Error handling involves handling custom error conditions and pre-defined error conditions. Examples of custom error conditions could be data validation faults (missing last-name, missing first-name, and so on) and business validation faults (typically arising from backend services such as account number not available). You gained some experience in error handling earlier in the Invoke policy section.
Examples of pre-defined error conditions are ConnectionError, JavaScriptError, and TransformError. A complete list of pre-defined errors is available at https://www.ibm.com/docs/en/api-connect/10.0.1.x?topic=reference-error-cases-supported-by-assembly-catches. A Throw Policy is available to throw an error reached during the execution of a message flow. Handling of the thrown error is done via an IBM Catch extension. This extension allows you to catch the thrown exception, build a processing flow to take remedial measures, and generate an appropriate error message for the API consumer. In this section, you will learn techniques to do the following:
- Throw a custom error using a Throw Policy
- Throw a pre-defined error in the GatewayScript Policy
- Catch an error
- Access the Error context variable in a GatewayScript Policy
You will use the inline-access API proxy that you built earlier to apply some error handling.
The Switch Policy has two execution paths. These two paths will be used to demonstrate the throwing of a custom error using the Throw Policy and the throwing of a pre-defined error in the GatewayScript Policy:
- Open your inline-access API Proxy in Designer and click on the Gateway tab | Policies in the navigation menu.
- Drag and drop a Throw Policy to the Production path of the execution flow, as shown in Figure 4.44:
Figure 4.44 – Adding a Throw to the Production branch
- Provide the following values for Error name and Error message:
Error Name: UnsupportedEnvironment
Error Message: Set ‘Environment’ header to ‘Test’ because ‘Production’ environment is currently unsupported.
Note: v10.0.1.5 Enhancements
When configuring a throw policy, you can now specify the HTTP status code and reason phrase in the Error status code and Error status reason properties, respectively.
- Next, drag and drop a GatewayScript Policy at the beginning of the Test path. Name it Validate patient-id.
Figure 4.45 – Add the PID validation check
- You can use the code downloaded from GitHub called pidcheck.js to copy and paste in the code block of your GatewayScript policy.
Figure 4.46 – Applying error handling to GatewayScript
Review the following code. You will see that it checks for the length of the patient-id parameter value and throws an error based on the length of the patient-id value:
var patientid =
context.get(‘request.parameters.patient-
id.values[0]’);
if (patientid.length < 36) {
context.reject(‘ValidateError’, ‘Incorrect
patient-id’);
}
The code uses the context.get() method to access context variables. Parameters that you receive as part of the request are also considered context variables.