IBM Business Process Manager operation overview,

Part 2: Maintenance and migration

Allen Chan (avchan@ca.ibm.com)
STSM, IBM Blueworks Live and IBM BPM
IBM

23 September 2015

Wei Hua Duan (duanwh@cn.ibm.com)

Senior Software Engineer
IBM
Erich Fussi (fussi@de.ibm.com)
IBM BPM Configuration Architecture and Development
IBM
Shi Su (sushibj@cn.ibm.com)
Staff Software Engineer
IBM
Shuo Zhang (zhangs@cn.ibm.com)
Technical Lead, IBM BPM Migration
IBM
Werner Tod (wtod@de.ibm.com)
IBM BPM Consultant
IBM
Part 2 of this series gives an overview of the maintenance and migration steps that
administrators for IBM Business Process Manager (IBM BPM) complete in their daily
operation work. The maintenance of a clustered server environment for IBM BPM that interacts
with many back-end and front-end systems and services can be a challenging task. The
overview and tips help administrators plan for and successfully maintain and migrate IBM BPM
systems.
View more content in this series

Copyright IBM Corporation 2015

IBM Business Process Manager operation overview, Part 2:
Maintenance and migration

Trademarks
Page 1 of 13

developerWorks

ibm.com/developerWorks/

Introduction
To help you maintain a clustered server environment for IBM BPM that interacts with many backend and front-end systems and services, this series provides an operation overview to guide you.
Part 2 introduces the following operations for IBM BPM:

Maintenance
Snapshot management
Instance migration
Product migration

Try the Workflow service

Create long-running, stateful workflows that orchestrate tasks and services with synchronous
or asynchronous event-driven interactions with the Workflow service from Bluemix. Try it for
free!

Note: This operation overview covers IBM BPM on Microsoft Windows, Linux, and UNIX
platforms (including AIX and Solaris).
In Part 1 of this IBM BPM operation overview series, you learned about topology, security, and
basic administrative and monitoring operations. Part 2 introduces maintenance and migration
tasks.
If you are using IBM BPM on Cloud, the IBM BPM on Cloud operation team is responsible for
managing the operations of the system and you can work with that team to apply product fixes or
upgrades. Learn more about the unique aspects of managing the IBM BPM on Cloud environment
in Part 3 of the series.

IBM BPM product maintenance and upgrades

To keep a healthy production environment, IBM BPM administrators should complete the following
regular maintenance operation tasks to update, upgrade, and migrate:
Updates: Whenever an interim fix or a fix pack is available, operators should complete an
in-place update procedure to update the product binary files and also a profile update, if
necessary for the fix. Typically, interim fixes do not require database schema updates.
Upgrades: Recent IBM BPM releases greatly simplified the upgrade and migration policy, so if
you're using IBM BPM V8.5.x, moving to a newer version of IBM BPM V8.5.x requires only an
in-place upgrade. You don't need to migrate the application or data.
Migration: If you're using IBM BPM V8.0 and earlier, moving to IBM BPM V8.5.x requires only
a side-by-side product migration. You need to install an IBM BPM V8.5.x system on the side,
and then you migrate applications and data from the old IBM BPM system to the new one.

Updates
Monthly, review the list of recommended interim fixes and schedule regular maintenance to apply
them. For example, see the list of recommended fixes for IBM BPM 8.5.6. In addition, it is also
important to review the list for specific fixes that that apply to current applications and schedule a
time to apply and test them.
IBM Business Process Manager operation overview, Part 2:
Maintenance and migration

Page 2 of 13

ibm.com/developerWorks/

developerWorks

In addition, subscribe to security bulletins and flashes as described in the Keeping up to date
with security fixes blog entry. IBM BPM 8.5.x has the most up-to-date security policy and
implementation, so create a plan to move up to the the IBM BPM 8.5.x releases.
When a new interim fix or fix pack is available to apply on your system, make sure that your
update process is well planned.
Include the following plans in your update process:
Test the upgrade in a QA system first, before you apply it to Staging and Production servers,
to avoid any unexpected interruption to your operation.
As part of the testing, make note of the time that is required so you can adjust your
maintenance window.
Back up the system before you apply any patches, and test any recovery procedures. Details
about backing up are discussed in Part 3 of this series.
Prepare a set of regression test cases so you can quickly validate the operation of the system
after you apply the fixes.
Set the date and time for the update, coordinate the maintenance window, and notify to all
stakeholders and users. This plan is especially important because the IBM BPM system
is often a component of a complete enterprise solution and other components might be
impacted.

Upgrades
Consider the following rules for upgrades:
You can use one of the following "rolling upgrade" methodologies to upgrade your IBM BPM
ecosystems:
An in-place rolling upgrade, typically used for interim fixes.
A side-by-side rolling upgrade, typically used for version upgrades.
The term "rolling upgrade" refers to the technique to roll out the update across the IBM
BPM ecosystems (for example, the set of Process Servers and Process Center). Within one
IBM BPM system (Process Server or Process Center), most updates require scheduling a
maintenance window to maintain consistency between product application code and the
database.
Do not upgrade your Process Center (your development environment) until you have at least
proved that the upgrade is working in your QA environment.
The version of Process Designer and Integration Designer must match the version of the
Process Center.
In general, the following rules apply between the older and newer version of IBM BPM:
The version of Process Center and Process Server must match before the Process
Server is connected as "online". IBM BPM 8.5.x and later releases relaxed this rule
to allow a newer version of Process Server to connect to an older version of Process
Center 8.5.x.
An application that you developed with an older version of IBM BPM can be deployed
to run on a newer version of IBM BPM, if the application is not using features that were
removed.
IBM Business Process Manager operation overview, Part 2:
Maintenance and migration

Page 3 of 13

developerWorks

ibm.com/developerWorks/

Check the product release notes for any deprecated features or changes in supported
environments, for example, operating system level and browsers.
If you have multiple Process Centers in your environment, consider the following additional rules
for upgrades:
If you need to export snapshots to another Process Center, always export from an older
version Process Center to a newer version Process Center.
You can have multiple installations of Process Designer or Integration Designer, but each
should be configured to communicate with a matching version Process Center.
The following images illustrate a few important upgrade scenarios in more detail.
The side-by-side rolling upgrade procedure that is shown in Figure 1 sets up a new "upgraded"
Process Center side-by-side, and then upgrades each of the Process Server environments. This
approach is recommended if you need to upgrade the Process Center first, but there are setup
costs and licensing implications.

Figure 1. Side-by-side rolling upgrade process

Depending on the scope of change, you can also complete an in-place rolling upgrade process
that upgrades Process Server first, as shown in Figure 2. The upgrade process continues through
from the test to production Process Server, and then upgrades the Process Center last.

IBM Business Process Manager operation overview, Part 2:

Maintenance and migration

Page 4 of 13

ibm.com/developerWorks/

developerWorks

Figure 2. In-place rolling upgrade process

Before you upgrade or apply fixes, always make a full backup of your environment (typically an
installation binary backup, a WebSphere Application Server profile backup, and the corresponding
database backup, or an operating system-level backup, described in Part 3 of this series). If you
have a backup, you can restore the system if there is an issue with the updates.
Figure 3 shows the procedures to certify the upgrade for Process Server, which means testing that
the server works correctly after the upgrade.

Figure 3. Certifying Process Server

Figure 4 expands the Upgrade <Env> task to show the sequence of applying an upgrade to an
environment.

IBM Business Process Manager operation overview, Part 2:

Maintenance and migration

Page 5 of 13

developerWorks

ibm.com/developerWorks/

Figure 4. Upgrading to IBM BPM V8.5.5.0

As shown in Figure 4, you need to make sure that the server is stopped correctly so that all
pending transactions are completed.
Complete the following steps to safely stop for Process Center and Process Server before you
upgrade:
1. Do not install any new process applications to Process Server.
2. Turn off all incoming client requests.
1. If a front-end HTTP server or load balancer is used, stop the flow of incoming HTTP
traffic flow to IBM BPM.
2. Schedule an Event Manager black-out period.
3. If you are using IBM BPM Advanced: For Java Messaging Service (JMS), Message
Queue (WebSphere MQ), Message Queue over Java Message Service (MQ/JMS), and
web service inbound requests, refer to your operational procedures on how to stop the
applications that generate the request messages into queues or calling the web services.
3. Let existing message queues get to a stable state before you upgrade, especially when you
complete a major upgrade.
1. Wait until the eventqueue is empty, and check that the eventerrorqueue is empty. If not,
reprocess or delete those errors.
2. Wait for the following queues to finish processing (this process might take a few
minutes):
DataDefLoaderQueue
PostLoadCalculationQueue
3. Check that the error queues are empty and either reprocess or delete those error
messages.
4. If you are using IBM BPM Advanced with a JMS or an WebSphere MQ binding, pause
processing of those messages by following step 2a at Technote 1610342
4. Stop the application cluster.
5. Stop the messaging and support clusters.
6. Stop deployment manager and nodes.

IBM Business Process Manager operation overview, Part 2:

Maintenance and migration

Page 6 of 13

ibm.com/developerWorks/

developerWorks

Figure 5 shows the procedures to certify the upgrade for Process Center, which means testing that
Process Center works correctly after the upgrade.

Figure 5. Certifying Process Center

Optimizing time during major updates and upgrades

By completing some upgrade tasks in parallel, you can reduce the time that is required for
upgrading and updating. Consider the following tips:
If your system has multiple nodes, you can run Installation Manager and back up the profile in
parallel across all nodes.
If you are updating a profile for each node, you need to stop all nodes. Run the update on the
deployment manager first, then start the deployment manager, and then run the update on
each node (and start the node) on a 10-minute delay.
For details about the specific IBM BPM upgrades, see the following resources:
The Profile upgrade instructions for IBM Business Process Manager Version 8.5 Refresh
Pack 5 IBM Support document
The Upgrading IBM Business Process Manager topic in the IBM BPM documentation on IBM
Knowledge Center

Understanding the development lifecycle: deploying and managing

snapshots
During the normal development process, new snapshots of a process application become
available in the Process Center, or they can be deployed to Process Servers.
IBM Business Process Manager operation overview, Part 2:
Maintenance and migration

Page 7 of 13

developerWorks

ibm.com/developerWorks/

A snapshot can be deployed to Process Server either by online deployment or offline deployment.
Many organizations choose to use offline deployment for a production systembecause the Process
Center is not typically able to access the production system. See Managing installed snapshots in
the IBM BPM documentation for the set of available actions to manage the snapshots.
As the number of snapshots accumulate, the efficiency of the system might suffer as it takes
longer for database queries to return due to the amount of data. It is important to define a policy
on how frequent to clean up unused snapshots from the system. See the Deleting snapshots on
process servers topic in the IBM BPM documentation.

Product migration and process instance migration

Process instance migration, also called in-flight process migration, refers to the migration of active
process instances from one snapshot of a process application to another, usually as a result of
installing a new snapshot of the application.
Product migration refers to the process of updating the IBM BPM runtime environment to a newer
version of the product, and moving applications and configuration information from an earlier
version of IBM BPM to a newer version of IBM BPM.
IBM BPM administrators need to understand and complete both of these kinds of migrations, as
described in the following tasks.

Migration and recovery of a business process definition process instance

Before you migrate the instance, complete the following steps:
1. To ensure that the new snapshot is compatible with instances that are running on older
snapshots, consider the guidance and strategies as described in Strategies for migrating
instances in the IBM BPM documentation.
2. To ensure that all possible orphaned tokens have an appropriate policy, generate an
orphaned token policy file.
3. To ensure that migration is completed successfully and within the allocated time, test the
migration in a QA environment with existing instances.
4. To minimize the risk of conflicts due to event firing during the migration, schedule an Event
Manager black out period.
In some situations, the process instances might fail after migration or during the course of normal
operation. In IBM BPM V8.0.1 and later, the Web Inspector includes improved the process
recovery options in the following ways.
If the failure is due to bad input data, administers can fix the input data and retry the task.
If a task permanently failed, administrators can fix the output data and skip the task.
For details about BPM Instance Data Migration and Recovery, see Migrating instances in the IBM
BPM documentation.
IBM Business Process Manager operation overview, Part 2:
Maintenance and migration

Page 8 of 13

ibm.com/developerWorks/

developerWorks

Migration and recovery of a Business Process Execution Language (BPEL)

process instance in IBM BPM Advanced
Similarly, if you deploy a new version of the BPEL templates, you have the option to migrate the
existing BPEL instances to it.
Before you migrate the instance, complete the following steps:
1. Consider the guidance and strategies as outlined in the BPEL process migration: Changes
to the business logic of a process instance topic in the IBM BPM documentation to ensure
the new template version is compatible with instances that are running on older template
versions.
2. Test the migration in a QA environment with existing instances to ensure migration can be
performed successful and completed within the allocated time.
In some situations, the process instances might fail after migration or during the course of normal
operation. Use the Business Process Choreographer Explorer to examine in-flight BPEL instances
and perform the appropriate recovery actions. See Getting started with Business Process
Choreographer Explorer and Business Process Archive Explorer in the IBM BPM documentation.

Product migration
If you are running IBM BPM V8.5.x.x, you do not need to perform a product migration going to a
higher version of 8.5.x. Just follow the procedures outlined for an in-place rolling upgrade in the
IBM BPM documentation in the IBM Knowledge Center.
Your decision on when and how to migrate should be driven by your organization's current
situation and specific goals relative to several key factors. See Choosing a migration approach in
the IBM BPM documentation for a discussion of the migration approaches.
If you are running a more recent version of IBM BPM, you can migrate your existing process
instance data to the latest version. If you are running an earlier version of the IBM BPM product
family such as Teamworks V6.0, WebSphere MQ Workflow, or WebSphere Interchange Server,
you can only perform artifact migrations (you can migrate source code to work with newer version
of IBM BPM, but you must let existing process instances run to completion in old system). See
Migrating to IBM Business Process Manager V8.5.6 in the IBM BPM documentation.
The migration of all environments must be properly planned. However, the migration of the
production environments is of special importance, because it also depends on the lessons learned
from prior environment migrations. To plan your migration properly, consider top practices to
ensure successful migration. See the Top practices to ensure a successful IBM Business Process
Manager migration presentation from InterConnect 2015.

Conclusion
In Part 2 of this IBM BPM operation overview series, you learned the following operations that are
necessary for an IBM BPM administrator: how to maintain your system with updates, fix packs,
IBM Business Process Manager operation overview, Part 2:
Maintenance and migration

Page 9 of 13

developerWorks

ibm.com/developerWorks/

and rolling upgrades, how to manage and migrate process model snapshots, and an overview of
process instance and product migration.
Read Part 3 in the series to learn about advanced operations such as troubleshooting,
performance tuning, archiving, and backing up - including an operation checklist.

Acknowledgments
The authors would like to thank Chris Richardson, Karri S Carlson-Neumann, Guo Liang Huang,
Phil Coulthard, Ryan T Claussen, Jens Engelke, Markus Reichart, Andy Garratt, Dave Hay, and
Eric Herness for their contributions and comments.

IBM Business Process Manager operation overview, Part 2:

Maintenance and migration

Page 10 of 13

ibm.com/developerWorks/

developerWorks

Resources
IBM Business Process Manager documentation on IBM Knowledge Center
IBM Business Process Manager Developer Center
developerWorks Business process management zone

IBM Business Process Manager operation overview, Part 2:

Maintenance and migration

Page 11 of 13

developerWorks

ibm.com/developerWorks/

About the authors

Allen Chan
Allen Chan is a Senior Technical Staff Member of IBM Smarter Process, and is
the currently the Chief Architect for IBM Blueworks Live and IBM BPM installation,
configuration and migration. Previously, he was the IBM BPM SWAT Technical Lead
where he led a team of experts to help ensure customer success in key IBM BPM
deployment and rollout scenarios. He is passionate about ensuring customers'
successful use of IBM products.

Wei Hua Duan

Wei Hua Duan is a senior software engineer and is currently the technical lead
for IBM BPM configuration development. He leads a team that works on IBM BPM
configuration, a key part of of IBM BPM server infrastructure. Prior to his current role,
he was the technical lead for Business Space migration development.

Erich Fussi
Erich Fussi works for the IBM BPM Configuration Architecture and Development
team.

Shi Su
Shi Su is a Staff Software Engineer and is currently a developer on the IBM BPM
migration team. Before joining the IBM BPM team, he worked in the IBM Banking
Industry Solution Lab and led design and delivery for a new generation e-banking
project.

Shuo Zhang
Shuo Zhang is the technical lead for IBM BPM migration. Shuo has developed strong
skills in Business Process Management and Business Integration areas since joining
IBM in 2003. Before he became technical lead of the IBM BPM migration team, he

IBM Business Process Manager operation overview, Part 2:

Maintenance and migration

Page 12 of 13

ibm.com/developerWorks/

developerWorks

also built team lead experience with WebSphere InterChange Server, WebSphere
Process Server, and Lombardi projects.

Werner Tod
Werner Tod works as IT Specialist and Senior IBM BPM Consultant in the
Technology Practice team at the IBM Germany Research and Development
Laboratories in Boeblingen, Germany. In this role, he covers a wide range of topics
throughout the IBM BPM lifecycle (requirements, architecture, design, application
development, installation, migration) and has applied those skills in numerous
customer engagements world-wide. Werner is the IBM BPM Migration Leader in the
IBM Services team.
Copyright IBM Corporation 2015
(www.ibm.com/legal/copytrade.shtml)
Trademarks
(www.ibm.com/developerworks/ibm/trademarks/)

IBM Business Process Manager operation overview, Part 2:

Maintenance and migration

Page 13 of 13