BPM lifecycle for ARIS models in IBM Business Process Manager V8.0, Part 2: Merging a newly imported process version with an executable one

This two-part article series focuses on a practical approach for a standard-based, cross-tooling, and cross-vendor business process management lifecycle that implements ARIS Event-driven Process Chains (EPC) models in the IBM® Business Process Manager suite, as they were created within its own repository. Part 1 describes two ways of importing process models from ARIS into IBM Process Designer via a standard BPMN2.0 import as as well as in the ARIS XML format. Part 2 shows how to merge a newly imported ARIS model version with the already extended and executed process in Process Designer.


Plamen Kiradjiev (kiradjiev@de.ibm.com), Executive IT Architect, IBM

Photo of Plamen KiradjievPlamen Kiradjiev is an IBM Executive IT Architect with a strong background in business process management, application integration, and complex IT environments. He has been working with IBM since 1995, first with Global Services, and then in 2004 with Software Group Technical Sales with a focus on the Automotive and Public sectors. Plamen invested several years in methodology, tools, and best practices for integrating ARIS with WebSphere as well as led and advised dozens of client engagements in that area.

Matthias Diester (matthias.diester@de.ibm.com), IT Specialist, IBM

Photo of Mathhias DiesterMatthias Diester is an IT Specialist with IBM Software Services for WebSphere in Germany. His focus is on software development, especially in connection with WebSphere Application Server. Matthias joined IBM in 2006 after graduating from Stuttgart University of Cooperative Education in Germany.

20 June 2012

Also available in Chinese


The ability to import and execute process models that are created in external tools, such as ARIS, is key to leverage your legacy process models, which have been documented for years, is by optimizing and automating them with IBM Business Process Manager (IBM BPM). ARIS, specifically ARIS Business Architect, is a popular modeling tool that uses Event-driven Process Chains (EPC) for documenting business processes. An important aspect is the ability to handle changes imported from the external process repository in an efficient way. In contrast to extending the process within the IBM BPM Repository when you develop the next version, importing from external repositories requires you to merge the current version with the newly imported one. This is often referred to as "round-tripping". There are different approaches to implement round-tripping:

  • Bidirectional round-tripping: This enables you to merge both in the source (business) repository and in the IT repository. This is the most flexible, but also the most complex implementation of round-tripping. An example is the integration of IBM WebSphere Business Modeler and WebSphere Integration Developer in version 7.
  • Backward round-tripping: This allows changes in the IT repository to be compared and committed or rejected on the business side. A typical example is here the round-trip approach between ARIS and webMethods. This provides the ability to decide which IT changes can be accepted and which cannot, exposing unfortunately, the business user to the complexity of IT. Another problem here is how to handle IT-initiated changes that are rejected on the business side.
  • Forward round-tripping: This is the approach chosen with the Merge utility and described in this article. The merge is performed on the IT side, which is the most native way of hiding unneeded complexity from the business user and making implementation-specific decisions at the right place. With the aid of the snapshot capability of IBM BPM Process Designer, the merge approach can be re-tried as shown below in order. This delivers the result of requiring the least manual changes on the deltas in the merged process model. An important advantage here, besides the simplicity and separation of concern between business and IT, is the consistency of the BPM methodology according to the principle that all process design changes start on the business side, while IT only provides the implementation-relevant extensions.

You can apply the Merge utility on any process model – imported as a standard BPMN 2.0 model (from any tool supporting the specification), or with the help of the Import framework, which is described in of this article series, synchronized from BlueworksLive. Part 2 of the article series describes how to merge the second version of the Stand-by Ticket process imported via the Import framework (refer to Part 1).

Importing the next ARIS EPC version

This section uses the Stand-by Ticket process prepared for execution from Part 1 of the article series and demonstrates the merged approach with a process version that has been improved in ARIS.

Extending the previous EPC version and exporting from ARIS

When executing the Stand-by Ticket process, the following inconsistency can be recognized, even if the ticket has been cancelled by the Service center via the customer directly. The Payment action is fired after passing the "24 hours before departure" event, as shown in Figure 1.

Figure 1. Process version 1 log with Payment execution after cancellation
Process version 1 log with Payment execution after cancellation

To correct this, a check has to be inserted after the task "Query and verify status", skipping the Payment when the ticket has been cancelled. This change is implemented in ARIS by adding an XOR construct (refer to Figure 2).

The result of the "Query and verify status" is checked and if ticket has not been cancelled 24 hours before departure, payment occurs. Otherwise, the process ends. Then, the EPC is exported as an ARIS XML file, standby2.xml, to the local file system (refer to Part 1 more details).

Figure 2. Changed process in ARIS
Changed process in ARIS

Importing ARIS XML into IBM Process Designer

After importing the ARIS XML file via the Import framework into the process application "Standby Ticket 2" (shortcut "STBY02") described in Part 1, the process now contains the fragment within the IBM Process Designer, as shown in Figure 3.

Figure 3. Process version 2 fragment containing the XOR check for cancellation
Process version 2 fragment containing the XOR check for cancellation

Run the Merge utility

Now, the Merge utility is called from the Process Portal under the URL of http://localhost:9080/portal (the local version used here is IBM BPM V8.0), as shown in Figure 4.

Figure 4. Calling the Merge utility from the Process Portal
Calling the Merge utility from the Process Portal

The following screens in Figure 5 and Figure 6 show the selection of the just imported process application:

  • "Standby Ticket 2" as the source.
  • The already existing process application "Standby Ticket 1" as the target.

The terms "source" and "target" here are used in that the "source" process will be merged into the "target" (existing) one.

Figure 5. Merge utility screen 1
Merge utility screen 1
Figure 6. Merge utility screen 2
Merge utility screen 2

Figure 7 shows the two process diagrams hierarchy with the recommended actions for the merge operation:

  • In the first section, the two process model representations can be compared.
  • The second one contains recommended actions regarding creating, updating, and deleting the process model elements.
  • The third one provides options and controls. Two important options are:
    • The ability to create a snapshot of the target process model that will be overwritten and thus reverting to this snapshot after performing the merge.
    • The option to choose whether or not to visually reorganize the diagram.
Figure 7. Merge utility recommended actions
Merge utility recommended actions

In the first run, you can select the default recommendations with the result that some of the lane details will be overwritten intentionally (refer to the Update task section in Figure 7). In order to avoid re-doing the updates in the lane details in process version 1, the process state can be reverted to the snapshot of V1.0 that was created in Part 1 of the article series. The Merge utility is then called again, this time clearing all four selections in the Update Task section and de-selecting the "Reorganize diagram" option.

Extending the process model and run

The result is the following process diagram shown in Figure 8, including the additional configured decision rule.

Figure 8. Resulting merged process, including the decision rule
Resulting merged process, including the decision rule

After running the playback, you can observe the intended behavior in the process log shown in Figure 9. The log shows the skipping of the Payment task when the ticket has been cancelled 24 hours before departure.

Figure 9. Process log showing no payment after cancellation
Process log showing no payment after cancellation

Note that the only manual change that was needed to be done was the setup of the decision rule for the added diagram element. All other implementation details have been taken over from the already implemented process in version 1. Therefore, no implementation work repetition occurred during the preparation of the process in version 2 for the execution.

Overview of the Merge utility implementation

The following section provides a short explanation of the Merge utility architecture and components, as well as some essential methods used during processing. The Merge utility is packaged as a Process Application. It consists of a Human Service called "Merge Utility Main Service", a series of Business Objects for internal procedures and common server-side JavaScript source code, which is referenced in a Server File definition. The Merge Utility Main Service is the main starting point to begin the merging of the two process applications. Several Coach and Server Script components form this main service, which can be logically divided into three segments: data input plus validation, comparison, and execution of the actual merge.

In the first step, a data gathering component analyzes the selected process applications to identify lanes, flow-objects, and their interaction. The Merge utility uses the internal APIs to create tree structures made of business objects, which represent certain parts of the process applications. These structures are used throughout the merge process.

The comparison of these tree structures is done in the component "compare projects". These components use server-side JavaScript functions to compare the differences in variable declaration, used participants as well as the lanes and their flow objects. Another component called "dependency check" then resolves possible dependencies, such as a creation sequence.

In addition to the user selection of which actions should be executed, a component called "perform merge" runs through the activity list and changes the internal structure of the target process application. You can use an optional component to rearrange the service diagrams since the changes might lead to unwanted line crossings.

Each component uses standard server-side JavaScript in conjunction with Java method calls against the Process Server instance. All internal tasks are stored in separate functions and can always be found at the beginning of the service implementation. Where possible, parameters of these functions are marked with type-specific compiler hints (for example, /*: TWObject*String :*/) to help with future adjustments or changes. As a general rule, type-specific compiler hints for Java objects typically point at the actual implementation, rather than an abstract definition or interface. The main reason for this is to use implementation specific functionality, which is not always accessible in a super class or interface.

To use the Merge utility, you have to download the Merge utility process application export (TWX) file, which is provided in the Download section of this article. You can easily import this TWX file into your Process Server instance using the IBM Process Designer. In Process Designer in the Process Center view, you will find a "Import Process App" button in the upper right corner. To use the Merge utility as part of the Process Portal, check if the "Merge Utility Main Service" is exposed on the project page and the appropriate user. You will find these settings on the "Overview" tab of the service definition on the right-hand side. The Merge utility will start if you initiate this service in Process Designer or Process Portal. It uses the default browser to guide you through the merge process. Since the Merge utility utilizes the same functionality as Process Designer to edit the target Process application, it is crucial that the given user has the needed rights to perform these changes.


This article demonstrated how the Merge utility can significantly improve your productivity in the BPM lifecycle during process modeling, optimization, and execution. For ARIS business users, this forward round-tripping approach delivers separation of concerns between business and IT departments, avoids the repetition of previous versions performed IT adjustments, and provides flexibility, method consistency, and high efficiency by leveraging IBM Business Process Manager with other tools.


Merge utilityMerge_Utility.zip613KB
Test artifacts (TWX file)ARIS_TestAssets_part2.zip839KB



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Business process management on developerWorks

Zone=Business process management, WebSphere
ArticleTitle=BPM lifecycle for ARIS models in IBM Business Process Manager V8.0, Part 2: Merging a newly imported process version with an executable one