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.

IP.com Disclosure Number: IPCOM000199928D
Publication Date: 2010-Sep-21
Document File: 7 page(s) / 441K

Publishing Venue

The IP.com Prior Art Database

Abstract

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

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.

Problem

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.

Solution

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.

Cell

BPM Deployment Environment manager or Cell manager (Dmgr01)

Nodes, Profiles,

1

Page 2 of 7

Nodes:

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.

Supp...