In the webMethods.io Integration scenarios, we would be required to handle the errors that occur during run time in workflows or flow services. The errors should be handled and logged appropriately or sent as response to the source system that initiated the call to webMethods.io integration.
Why to do error handling & logging?
- To identify the root cause of errors.
- For generating alerts upon errors from the system.
- Source or target systems to be informed of the respective errors in the integration flow.
- Avoid situations like getting into infinite loop or heavy utilization of existing resources etc.
Where to do error handling & logging?
- Workflows.
- Flow services.
- Workflows involving Flow services
- Hybrid flow: Workflows with on-prem connectors.
What to use for the implementation?
- For Workflows
| Step | Usage |
|---|---|
| Logger | To log the relevant information to webMethods.io logs. |
| JSON Customizer | To customize the JSON data in the flow or the response. |
| Return Data on Sync Webhook | To send the error response to the caller. |
| Send Email | To generate email in workflows. |
| Set Workflow Status Failed | To explicitly set the status of Workflow as Failed. When Global Error Handler is used, the status of Workflow would always be indicated as “Success,” and it would cause huge effort to identify the workflow instances that failed. |
- For flow services
| Step | Usage |
|---|---|
| Try-Catch Block | To handle the exceptions in catch block. |
| Throw error | To throw exception in the flow service. |
| getLastError | To get the last error that occurred. |
| logCustomMessage | To log the custom message to webMethods.io logs. |
| SMTP Connector | To generate emails. |
| On-prem connector | This is useful in scenarios where we would have the hybrid connection to the on-prem system. We can have the error handling framework in the internal IS and we could invoke the respective service as an on-prem connector. We need to make a note that this could result in additional network traffic when we call the on-prem system. |
How Should We Implement?
The custom error code to be captured at specific step in the flow are customized using JSON parser. Please note that the below workflow steps as indicated here in the screenshot are only for demonstration purpose and not compulsory.
The custom error message is extracted from the previous step of error handler (in this example createAlarm).
The custom error codes are stored in the project parameters which are used for the mapping.
Error logging in monitor: this is how the error logs will look like in webMethods.io monitor.
This article is part of the TECHniques newsletter blog - technical tips and tricks for the Software AG community. Subscribe to receive our quarterly updates or read the latest issue.