Handling error conditions on a failed invoke – Digital Transformation with IBM API Connect

0 Comments

Within the Invoke policy, there are capabilities that instruct how the Invoke policy will behave on error conditions. A typical error condition would be a backend service that is experiencing slow response times. It is possible that your proxy needs to respond back to the consumer with a response (success or failure) within a defined Service-Level Agreement (SLA). If the SLA is shorter than the Invoke policy’s default Timeout value of 60 seconds, an error occurs. This scenario can be easily handled by leveraging the Timeout and Stop on error properties found within the Invoke policy setup. Here is a brief description of these properties:

  • The Stop on error property provides an option to stop the message flow’s execution when one or more pre-defined errors (for example, ConnectionError, SOAPError, OperationErrror) is encountered during an Invoke policy’s execution. If a catch flow is configured to handle these errors, then that catch flow is executed. If there is no catch flow configured, then the message flow processing continues, thereby ignoring the error. You add a catch flow by first enabling the Show catches slider. That will display an empty Catches box. When you click on the Catches box, it opens the properties box to allow you to add a new catch or add a default catch. This is shown in Figure 4.19:

Figure 4.19 – Enabling Catches

When you click on Add catch, you have various catch conditions to choose from. When you choose one of the 11 catch types, it updates the Catches section with the selected catch type and allows you to configure how to handle the catch. This is shown in Figure 4.20:

Figure 4.20 – Adding a catch

You can add more catches to handle other conditions.

  • The Timeout property is the time (in seconds) that the Gateway waits to receive a reply from the backend service.

You will now build an example to see the Stop on error and Timeout properties in action:

  1. Open the patient-information API in Designer. Open the Gateway tab.
  2. Enable the Show catches section of your API as shown in Figure 4.19. Click anywhere on the Catches block. A catch view will open. Add a ConnectionError catch by clicking on the Add catch button and selecting ConnectionError.
  3. Drag a GatewayScript policy onto the ConnectionError catch. This is shown in Figure 4.21:

Figure 4.21 – Applying error coding to handle error

4. Enter the following code into the editor of your newly added GatewayScript policy. You can also fetch this code (errormsg.js) from this chapter’s GitHub repository:

var errorName = context.get(‘error.name’);

var errorMessage = context.get(‘error.message’);

var errorResponse =

{

“name”: errorName,

“message”: errorMessage

};

context.message.header.set(‘Content-Type’,

“application/json”);

context.message.body.write(errorResponse);

Click Save to save your changes.

5. Click on the Invoke policy, scroll down the properties page, and check the Stop on error checkbox.

Figure 4.22 – Configuring Stop on error

When you click on search errors …, a dropdown with error types is displayed as shown in Figure 4.22. Choose ConnectionError to match up with the catch you just configured.

This completes your configuration of handling ConnectionError when such an issue is encountered in the API Proxy. With your API now configured to handle the connection error issues, you will next do a temporary configuration to create this error condition. This error condition will be created by utilizing the Timeout property of the Invoke policy.

6. The Timeout property (Figure 4.23) has the default timeout value of 60 seconds. You should set it to 10 seconds.

Figure 4.23 – Invoke policy’s Timeout property

7. The last thing that you need to do is force a timeout. This will be done by updating the patient-target-url API property. Use a URL that will time out. Change the API property value from https://stu3.test.pyrohealth.net/fhir/Patient/d75f81b6-66bc-4fc8-b2b4-0d193a1a92e0 to https://stu3.test.pyrohealth.com/fhir/Patient/d75f81b6-66bc-4fc8-b2b4-0d193a1a92e0 (note the change from .net to .com in the server name). Save the changes to your API.

8. Next, click on the Test tab. Send the request. After about 10 seconds, you should get the backend server timeout and observe the ConnectionError catch in action.

Figure 4.24 – Error caught – “Could not connect to endpoint”

Figure 4.24 shows the ConnectionError response “Could not connect to endpoint” in JSON. You have successfully tested the Stop on error and Timeout properties within an Invoke policy.

Remember to change the patient-target-url property back to https://stu3.test.pyrohealth.net/fhir/Patient/ for future testing.

Next, you will learn about another important property of the Invoke policy that is frequently used, and that is changing the HTTP method of the outgoing request (to the backend service).

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts