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.

Example Description

Imagine a 3-step expense report submission, review, and approval process:


Now assume that there is a Javascript coding error within a script block in the Review step that only surfaces under very specific conditions. In this BPD diagram, since there is no error handling on the activities, the BPD will fail. Even when exception handling is introduced, there may be conditions in which the BPD fails and cannot be resumed because the condition causing the error occurred at a previous step and the in-flight data cannot be retroactively modified to allow the BPD to proceed.

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.


Next, create an On Event UCA and attach the passthru service created in the previous step.


Create Injection Coach Service

Now, a method for injecting the data at a given point must be built. A sample coach service is shown below:


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

Launch the rescue service and enter the XML taken from the Process Inspector into the text field, then select the starting step from the drop-down (i.e. “Review” in this case).


Finally, look at the Process Inspector again to see that the instance has been injected back to the point requested with the same expenseReport data.


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.

1 comment on"BPD Injection Recovery Pattern (Rescue Services)"

  1. Hi Jim

    Great tutorial and quiet helpfully , could you please share the sample code for this approach ?



Join The Discussion

Your email address will not be published. Required fields are marked *