Troubleshooting API calls in Custom MPages with JavaScript

If you don’t have access to the Developer Tools, then you are stuck with the troubleshooting challenge. JavaScript outputs is one of the options you have to hack the behavior of your custom MPage. We recommend reviewing our related articles on troubleshooting custom MPages.

When developing a web page on your local desktop computer, you can use your browser’s Development Tools to help you troubleshoot. we have access to the Developer Tools from the browser we are using to run and troubleshoot our web page. The browser’s Developer Tools are essential for troubleshooting.

When developing a custom MPage or custom component, we can start the development on our local desktop computer but eventually we will have to troubleshoot our code in our Cerner Millennium domain.

When troubleshooting a custom MPage or component from within the PowerChart framework, we don’t always have access to the browser’s Developer Tools. This can make troubleshooting very challenging.

When we don’t have access to the browser’s Developer Tools, one option to troubleshoot is to add JavaScript outputs to our code. Never the less, it’s important to note that some issues are detected and managed by the browser, not by the JavaScript code. This inherent limitation is an additional challenge to troubleshooting certain issues, as the browser does not give the JavaScript code the ideal feedback of the issues it encounetrs.

In any case, JavaScript could be all we have for troubleshooting custom MPages or components in a Millennium domain. To make this a little easier, you can find attached to this article a small custom MPage that can help troubleshoot an API call.

This article will review the JavaScript output for different issues you might encounter when implementing an API call.

Please note that unless the web server is set to allow CORS, the browser will most likely block API calls in JavaScript from a custom MPage or component, especially if you use the EDGE – Chromium setting. If you are unfamiliar with the CORS protocol, we recommend reviewing our article that describes the CORS concept. Understanding what the CORS protocol tries to prevent can save you days of troubleshooting.

It could still make sense to try to implement the API call from a custom MPage or component if you are in one of the following scenarios:

• The web server allows CORS.
• You are using a proxy web server that allows CORS.
• You are still working with the Internet Explorer preference setting.
• You just want to try implementing the API call – even knowing it will likely not work (as most web servers are not set to allow CORS).

The custom MPage attached to this article, implements an API call to a web service at EHR Enhancify. The JavaScript code makes a POST request with some dummy clinical event values. The web server’s response predicts whether the patient has diabetes or not (True or False).

The MPage makes two API calls:

• The first API call tries to make the POST request and hopes for a response with a status of 200:

   fetch(url, {
           method: 'POST',
           //mode: 'no-cors',
           headers: {
               'Accept': 'application/json',
               'Content-Type': 'application/json'
           },
           body: (data)
       })

       .then(response => {

           if (!response.ok) {
               document.getElementById("api_response_code").innerHTML = response.status;
               document.getElementById("api_call_outcome").innerHTML = 'Response status code other than 200';
               //throw new Error("Response indicates an error");
               return "";
           } else {
               console.log('Response code:', response.status);
               document.getElementById("api_response_code").innerHTML = response.status;
               document.getElementById("api_call_outcome").innerHTML = 'API call seemed to have been successful';
               return response.json();
           }

       })

       .then(mydata => {
           document.getElementById("prediction_result").innerHTML = mydata['prediction'];
           console.log('Data received:', mydata);
       })

       .catch(error => {

           document.getElementById("api_call_outcome").innerHTML = error + ". If domain is reachable, server/service may be down or CORS issue";
           //document.getElementById("api_call_description").innerHTML = 'Network, Server or CORS issue';

       });

• The second API call is incorrect on purpose. Additionally, it tries to make the API call asking for CORS to be ignored. It is intended to get an error response before CORS becomes applicable. This second call helps determine if you can at least reach the web server or if you get blocked by a firewall or network issue.

  //TRYING TO REACH THE SERVER:
  fetch(url, {
          mode: 'no-cors'
      }).then(r => {
          console.log('server reachable');
          //console.error('Error:', error);
          //document.getElementById("api_call_error").innerHTML = error;
          document.getElementById("api_call_description").innerHTML = 'The domain is reachable.';
      })
      .catch(e => {
          console.log('server not reachable');
          //document.getElementById("api_call_error").innerHTML = error;
          document.getElementById("api_call_description").innerHTML = 'The domain is not reachable. If the url is correct, this could be a network/firewall issue.';
      });

The following scenarios represent some of the most common issues you can encounter when implementing an API call.

Please note that your environment or circumstances may differ, and the MPage might behave differently. In any case, the JavaScript code and outcomes from the scenarios below can still be helpful for testing your implementation.

The tests were performed on a local machine – not a Millennium domain. We include the browser console errors for each scenario. This helps us understand what is really going on for each of the MPage’s outputs.

Scenario 1: The web server is running, and no network or firewall settings are blocking access to it. However, the web server is following the CORS protocol. #

Scenario 2: The web server is running, and no network or firewall issues are blocking access to it. The web server is set to allow API calls when CORS occurs. #

Scenario 3: The web server is running, and no network or firewall issues are blocking access to it. The web server is set to not block calls when CORS occurs. However, there is an error in the data we are posting to the web server. #

Scenario 4: The web server is down. The URL is valid. #

Scenario 5: The domain name in the API call is incorrect. #

Scenario 6: The API call is correct, but there is a network issue. #

Scenario 7: The web server is up, no network or firewall issues but the API call is is made to an incorrect method. #