Browse Prior Art Database

A method to perform version-to-version migration of Business Process Management (BPM) deployment environments using Business Process Execution Language (BPEL) runtime with HumanTasks. Disclosure Number: IPCOM000199928D
Publication Date: 2010-Sep-21
Document File: 7 page(s) / 442K

Publishing Venue

The Prior Art Database


A method to perform version-to-version migration of BPM deployment environments using Business Process Execution Language (BPEL) runtime with HumanTasks. Introduction Business process integration servers typically are built on top of application servers which provide the infrastructure for security, transactions, distributed computing, dynamic web engines etc. By making use of the infrastructure provided by application servers, components like BPEL engine, HumanTasks engine, Event Infrastructure services, Business Rules Engine etc. run the business processes and integration tasks. Each of these components make use of a database management system for persisting the runtime state of business processes, integration tasks etc. For example, BPEL engines run both micro-flows and long-running processes whose runtime state is persisted in a database. The Service Component Architecture (SCA) runtimes make use of a database to store runtime state of integration applications. The runtime databases contain not only meta-data about the business integration applications, but also the runtime state which helps to recover them in the case of outages. In business process integration server environment, the following databases are used to store not only the meta-data but also the runtime data. Common database: Stores environment configuration data, SCA runtime data, and recovery information. Business Process Choreographer database: Stores BPEL template meta-data and runtime data Event Infrastructure database: Used by Event Infrastructure services. It stores events generated by various SCA components and ready to be consumed by event consumers. Messaging databases: Stores messages that flow across various SCA modules through messaging system. There will be databases for other components that are extensions built on the standard specifications. Along with the above databases, the BPM deployment environments configured on business process integration server environment contain administrative components like Cells, Nodes, Profiles, Clusters, and Servers etc. The configuration data for these components spread across multiple systems. All these components are combined to form a topology for deployment environments that cater to non-functional requirements of businesses and help in organizing the administrative tasks. When a new version of business process integration server is released, customers are compelled to migrate to the new version. The migration process involves copying and transforming configuration and application data from the previous version to the new version. The new version is installed by the side of the old version and the migration process reads the configuration and application data from the old version and transforms it and moves it to the new version. In the migration process the BPM deployment environments from the previous version are moved to the new version of the business process integration server. The steps involved in performing the migration is as follows. 1. Take the backup of the databases 2. Install the new version of business process integration server across all the locations where the previous version is installed and migration is required 3. Migrate the Cell configuration 4. Migrate the Common database. 5. Migrate the Node configuration which are part of the Cell at all the locations. 6. Migrate the other databases. Business Process Choreographer database and utility databases. 7. Migrate the cluster level configuration 7. Synchronize the nodes 8. Start the migrated BPM deployment environment

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 46% of the total text.

Page 1 of 7

A method to perform version-to-version migration of Business Process Management (BPM) deployment environments using Business Process Execution Language (BPEL) runtime with HumanTasks.


Currently, the migration process can be done using GUI wizards or command-line tools provided by the particular business process integration server. However, manual intervention is required
to monitor the each task within the migration process. Migration process consists of several tasks as mentioned above. Each of these tasks produce log and trace files that can be examined to find out whether a particular task has been done successfully or not. Some of the tasks can be retried if they ever fail after fixing the errors notified in the logs. So, it is the responsibility of the person who is performing the migration to monitor the whole migration process and intervene accordingly until the entire migration process completes.

Drawbacks of this method are as follows.

1. A BPM deployment environment may span several nodes which are spread across several

physical machines. Users have to manually go to each physical machine and perform the

migration. Performing the migration from a central location is not possible.
2. There is no centralized monitoring of the whole migration process. Users have to individually monitor the whole process by looking into the logs/traces generated at individual locations.

3. If certain tasks fail, users have to examine the corresponding logs/traces to find out the cause and fix it before reinitiating the tasks manually.

4. If multiple deployment environments have to be migrated, it requires several administrations

performing and monitoring these migration instances.

5. Certain tasks will be performed depending on certain conditions met while performing the migration. Manually evaluating the conditions will be error prone.

6. Manually verifying the migrated environment is error prone and laborious.
7. Even though the individual tasks in the whole migration process can be carried out by the supplied migration tools and commands, users have to manually chart out the actual

procedure depending on the topology of the deployment environment being migrated.

8. After charting out the actual procedure, users have to manually execute and monitor it.


Consider an example deployment environment which has the following Cell,

Clusters and Databases created in a previous version of a business process integration server. This is called the source environment. The version to which the source environment is migrated is called target environment.


BPM Deployment Environment manager or Cell manager (Dmgr01)

Nodes, Profiles,


Page 2 of 7


Managed node (Custom01)

Managed node (Custom02)

Clusters: The cluster members of the each of the clusters mentioned below are distributed across the Custom01 and Custom02 nodes.

Application cluster:

             Hosts BPEL and HumanTask engines, WEB2.0 UI Engine, Business integration applications.