In this lesson, the following topics are discussed:
- What is an Exception?
- Define an Error Configuration for one integration flow to inform the Sender.
- Define an Exception Subprocess.
- Error Handler.
- Error and Escalation events.
What is an Exception?
There are typically two types of exceptions: expected and unexpected. Expected exceptions can include different values in a message field or empty values, and can be handled through the integration flow design. Unexpected exceptions, on the other hand, are technical in nature, such as connection failures or errors in scripts, and can lead to program termination. To prevent this, unexpected errors must be intercepted and handled appropriately to allow the program to continue running.
The focus now shifts to unexpected exceptions and their handling, and for the remainder of this discussion, the terms "unexpected exceptions", "exceptions", and "errors" will be used interchangeably.
Define Error Configuration for One Integration Flow to Inform the Sender
You can specify the error handling mechanism for handling runtime failures during message processing. The primary objective of this approach is to communicate error details to the sender for better awareness. To achieve this, you can enable the Return Exception to Sender flag in the integration flow settings.
Read More Here:
Define an Exception Subprocess
An extra subprocess can be defined within an integration flow, which will be invoked whenever an unexpected error occurs.
Procedure
- In an editable flow, you may want to retrieve an exception to ensure that the original process is completed without any errors.
- Place an Exception Subprocess.
- Define your error handler.
- Save, deploy, and run your integration flow.
Sample
Your integration flow has encountered an error as the connection parameters are not functional.
The error in the message monitor after deployment:
Usage of an Exception Subprocess:
The starting event is an Error Start event. This component fetches the exception.
The monitor with the exception subprocess:
You can view the detailed error information inside the Message Processing Run.
Error Handler
If the error is caught by an Error Start event, any further processing can be implemented as in a regular process. Scripts, like the one demonstrated in Handle Exceptions, are especially common.
Error and Escalation Events
The Error Start event always triggers the Exception Subprocess, which intercepts the error and starts its execution. If you want to terminate the Exception Subprocess without the status Failed, you must define an End Message, as shown in the previous example.
Manual Generation of Error and Escalation End Events
Setting an Error End event at the end of an integration flow will always cause it to enter the Fail status, which can be used as a design element. The Error End event serves as the endpoint of the main process, and in case of any errors, the Exception Subprocess always intercepts it.
Run to an Error End Event:
If you get the Failed status, then the process worked correctly.
The Escalation End event generates an error without interrupting the main process.
Run to an Escalation End Event:
If you get the Escalated status, then the process worked correctly.
Summary
A special error subprocess can intercept an unexpected error using an Exception Start Event. After interception, various processing steps can be implemented. For instance, it is appropriate to store process values or message content following an error. Also, informing the sender about the error can also be configured.
