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:
- In the likelihood that your BPEL process will need to be modified over time, but its callers will not. In such a case, you will want the existing callers to be able to seamlessly pickup the newest version of the process the moment it becomes effective.
- You have a solution where multiple versions of the same BPEL process must coexist. Although the solution as a whole cannot be uninstalled and reinstalled, you will need to be able to deploy new versions of the process in such a way as to ensure that new instances use the latest version and, wherever possible, existing instances also migrate to the latest version.
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:
- same process component name
- same target namespace
- 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:
- same process component name
- same target namespace
- different snapshot ID
In addition, it is important to note the following requirements:
- Correlation set specifications of different process versions need be the same.
- Interface specifications of different process versions need to remain the same. If you change the WSDL definition in any way, you need to change the BPEL process to incorporate those changes. If the WSDL has changed, you will need to load the new WSDL into IBM Integration Designer, because when you deploy the module to the runtime environment, it requires the service definitions in the consumer and provider to match.
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:
- Using SCA wiring
- Using the Business Process Choreographer APIs (generic EJB API or generic web Services API)
Clients that want to use late binding can do it in one of the following ways:
- Through the partner link extension in cases where a process that is acting as a client calls another BPEL process.
- Using the Business Process Choreographer APIs (generic EJB API or generic web Services API)
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.
- Create a new version of your process - migrate running instances
Process instance migration enables you to migrate running instances to a newer version by creating a process migration specification. This topic explains how to create a new version of your process that you can use as the target of a process instance migration in the runtime environment.- Create a new version of your process - running instances use old version
Create a new version of your process whose binding may be dynamically resolved in the runtime environment. This procedure does not include the generation of a Migration Specification, which would be necessary to move running instances of the process to the new version.- Create versions of your process to be used with SCA components and exports
This section explains how late binding between two processes can be used to allow late binding for arbitrary SCA components and exports. This pattern is only to be used when other means to apply late binding such as using the Business Process Choreographer API are not applicable.- Late binding using a partner link extension
When you late bind one process to another one, the connection is resolved dynamically in the runtime environment. In that situation, the calling process will always pick up the currently valid version of the process that it is invoking. New instances will always use the latest version of the process, and if you use the migration verification tools you can also migrate running instances to the latest version.- Process Migration Specification
Use a Process Migration Specification to migrate business process instances.