![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Business processes evolve over time. They need to reflect changing environments and business needs. These changes might be business-driven changes, such as changes in regulations, or optimizations of business processes. Also, technology-driven changes can impact business-process-based applications, for example, a service that is important to a process is replaced by another service.
Business-process-based applications are unique in that they can include long-running instances. These business process and human task instances can run for weeks, months, or even years. This imposes specific requirements on the introduction of evolved business processes or human tasks because instances might still be running. These instances need to complete using the version they were created and started with. However, the business may require that new instances are created based on a new version of a business process definition. Hence, new versions and old versions need to coexist.
The following example shows business processes that handle travel approval and booking. A top-level process TravelApprovalAndBooking controls the overall processing, a subprocess TravelAvailablitiyAndCosts determines the cost and availability of a flight, hotel, and rental car, and another subprocess TravelBooking does the booking.
Figure 1. Travel approval and booking process (first version)
The process starts when an employee enters data for a business trip.
A subprocess is called to evaluate the availability and the costs of the travel request.
Depending on the costs, a manager needs to approve the travel request. This is realized using an inline human task.
If the travel request is approved, another subprocess is called to book the
travel arrangements.
The travel information (flight numbers, hotel name and rental car company) is returned to the employee.
Because of changes in the travel booking guidelines, an update of the travel booking and approval process is necessary. An additional approval step is required so that travel requests to insecure countries can be rejected.
Figure 2. Travel approval and booking process with additional approval step (second version)
The update is realized by introducing a new version of the travel approval and booking process. The new version includes an additional human task activity for the extra approval step.
The following sections explain the concept of versioning and how to develop new versions of business processes and human tasks in WebSphere Process Server. They also describe best practices you should consider when using versioning.
This section explains some important concepts that you need to know to gain an understanding of versioning.
The Service Component Architecture (SCA) is the key to service oriented architecture (SOA). The basic units of such architecture are SCA components. An SCA component is a SOA service that is described through its interfaces and references that are wired to other services. Its implementation differs depending on the component type. Business processes and human tasks are two of the component types. A business process component is implemented using a business process definition (BPEL file), a human task component using a human task definition (TEL file).
A process template is the runtime representation of a process component that is specified in WebSphere Integration Developer and deployed to WebSphere Process Server. Similarly, a task template is the representation of a human task component that is deployed to the runtime environment. When a business process or human task is started, an instance is created based on a specific template. This template describes how the instance is executed.
The life cycle of a process template or task template is shown in Figure 3. A template can assume one of the two states started and stopped.
State transitions are triggered using either the WebSphere administrative console, or the wsadmin console interface.
Template life cycle
- started
- In this state, new instances of a business process or a human task can be created.
Next state: A template can be stopped to prevent the creation of new instances from this template. Stopping a template leads to the state stopped. - stopped
- In this state, no new instances can be created from this template. However, existing instances can run until they complete.
- Next states
- In this state, when a template is started, its state is set to started. If no more instances of a template exist, the template can be removed by uninstalling the corresponding enterprise application.
The enterprise application containing this template can be stopped or started independently of the template life cycle. If an enterprise application is stopped, instances of the templates in the enterprise application are not processed, and instances cannot be created.
Versions of processes and human tasks
A version of a business process or human task is an evolved copy of an existing business process or human task. You use versioning when you want alternative instances of the same business process or human task to co-exist in the runtime environment.
Versions are identified by the following properties:
- same process or task component name
- same target namespace
- different valid-from dates
The following figure shows where the properties come from for a business process. For human tasks, the same applies.
Figure 4. Properties used to identify a version
The scope for versions of business processes and human tasks is a single deployment target; in a network deployment environment this is a cluster or an application server. Templates of different deployment targets operate separately and therefore cannot be considered as versions of the same business process or human task.
The valid-from date
WebSphere Process Server allows the installation of multiple versions of the same business process or human task. This means that several versions of a process or task can coexist in the runtime environment. A version of a process or task is realized in the runtime environment by the corresponding template.
A task or process version, that is, its template, is currently valid if the valid-from date of the task or process definition is the most recent in the past. The valid-from date is relevant for late binding.
Figure 5 shows a versioning example. There are three versions of process A installed. The current date of the server determines which version of the process is currently valid. In this example, this is the process template of version 2 because its valid-from date, 2009-01-01, is the most recent in the past. The next version (V3) becomes valid on 2010-01-01. Process B has only one version installed. Its valid-from date is in the future. If process B is invoked using late-binding, you see an error. However, if process B is invoked using early-binding, the invocation is successful.
Figure 5. Shows which version is currently valid
Early binding and late binding
To invoke a specific version of a business process or human task, the invocation needs to happen using early binding. Early binding happens when, for example, a Web service client calls the SCA export of a process, or an SCA component invokes a process using an SCA wire.
Figure 6. Early binding: Wires between SCA components
SCA wiring is one way of specifying early binding invocation. An SCA component has one or more references to other services. It wires these references to another SCA component within the same module or to an SCA import if the target is beyond the SCA module scope. If you use SCA wires to invoke a human task or business process, the valid-from date of the task or process is not considered. A specific version can be invoked this way.
If a business process or human task is invoked using late binding, Business Process Choreographer determines the currently valid version, and then uses this version for the invocation. Late binding can be applied to business processes and human tasks.
Instances of different versions
Instances are executed based on the template from which they were created. When a business process or human task instance is created, a reference to the template is stored with the process or task instance. Subsequent calls to the instance, for example, via an event handler of the business process, are handled using the template that was stored during instance creation.
Instances of multiple versions can coexist in the runtime environment, because new versions can be introduced while instances of previous versions are running. If a new version of a business process or human task becomes valid, this does not impact existing instances. However, clients that use late binding automatically pick up the new version when new instances are created.
In the example shown in the following figure, there are three templates representing three different versions of the same business process, and the instances based on these versions.
Figure 7. Instances execute according to the template from which they were created.
Considerations for specifying a new version
In addition to the component names and the valid-from dates, you need to consider the following aspects.
Interfaces and business objects
Versions of the same task or process must have identical interface specifications. Clients that use late binding to interact with processes and tasks through these interfaces must not be impacted after the installation of a new version. If the interface for a new version is changed, the behavior of the process or task is not predictable.
Business objects that are used as part of these interfaces of versioned processes or tasks must also be identical, that is, their qualified name (qname) and the corresponding type specification must be identical.
Figure 8. Interfaces and business objects used in processes
You can change business objects that are only used within a business process for its internal processing in a new process version.
If parameters of the process interface are likely to change in the future, consider using a more weakly-typed interface for your process. Refer to section Weakly-typed interfaces and business objects below for details.
Correlation set specification for business processes
When Business Process Choreographer receives a request, it needs to identify the process instance for which the request is targeted. Instances are identified using a correlation set that is passed as part of the request. The correlation set must work across different versions of a process. Therefore, correlation set specifications that are used to identify process instances must remain the same for new process versions.
Clients relying on certain process or task characteristics
Clients may rely on certain characteristics of the processes or tasks they interact with. When you design a new version of a process or task, you should consider these characteristics so that existing clients can continue to work seamlessly when the new version is installed.
These characteristics include:
- Type of business process
- Long-running business processes and microflows have different response behavior and transactional behavior. For example, when invoking a microflow, the client receives the result within the same transaction; for a long-running business process, the result is available in a subsequent transaction only. Also, API methods used to invoke a business process can depend on the type of process. That is, changing the type between versions can have an impact on the clients of the process.
- Authorization
- Clients might need specific authorization to interact with a business process or a human task. If you modify authorization specifications of processes or tasks, verify whether the changes impact your clients.
- Query properties of business processes
- If query properties are specified for a process to enable clients to query business data, keep the same specifications for the new version so as not break existing clients that rely on these query properties.
- Interface qualifiers
- SCA interface qualifiers apply to business process and human task components, for example, transactional qualifiers or invocation specifications. If you needed to change such a specification, verify that this works for existing clients.
Where early and late binding are supported
As indicated earlier in section, Early binding and late binding, there are cases where you can choose to use early binding or late binding to call a human task or business process, and there are cases where only early binding or late binding is supported.
Support for early binding and late binding
This section describes where you have the option to choose from early binding and late binding.
Web services interface and EJB API of Business Flow Manager
The Web services interface and the EJB API of Business Flow Manager provide methods for early binding and late binding. In general, methods that take a process template name as a parameter use late binding. Methods operating with template IDs, for example, PTID, ATID, and VTID use early binding.
For example, the BusinessFlowManager EJB interface, offers the following method signatures:
-
sendMessage(String processTemplateName,
String nameSpace, String portType, String operation, ClientObjectWrapper inputMessage) -
sendMessage(VTID vtid,
ATID atid, ClientObjectWrapper inputMessage)
The first signature of sendMessage uses the currently valid process denoted by processTemplateName, that is, it uses late binding. The second signature invokes a specific process template using the template IDs vtid and atid that is; it binds to that particular version.
Process-to-process invocation
Process-to-process invocation can be done in either a late-bound or early-bound fashion. If the calling process is wired to the other process using an SCA wire, then the invocation is done using early binding, that is, the process that is the target of that wire is invoked. The calling process and the process to be invoked can be in the same SCA module, or they can be in different modules wired through an SCA import or SCA export.
Late binding does not require wiring between the processes in a process-to-process invocation because the target component is determined dynamically at runtime. Instead of a static SCA wire, you specify the process template name of the process to be invoked as part of the calling process. This is done in the business process editor in WebSphere Integration Developer as part of the reference partner properties of the invoke activity that does the process invocation. See WebSphere Integration Developer Information Center, V6.1.2, Late binding using a partner link extension in the Resources section.
Typically, the process to be invoked resides in a separate SCA module. If so, it needs to be exported using SCA export with SCA native binding.
Figure 9. Assembly diagram and business process editor specifications for late binding
Web services interface and EJB API of Human Task Manager
The Web services interface and the EJB API of Human Task Manager only support methods that use late binding.
For example, the HumanTaskManager EJB interface offers the following method signature:
-
createTask(String taskTemplateName,
String taskNamespace)
This method creates a task based on the currently valid task denoted by taskTemplateName and taskNamespace.
Dynamic invocation of subprocesses by name
Endpoint references (EPRs) are a common way to dynamically choose the service to be invoked. To enable dynamic subprocess selection and invocation at runtime, WebSphere Process Server allows you to determine an EPR of a subprocess. The getServiceRefForTemplate method is used to retrieve an EPR of a subprocess given its name processTemplateName. You can use the EPR to invoke the service of the subprocess that is specified via its port type – portTypeNamespace and portTypeName. The method returns an EPR of the currently valid version of the process, that is, it uses late binding:
-
getServiceRefForTemplate(
String processTemplateName, String portTypeNamespace, String portType)
This method is available to assign activities see
the WebSphere Integration Developer information center, XPath extension functions and Java™ snippet activities. In assign activities, you use the XPath extension function getServiceRefForTemplate in the from expression to assign the EPR that is returned to the partner link specified in the to specification of the assign activity.
In Java snippet activities, if you call the method getServiceRefForTemplate you retrieve an instance of com.ibm.websphere.sca.addressing.EndpointReference. Use this EPR to assign the instance to a partner link using the method setServiceRefToPartnerLink( <partnerLinkName>, <EPR> ).
Business Process Choreographer Explorer
Business Process Choreographer Explorer provides a generic, Web-based interface for creating and working with business processes and human tasks.
Figure 10. Business Process Choreographer Explorer showing process templates
You can start instances of currently valid business processes and human tasks only. That is, Business Process Choreographer Explorer is a client that uses late binding. Nevertheless, you can work with instances of templates that were previously valid, for example, you can claim these human task instances or work with these process instances.
JSF and Lotus Forms custom clients
In WebSphere Integration Developer you can generate business user clients for business processes and human tasks based on JSF technology or Lotus Forms technology. The generated client code uses the EJB API to interact with tasks and processes; the EJB methods that are called by the generated client code use late binding.
Support for early binding only
SCA components invoking business processes or human tasks
SCA components that invoke a business process or a human task are wired to the corresponding SCA component of the business process or human task. This static wiring results in calling a specific version, that is, early binding is used.
If the calling SCA component is a process, you can use late binding, as described in the earlier section, Support for late binding .
To enable any SCA component to call the currently valid version of a business process or human task, you can use the patterns described in sections, Proxy process for business processes and Decorator process for human tasks below.
Processes without WebSphere Process Server BPEL Extensions
The valid-from date is a BPEL extension, standard BPEL does not provide it. If you want to use standard BPEL without the WebSphere Process Server extensions, time-based versioning as described in this document is not supported.
The following section introduces you to best practices that can help you with versioning your business processes and human tasks.
Designing for change using versioning
To allow for future changes in your business processes and human tasks, you should consider versioning when you design your business-process-based applications. This section describes some best practices and patterns that prepare you for change.
Module boundaries and libraries
Components that are changed together should be grouped into one module. In general, it is good practice to have a single process that is to be versioned in one module. Thus, a new version of this process can be introduced easily and the old version can be removed when it is not needed any more.
Put interfaces and business object definitions for process and task versions in a library. This library is used whenever a new version is introduced.
To create a library in WebSphere Integration Developer, right-click in the Business Integration view and select New => Library.
Figure 11. Create a new library in WebSphere Integration Developer
Business rules
Rules logic is likely to change over time. So, instead of directly coding rules logic into your business process logic, provide rules logic as business rules, and call them from your business processes. Business rules can be changed dynamically at runtime and these changes apply immediately. Thus, you do not need a new version of the business process when a change to the rules logic is required.
For further information on business rules and how they can help you solve the dynamicity aspects of business processes, refer to the IBM WebSphere Integration Developer and WebSphere Process Server information center.
Business processes and subprocesses
When you design a long-running process, consider implementing the parts of your process that are likely to change as subprocesses. This allows even running instances of the parent process to pick up newer versions of these subprocesses. With late binding, the parent process instance calls the currently valid version of a subprocess when it reaches the subprocess invocation in its navigation.
Weakly-typed interfaces and business objects
Because interfaces and business objects used by these interfaces must be identical for all versions of a process or task, consider using weakly-typed interfaces. For parameters that are likely to change, you can, for example, use XML schema types, such as anyType, instead of a specific type. Support for weak typing using wildcards (xs:any) and unconstrained content (xs:anyType, xs: anySimpleType) was introduced in WebSphere Process Server V6.1.
This enables you to change types between different versions provided that the contract between clients and their process is still honored – changing types can mean changing clients too.
Versioning in WebSphere Integration Developer
A typical way of creating a new version is to copy the module that contains the previous version in WebSphere Integration Developer, and evolve your process or task from there. This ensures that a new module with a new module name is created. Module names must be unique within a WebSphere Process Server cell.
Refer to the WebSphere Integration Developer information center (see the Resources section) for more information on creating new versions of processes or tasks in WebSphere Integration Developer:
-
Business processes:
Creating a version of your process -
Human tasks:
Creating a version of your human task
UTC versus local time
The valid-from date and time specified in WebSphere Integration Developer for business processes and human tasks is specified in UTC. For example, if a developer working in Los Angeles wants a business process version to become valid at 10 a.m. local time (UTC-8), he has to specify 18:00 UTC in the business process editor.
Figure 12. Specifying a valid-from date and time in UTC
If a valid-from specification is not provided but the check box is selected in the editor, the valid-from field is automatically filled with the current date and time in UTC.
If you install a new version of a business process or human task, usually instances of the old version still exist. You cannot uninstall the old version as long as instances of that version exist because running instances still need to complete their processing, and finished, failed, or terminated instances might be restarted. Also, make sure that you keep all of the services that are used by these instances to allow them to complete.
To avoid new instances being created from an old version, stop the corresponding template. When no instances exist anymore, you can remove a template by uninstalling the corresponding enterprise application.
The following two patterns explain how arbitrary SCA components can interact with human tasks and business processes using late-binding. Note that clients interacting with tasks and processes through the BPC API do not need these patterns as the BPC API directly supports late-binding (see section Where early and late binding are supported before).
Proxy process for business processes
If an SCA component calls another SCA component, these components are statically bound, that is, a wired process component is called regardless of its valid-from date. The only supported combination for late binding is if a process component calls another process component. However, late binding can be extended to other SCA components or clients that should always call the currently valid version of a process component. This is done by adding a proxy process between the calling SCA client, for example, another SCA component or a Web service client, and the process. The SCA client is then statically bound to the proxy process; however the proxy process calls the currently valid version of the process dynamically using late binding.
Figure 13. Late binding for SCA clients using a proxy process
The implementation of the proxy process is simple. The process contains a receive activity followed by an invoke activity, and a reply activity that is needed only if the operation offered by the process is a two-way operation. Make sure that the reference partner of the invoke activity specifies a process template name. The interface partner and reference partner must both use the interface of the process to be called.
Figure 14. Proxy process implementation
The type of the proxy process depends on the type of the process to be represented. Because microflows perform better than long-running processes, use a microflow for your proxy process implementation if possible. The following table provides suggestions for when to use which type of proxy process.
Table 1. Provides suggestions for when to use each proxy process
| Type of process | Operation of the process interface | |
|---|---|---|
| one-way | two-way | |
| process is microflow | proxy process is microflow | proxy process is microflow (*) |
| process is long-running | proxy process is microflow | proxy process is long-running |
(*) If the process is likely to change in the future to a long-running process, use a long-running proxy process
Choose the type of the proxy process carefully because this process cannot be replaced easily. For example, if your process is a microflow with a two-way interface, you would normally implement the proxy process as a microflow. However, if a later version of your process becomes a long-running process, you will need to change your proxy process, too.
Decorator process for human tasks
Usually, SCA clients call human task components using an SCA wire, that is, they are statically bound to the corresponding tasks.
If an SCA component needs to call the currently valid version of a human task, the decorator process for human tasks pattern can help to achieve this. The general "decorator pattern" is a design pattern that allows adding new behavior to an existing component dynamically. This pattern uses late binding to invoke the currently valid version of a decorator process representing the actual human task, and thus it enables late binding to that task.
For example, if a process calls a human task in a late-bound fashion, it calls a decorator process using late binding, and in turn, the decorator process calls the task statically. The decorator process either contains the task as an inline task, or it invokes the corresponding human task component. The following figure shows an example of different versions of human tasks implemented as human task components.
Figure 15. Process calling a human task using a decorator process
The decorator process exposes the same interface as the task it invokes. Because human tasks are always asynchronous, the corresponding decorator process is typically a long-running process. For a one-way operation for the human task, you could consider using a microflow.
The decorator process pattern does not only apply to human tasks, however, it can also be applied to allow time-based versioning for any type of long-running, asynchronous service.
This article explained versioning concepts and best practices for business processes and human tasks in WebSphere Process Server to help you design business-process-based applications that are prepared for changing environments and future business needs.
Learn
- Find the product documentation you need for
versioning business processes and human tasks in the WebSphere Business Process
Management V6.1.2 information center:
Business processes
Human tasks
State machines - Find the product documentation you need for process
versioning in the WebSphere
Process Server V6.1.2 information center.
- Get started with a versioning example on the Business
Process Management Samples and Tutorials page.
- Read the developerWorks WebSphere article, Versioning
and dynamicity with WebSphere Process Server .
- WebSphere
application connectivity zone provides the latest technical resources for process and
application integration.
- WebSphere
Process Server and WebSphere Integration Developer resource page provides the latest
technical resources for Process Server and Integration Developer.
- General information
IBM WebSphere Business Process Management Version 6.1.2 information center
Architectural overview of WebSphere Process Server
Creating and wiring components
About business processes
About human tasks
Building business processes
Building state machines - Find a tutorial on the: Business Process Management Samples and Tutorials page
- Business Process Choreographer papers on developerWorks
- WebSphere Process Server Version 6.1 Business Process Choreographer Programming Model
Get products and technologies
- Download
IBM product evaluation versions
and get your hands on application development tools and middleware products from
DB2®, Lotus®, Rational®, Tivoli®, and
WebSphere®.
Discuss
- Participate in the discussion forum.
- Check out
developerWorks
blogs and
get involved in the
developerWorks community.
Juergen Neth is a software engineer at the IBM Development Laboratory in Boeblingen, Germany. He works on Business Process Choreographer in the WebSphere Process Server development team.
Table of contents
Next steps from IBM
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
