Integration Centric Process – Advanced Exception Handling in BPM

The blog Integration Centric Process – Exception Handling in BPM would have helped set a context around handling exceptions within your Integration centric process. In this blog, we will take the Exception handling to the next level in an attempt to model a comprehensive solution and a Integration centric process that is highly supportable.

Note: To maintain continuity, we will extend the Process Model that was defined in the earlier blog.

Adding a Notification

We can introduce a simple notification step within our process. This will be helpful to trigger email notifications to the business process owner, Process Admin or the Application Maintenance team so that they can take the required follow up action.

On the introduction of the Notification step, the process will look as below;

You can configure the properties of the notification step to create an email. There is a concept of ‘variable’ that you can define. These variables can then be referenced as part of the Mail Subject or/and Body.

In our case, I decided to use the fields from the input file (FName, LName and Age), the Process instance id along with the actual exception details, to be embedded into the Email.

In the below screenshot, you can find the Notification step (Notify by Email) properties. The variables once added can be assigned an Expression and I have chosen the corresponding context objects from the expression editor. These variables once defined, can be referenced in the email subject/body using the curly braces i.e {} as shown below;

.

Upon the execution of the process (with an erroneous file), you will find an ‘alert’ email in your inbox as below;

The highlighted (orange boxes) are values of the variables at runtime, populated during the execution of the process.

Implement Retries for a failed Step

Even though notifications help better the overall maintainability of the process, what would be much more optimum for some business processes, is the ability to retry some of its failed steps.

Take the example of an automated activity that makes a webservice call to an external application. It is quite possible that due to the network traffic during the time of the execution of the call, the webservice could timeout. Instead of ending the process then and there, if we could implement a retry logic, then it would help continue the process and give it a better chance of a successful completion.

Lets us try and extend the above process model and implement a retry step for our automated activity.

Note: The automated activity in the process we have is making a mapping call into PI. So this might not be an ideal use case for retry. But the idea here is to demonstrate this as a strategy so that you can implement it in other processes where it finds a use.

The process is extended further as below;

If I can try to describe it, what we are trying to achieve is to implement a retry feature by checking the value of a data object (Retry_Num). The Data Object is initialized as 0 during the start of the process and when an exception occurs we increment it by 1. The exclusive choice will then check the value of Retry_Num. If it is less than 4, then we route the flow back to the automated activity. A notification is also triggered that informs that an exception has occurred and the step is being re-triggered.

So in short, in case of exceptions, the automated step PI_Mapping, instead of proceeding to end the process now attempts retries (a maximum of 3 times) in our particular process.

Properties of Intermediate Timer;

Properties of Exclusive choice step;

Mapping to increment the Data object;

Properties of Notification Step;

On testing with an erroneous file, you will find emails in the below order informing of the exception, the retry events and the final exception handling.

Mail for the first retry attempt;

Mail for the second retry attempt;

Mail for the third and final retry attempt;

Exception handled and the notification is triggered;

With this, hope you now have options to make your Integration Centric Processes much more supportable.

Reference:

INT361 : Error Handling in BPM-Based Processes Using SAP Process Orchestration