Integration Centric Process – Exception Handling in BPM
Many Architects , across organizations using PI (dual stack), tend to be very discouraging of using ccBPM in integration scenarios. They are happy to go to any extend in recommending workarounds so that ccBPM based designs are negated. This skepticism had prompted me to write the blog ‘Why are most skeptic about ccBPM and its usage in PI?’.
One of the points emphasized in the blog is around proper exception handling. Exception handling is key to any program, application or even a process. So as one moves from the traditional BPEL based ccBPM Integration scenario to BPMN based Integration centric processes, exception handling will continue to be the key. In this blog, we will focus on these aspects and hopefully for consultants who are migrating from PI dual stack to Process Orchestration will provide the ease of adoption.
Note: SAP Process Orchestration Details – Release NW731 SP 10
For simplicity sake, the scenario we will use follows the below processing logic;
1. Read an XML file from a FTP server which has the input fields as FName, LName and Age.
2. If Age is Greater than 70, then perform a simple mapping (modeled inside BPM itself) of setting the FName as the FullName of the output file.
3. If Age is Less than 70, then call a PI mapping (modeled inside ESR) which will concatenate FName and LName into FullName of the output file.
The Input File Structure;
The Output File Structure;
The scenario will be modeled as below;
Now lets make things interesting.
The automated activity PI_Mapping in the above Process Model is making a call from the BPM engine into PI and executing a mapping that was created in ESR.
The mapping is a very simple mapping as described in the below screenshot;
Now, in a real time scenario, one of the common exception to be handled is of the mapping failing on execution. To make our Process Model efficient, lets introduce an exception handler so that in case of the message mapping failing in PI, we can take appropriate actions. In our case, we will catch the exception and then write the exception to an Exception Output File.
Lets assume that the Exception file is of the below format;
How to introduce Exception Handling?
In our scenario, we want to handle exceptions for the PI mapping step. So in the Process Model, go to the Properties of the PI_Mapping automated activity. In the tab Boundary Events, add an event of the type TechnicalError.
Now we will perform an Output mapping for the newly created Boundary Event. You will find a standard data object ‘parameters’ that will hold runtime data related to an exception. We will use two of the fields from this object (logId and rootErrormessage) and map it to the Data object of the exception file.
We will now create a final automated activity to write the details of the exception to the Output Exception File to an FTP server. The final Process Model will be as below;
Build and Deploy the Process.
Now to ensure that the Exception handling is working, lets try and simulate a mapping exception. The easiest way would be modify the message mapping in ESR to ensure a failure 🙂
Change the mapping for the Age field and introduce a substring function so that we will mock a String Out of range exception.
Test the mapping in ESR to ensure that we do get a mapping failure;
Now if we test the scenario end to end, we should find that the BPM process to have triggered the boundary event and the exception details captured into the Exception Output file.
Hope this acts as a starting point to help you factor in appropriate Exception Handling measures in your integration centric processes.
One can extend the error management strategy by introducing TechnicalError boundary events to not only individual steps but also to Sub-Processes. You can also model the process to implement Retries on particular steps (a good scenario will be a when a Webservice call fails due to the webserver being down) so that instead of immediately taking action on a failed action, the step can be re-triggered (as appropriate). I recommend the TechEd && d-code session INT361 that will provide further details into error resolution strategies.
Want to take it to the next level? Then refer this blog.