IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Developing business processes > Building BPEL processes

Versioning BPEL processes

You can create new versions of your BPEL process, so that multiple versions of those same processes can coexist in a runtime environment.

Here are some possible examples of when you would create a version of a BPEL process:

To create a version of a BPEL process, it is important that you plan ahead. Specifically, you will need to consider how the client interacts with the process, and how the process itself is set up. To allow for seamless introduction of new versions, it is a good idea to anticipate the need ahead of time, and set things up in the manner described in the associated topics.

One important consideration is whether instances of the process that are already running should move to the new version. If you want to migrate running instances you need to create a Migration Specification.

If you are content to allow existing instances to use the old version you do not need to create a migration specification.


Differentiating process versions

A version is a copy of an existing process that is slightly different from the original. To understand how this differentiation takes place, first understand what identifies a version of a business process.

If the module that contains the BPEL process is not associated with a process application or toolkit, then a version of a business process is identified by the following properties:

  1. same process component name
  2. same target namespace
  3. different valid-from date

If the module that contains the BPEL process is associated with a process application or toolkit, then the following properties constitute a process version:

  1. same process component name
  2. same target namespace
  3. different snapshot ID

In addition, it is important to note the following requirements:

Of critical importance, the two versions must have the same name and namespace, but have different valid-from dates or snapshot ID's. In addition, where applicable, they must also have the same interface, and correlation set specifications. It is with different valid-from dates that multiple versions of the same BPEL processes are distinguished. In practice, at run time the process engine could use a new version of a process that is set to become valid today, even if an older version of that process was still being used.


Invoking a BPEL process

When a client invokes a BPEL process, that client can be configured either to choose a specific version each time, or to pick up the currently valid version of the process. This is the basic concept behind early binding and late binding.

With early binding, a client is hard-wired to a process in such a way as to force a continued relationship between the two of them, even if another version of the process becomes available. In contrast, with late binding the relationship between the client and the process is dynamic in that it is resolved in the runtime environment.

If the module that holds the BPEL process is part of a process application or a toolkit, additional considerations apply to late binding. See Invoking different versions of a BPEL process for information.

If the caller instantiates a process using early binding, a specific version of the process is used to create that instance. If the caller uses a late binding, the currently valid version of the business process is used.

Process instance migration tools help you to update versions of running instances of processes in a late-binding situation. You create a process instance migration which, when deployed to the runtime environment, moves running instances of the process to the new version whenever possible. This facility is useful when you have very long-running processes.

Clients that want to use early binding can do it in one of the following ways:

Clients that want to use late binding can do it in one of the following ways:


For more information

See the white paper on developerWorks called Versioning and dynamicity with IBM Process Server and the podcast called WebSphere Technical Podcast series: SOA programming model, Part 5: Managing change in Web services components and applications.


Example

To see an example of a versioned process that you can build and run yourself, go to http://publib.boulder.ibm.com/bpcsamp/index.html, and click Process modeling techniques > Versioning.

You will need a connection to the internet to view this example.

Building BPEL processes