There are a number of methods for exception handling. However, when a BPD failure occurs and is not caught by an exception handler, another method might be needed to address the issue. In some cases, code can be fixed and then promoted to the environment and the next time the BPD is resumed, it will execute properly. An example of this case would be something that occurs at the BPD level, or a failure within a service that implements exception handling and allows for a retry.
However, if error handling is not properly implemented or there is a coding error that arises for certain data values within a service, resuming the BPD may not resolve the problem as changing the value in the execution context of a service that is causing the failure is not possible or easily accomplished, like it is at the BPD level.
In this case of this non-recoverable failure, the decision needs to be made whether starting a new BPD is sufficient or another mechanism needs to be implmented to rescue or recover the current BPD instance. For short or quick-running processes with few inputs, creating a new instance may be just fine. For longer-running processes or processes with many complex inputs, recreating a new BPD instance from scratch may not be a viable option. This is where a recovery framework allows the administrator to rescue these services with minimal impact to the end users.
This article describes a pattern (along with an example) for rescuing a BPD in distress. From a high-level, the steps involved are:
1) Building the recovery/injection framework into the existing BPD.
2) Obtain the execution context of the failed or troubled BPD instance.
3) Run the rescue coach service and provide the execution context and the step that the new BPD should start at.
Imagine a 3-step expense report submission, review, and approval process:
Build the Recovery/Injection Framework
The BPD needs to be updated to allow for the recovery instances to be injected and a UCA, passthru service, and coach service to enter the rescue instance data and starting point need to be created. Each of these steps is detailed below in this section.
Create UCA and Passthru Service
Create a basic system service (with a straight line from the start point to the end point) to be used as a UCA passthru service. There should be an input and output parameter named expenseReport of type ExpenseReport and another input and output parameter named startingPoint of type String.
Create Injection Coach Service
The list of entry points is compiled in the first script block, then presented to the user in a drop-down along with a text field to enter the expense report XML data taken from the Process Inspector:
Finally, after the ‘Inject Instance’ button is pushed, the XML data is deserialized into the expense report and the object along with the startingPoint string are passed to the UCA which is invoked, thereby starting a new instance of the process at the desired step.
Add Start Message Event and Decision Gateways to BPD
The next step is to modify the BPD and add a start message event which listens for the UCA created earlier. Then, add a decision gateway for each step in the process where a new instance could be injected.
Rescuing an Instance
This section will describe how to rescue a failed instance by obtaining the execution context, determining which step the new instance needs to start at, and finally running the injection coach service created earlier to recreate the instance.
Obtain the Execution Context
Locate and click on the failed instance from the Process Inspector and then click on the last active point (before the error) in the Execution State diagram. Now, on the Variables tab in the lower right a list of the active variables should appear. The Execution Evaluator tab will also allow the user to type the variable to show (i.e., tw.local.expenseReport). Select all of the XML data for the expenseReport object and copy it to the clipboard to be used in the injection service.
Run the Rescue Service
Considerations with this Technique
If the BPD instance ID is used as an identifier in the process, note that it will be a different BPD instance ID after being resurrected – there may be process implications from this that need to be dealt with.