10.7 Implementing Error Handling
When modeling a process, it’s crucial to think about how to deal with exceptional situations in your business process. The exceptions need to be caught and handled.
There are a couple of options within SAP BPM to handle exceptions:
-
Error end event
An error end event can be used to model an exception that occurs in a process. Imagine a scenario in which you want the process to explicitly throw an exception if a bad value is entered in a human task. To intentionally throw such an exception, an error end event can be used. Be aware that you can select the Terminating checkbox to turn the error end event into a termination event (see next bullet point to learn about a termination event). The error end event requires that you specify the error event to be triggered. It’s therefore capable of triggering another process or an independent interface responsible for handling the exception. -
Termination event
This event is the same as the error end event, except that in addition to throwing an exception, the process will be terminated. -
Boundary event
There are more specialized exception events that can be attached to different activities, such as human activities, automated activities, and subprocesses. The boundary event catches an exception that occurred in the activity to which it’s attached. These exceptions can be handled by modeling outgoing flows from the boundary event. We already explored specific boundary events when discussing the different activities in Section 10.4.3.
Figure 10.68 shows an example process using a boundary event and an error end event to handle an exception that occurred in a human task. It’s important to be aware that the mechanisms listed previously are mostly used to catch exceptions and errors. When it comes to handling the errors, you have the freedom to model the error handling in whichever way suits your business requirements best. Some possible error handling solutions can include the following:
- Use a notification activity to notify the appropriate people within the organization who are capable of taking corrective actions.
- Have a human activity assign a task for the appropriate person to take corrective action.
- Call a service (an automated activity) that will handle the exception.
- Implement a retry mechanism to repeat the failed step. However, it’s important to be careful with this approach! Don’t retry steps that might produce the same exception, which could create an infinite loop and a deadlock situation. If you opt for a retry mechanism, make sure to set a maximum number of retry attempts.
When an exception occurs at a process level, the process will be stopped and its status will change to suspended. Someone from the support organization or an administrator will need to investigate the reasons that the process ended in an exception and take appropriate corrective action.