Described feature in this article was actually inspired by discussion with Donato so all credit goes to him!
BPMN2 has already a construct for similar thing – error boundary events that can be easily attached to service tasks to deal with exceptions and perform additional processing or decision taking. This approach has some drawbacks in more advanced scenarios
- error handling needs to be done on individual task level
- retry of the same service call needs to be done via process modelling – usually a loop
- each error type needs to be handled separately and by that makes the process definition too verbose
- process id that should be created to deal with this exception
- selected handling strategy to be applied when exception handling process is completed
- root cause exception
- COMPLETE – it completes the service task with the variables from the completed subprocess instance – these variables will be given to the service task as output of the service interaction and thus mapped to main process instance variables
- ABORT – it aborts the service task and moves on the process without setting any variables
- RETRY – it retries the service task logic (calls the work item handler again) with variables from both the original service task parameters and the variables from subprocess instance – variables from subprocess instance overrides any variables of the same name
- RETHROW – it simply throws the error back to the caller – this strategy should not be used with wait state subprocesses as it will simply rollback the transaction and thus the completion of the subprocess instance
Out of the box handlers and exception handling
Three major out of the box work item handlers are equipped with this handling automatically as soon as they are created with process id to handle exception and strategy. This takes over the regular error handling that will be applied when RETHROW strategy is selected.
Sample registration for RESTWorkItemHandler via deployment descriptor would be
new org.jbpm.process.workitem.rest.RESTWorkItemHandler("username", "password", classLoader, "handlingProcessId", "handlingStrategy")
Look at available constructors of given handler class to see all possible options. Similar way email and Webservice handlers can be configured to handle the exceptions via subprocess.
- report to administrator that service task failed – this would have to be via subprocess that has user task assigned to administrators
- use a timer based sub process to introduce some delay in retries
- ask business users to provide the information in case system is down in time critical situations