Overview

The versioning sample shows how a business process can evolve in a production scenario with long-running process instances. In this scenario, we cannot simply overwrite an existing business process definition because this would affect and possibly invalidate existing instances. Instead, a new version of a business process can be installed in parallel to existing older versions. In conjunction with late binding, the process execution infrastructure automatically uses the currently valid version when starting a new process instance. This sample demonstrates how to use late binding when calling a subprocess from a parent process.

Initially, the structure of the involved modules looks like this:

Figure 1: Module structure for a scenario enabled for evolving versions of the subprocess

Note: Even for the first version you need to use the late binding mechanism when calling the subprocess to be prepared that a new version of the subprocess can be called without any change in the parent process.

Next, a new version of the subprocess to be used from now on is installed on the server. This does not overwrite the existing version of the subprocess; this rather provides an additional version that will coexist with the older versions. As soon as the Valid From date specified for the new process version is reached, all newly created instances are created based on this new process version - version 2. However, already existing instances based on version 1 will continue to run according to version 1 of the business process.

The new structure of the involved modules looks like this:

Figure 2: Module structure after installing a new version of the subprocess

Sample business scenario

To illustrate process versioning with a concrete example, consider a simple business process to handle warranty claims. As the first step, this business process contains an approval step that determines whether a warranty claim is valid or invalid (fraudulent, warranty interval expired, etc.). Let us further assume that the implementation of the approval step is expected to change in the future, so we want to enable a smooth replacement of this step with a newer version.

The main business process looks like this:

Figure 3: Parent process

Note that the approval step is designed as call to a subprocess that is located in a different module.

The initial version (version 1) of this subprocess looks like this:

Figure 4: Version 1 of the subprocess

In this initial version, the approval decision is performed by a human being and thus is implemented as human task that requires the subprocess to be a long-running process.

Now imagine the approval process evolves: The approval decision does no longer require human intervention but can run fully automated.
The evolved version (version 2) of the subprocess looks like this:

Figure 5: Version 2 of the subprocess

As no longer a human being is involved in the approval decision, version 2 of the subprocess can be implemented either as a long-running process or as a microflow. However, the interface for calling the subprocess must exactly be the same.

Versioning for SCA components other than processes

The late binding mechanism as described in this sample is only supported between processes; in other words, to use the late binding mechanism it is required that both the invoking component and the invoked component are BPEL processes. All other SCA components need their references to be wired in the assembly editor and hence are subject to early binding. However, the late binding mechanism can be extended to other SCA components that are supposed always to call the most recent version of a process. This is done by adding a proxy process between the calling SCA component and the evolving process. The SCA component is then wired to the proxy process (early binding) and the proxy process calls the evolving process using the late binding mechanism.

The structure of the components including the proxy process is shown in figure 6.

Figure 6: Implementing late binding for arbitrary SCA components by using a proxy process

 

The implementation of the proxy process is simple: It just contains the activities that represent the initiating operation of the process, that is a receive activity and a reply activity if the operation is a request-response operation, and an invoke activity to call the evolving process using late binding.

For best performance, the proxy process should be a microflow in each of the following cases:

In all other cases, the proxy process should be a long-running process.

The details of the proxy process implementation are shown in figure 7.

Figure 7: Proxy process implementation details

Remarks: