Maintaining the IBM BPM system
This chapter describes how to maintain the IBM Business Process Manager (BPM) System. The following areas must be considered when you move to a higher version:
•Production binary
•Configuration
•Process applications
•Runtime data
A preferred practice is to upgrade or migrate to the latest IBM BPM version as possible. This update allows your organization to use the latest improvements and fixes. The production binary is owned by IBM and is automatically updated by the IBM Installation Manager when you upgrade or migrate to the new IBM BPM version. The configuration and the process applications can be set to default or modified to a specific version during this process. Interaction is required to maintain them to the new version. The runtime data that is generated in daily business must be transformed to the new format during the upgrade or migration.
Each version of the IBM BPM product includes an end of service (EOS) date. To ensure first-class support and better performance and new features, upgrade or migrate the IBM BPM environment before the EOS date. It usually takes months to complete a successful version-to-version migration. If the update is from an older version, the update process might take longer. A year or at least 8 months before EOS date to start a migration project is suggested.
For more information about product versions and EOS dates, see the following website:
This chapter includes the following topics:
3.1 Production migration and upgrade overview
One method for protecting your assets is staying current and using the newest versions of products through migration or an upgrade. The following assets are included in the process:
•Process application
•IBM BPM configuration
•Runtime data (such as process instances and tasks)
•System data (such as users and groups)
3.1.1 Terminology
The following terms are used in this chapter:
•In-place
This term refers to updating the artifacts and overwriting the original version. If the artifacts are in-place updated, the original version and new version do not coexist. Therefore, you must back up the artifacts in advance if you must roll back the in-place changes.
•Side-by-side
This term refers to updating the artifacts and writing to another location without overwriting the original version. Typically, the side-by-side updated artifacts do not need to be backed up in advance. The original version and the new version coexist. During a rollback of the changes, the side-by-side method is faster than the in-place method.
•Upgrade
This term refers to an in-place upgrade of the process server binaries and database. The in-place upgrade is completed without requiring any application migration or runtime database migration. The upgrade procedure is used to stay current with minor changes of different versions. It is also considered to be a lower risk and a faster function than migration.
•Migration
This term refers to those cases in which server binaries cannot be upgraded and a migration process must be used. The migration procedure manages the major differences between versions, such as when the underlying WebSphere Application Server version is changed and does not support upgrade from the older version. The IBM BPM configurations and the process applications (Advanced edition) are side-by-side migrated from the source version to the target.
The migration process typically involves converting the database to the new version. The conversion of the database is in-place and reuses the database instances rather than creating a target version database instance. Migrating IBM BPM might require that you upgrade the database instance to a higher version before the IBM BPM migration is run.
•Instance migration
Instance migration is migrating your process instances from one snapshot to another snapshot without IBM BPM version changes. For more information about instance migration, see 2.7, “Instance migration and application deployment” on page 25.
3.1.2 Migration and upgrade paths overview
In this section, the available migration and upgrade paths are reviewed. In each of the tables, the blank spaces indicate that there is no support.
WebSphere Process Server migration paths
Figure 3-1 shows the WebSphere Process Server for Mulitplatforms migration paths that are supported by each of the IBM BPM versions.
Figure 3-1 WebSphere Process Server for Mulitplatforms migration paths
WebSphere Lombardi Edition migration paths
Figure 3-2 shows the WebSphere Lombardi Edition (WLE) migration paths that are supported by each of the IBM BPM versions.
Figure 3-2 WLE migration paths
IBM BPM upgrade and migration path
Figure 3-3 shows the IBM BPM upgrade and migration paths that are supported by each of the IBM BPM versions.
Figure 3-3 IBM BPM upgrade and migration paths
3.1.3 Migration approaches
There are different migration approaches that can meet different migration expectations.
Migrating artifacts only
To migrate artifacts, create a parallel target production environment that is configured from scratch differently from the source production environment. After migrating the artifacts, you can modify your applications to use the capabilities that the new version of IBM BPM contains. You can then test and deploy the applications to the parallel target production environment. When the applications are deployed to the target production environment, the applications do not have access to the application data that is stored in the source databases.
Use this approach in the following cases:
•You must keep two systems running in parallel until all processes are completed.
•You are changing database vendors or changing the types of IBM BPM capability (such as from express to standard or from standard to advanced).
•Your business cannot tolerate a production environment downtime window to perform the migration.
The drain approach is an extension of migrating artifacts only. It keeps the source and target IBM BPM server in the production. This approach drains instances in the source and starts the new instances in the target. Drain is a powerful approach to solve the zero downtime requirement and is a minimal switch over risk. Because it does not include a switch over by your configuration, the new instances can still be started at the source IBM BPM server if you find anything wrong at the target.
The drain approach includes the following limitations:
•Process histories are not transferred to the new system.
•Parallel production environments require more maintenance and resources.
•Extra effort is needed to federate the portals of two systems or the user must tolerate the two portals.
Process Federation Server (PFS) can be used to federate the task list from different IBM BPM systems with the enablement of responsive portal. Responsive portal is new in IBM BPM v857, and makes work simpler. You can use the responsive portal to get the federated task list from the PFS and then work on these tasks at the same entry point.
Migrating business data and applications
To migrate business data and applications, you export the configuration information from your current environment (the source), modify it for your new environment, and transfer the modified configuration information into your new environment (the target). Then, you point to your databases from your new environment and update the databases.
Alternatively, you can clone your databases and use the cloned databases to test the migration before you migrate your production environment. When all applications are working in the new system, you convert the databases to make them compatible with the new system.
Use the migrating business data and applications approach in the following cases:
•You have long-running process or human task instances that started in the source environment and must complete in the target environment.
•You have product data in queues that were created in the source environment and this data must survive the migration and be managed in the target production environment.
•You want to move your applications to the target version without a dependency on the development tools and the development environment.
•Your business can tolerate a production environment downtime window to perform the migration.
|
An 18-month entitlement: IBM BPM recognizes that the SWG standard of 90-day dual entitlement might not suffice for large IBM BPM deployments that are performing IBM BPM version-to-version system migrations. If these migrations include long-running processes, you can acquire a pre-approved, 18-month extended migration agreement. For more information about this type of migration, see this website:
|
Application-by-application migration
You can migrate the runtime data one application at a time. The database method to use with this process is the side-by-side migration; therefore, the source and target IBM BPM environment can be available at the same time. The application-by-application migration is a service asset, and users should contact the IBM service team before starting this process.
Use this migration approach in the following cases:
•To avoid the risks of migrating all applications to a new version in a single batch.
•To reduce the maintenance window that is planned for the migration.
•To change the IBM BPM database from one vender to IBM DB2® distributed.
•To migrate only the selected data to the target (which avoids a data purge).
Migration decision maker tree
The migration decision tree for reference in selecting the migration approach that is most appropriate for your organizational needs is shown in Figure 3-4.
Figure 3-4 MIgration decision tree
|
Migrating runtime data and applications: To migrate the runtime data and applications, a 48-hour maintenance window often is planned. The migration procedure does not mean running only the migration steps. The following time considerations and procedures must be considered:
•Backing up the IBM BPM environment
•Running the regression testing
•Engaging a fallback plan if any unaccepted regression or failure occurs
If your maintenance window is compressed, consider the artifact migration method. In this method, the source and target IBM BPM environment run in parallel. Then, you drain out the instances at the source before you move to the new version of IBM BPM.
If you do not want a single process application that is run in two IBM BPM environments, you can consider the application-by-application migration method. Although this method still requires a maintenance window, the time is shorter when compared with migrating runtime data and applications.
|
|
Application-by-application method: The application-by-application migration method includes the following limitations:
•Only the migration of runtime data of Business Process Model and Notation (BPMN) processes and basic Case Management cases is supported. Business Process Execution Language (BPEL) applications cannot be migrated by using this tool.
•Data in an external IBM FileNet® Content Manager is not migrated.
•Does not support migration of the data at IBM DB2 for z/OS®.
•The source database host machine and the target database host machine must use the same time zone and system time. The IBM BPM source host machine and target host machine also must use the same time zone and system time.
•Contact the IBM service team to determine the support source version and the target version that you need. Updates are ongoing and at the time of this writing, the following paths are supported:
– IBM BPM V7.5.1.x to IBM BPM V8.5.6.0
– IBM BPM V8.0.1.x to IBM BPM V8.5.6.0
– IBM BPM V8.5.6.0 to IBM BPM V8.5.6.0
•This feature is an IBM service asset and support is provided as-is.
|
3.2 Readiness and planning for migration or upgrade
This section describes migrating runtime data and applications. The methodology that is described is similar for the application-by-application migration or upgrade process. How to plan a successful migration or upgrade project and reduce the risks that are involved also is described in this section.
3.2.1 Verifying your target environment
Verify that your target environment, including hardware, operating systems, and database prerequisites, is a supported operating environment for IBM Business Process Manager v8.5.7.
For more information, see these websites:
•IBM Business Process Manager Advanced system requirements:
•IBM Business Process Manager Standard system requirements:
3.2.2 Migration self-evaluation
When you start your migration, you must plan the migration as a project. Migrations are far more complex than simply completing the steps at the IBM Knowledge Center. Planning the migration requires months of work and preparation.
Perform a self-evaluation when you start planning the migration of your IBM BPM environments. This process includes consulting with your business sponsor to understand their requirements and expectations about the migration. The following self-evaluation questions can be used:
•How long of a maintenance window can the business tolerate?
•Are all of the process application sponsors ready for the migration?
•How many process instances in the database must move to the new version?
•How much monitor data (Performance Data Warehouse) in the database needs to move to the new version?
•What is the expected migration finish date, and does this date consider end of service times for IBM BPM versions?
Migrating the artifacts first
Before you attempt to migrate the runtime data, it is important to test if your process applications meet your expectations for running on the new version. If the migration motivations are based on fixes or new features that are provided by the new version, consider verifying that the new version resolved those issues. Consider the following aspects when the applications are tested:
•Compatibility
Although IBM BPM works to maintain compatibility with an earlier version as much as possible, the compatibility can be affected by the new features that are introduced or a bug fix. Test and verify all the important aspects of the application. Another best practice is to involve the user and acquire feedback about the behavior of the application that uses the new IBM BPM version.
•Performance
The new IBM BPM version features performance improvements in a major release. However, it is possible that some points of view or specific usage patterns might experience an unexpected performance downgrade when you test the applications. Most of the performance issues can be solved by tuning the performance and other issues might require the IBM support team to be involved.
•User experience
Version-to-version, the user experience might be changed, especially regarding the GUI. Be prepared to reeducate your users and familiarize them with the new GUI design before starting to use the new version of the IBM BPM.
•Deprecated feature and APIs
For each of the versions, you can find the deprecated feature or APIs in the IBM Knowledge Center. For more information about IBM BPM v857, see the following websites:
– Deprecated and removed features:
– New features:
|
Multiple versions: If your source and target version crosses multiple versions, see the following IBM Knowledge center website:
Select your BPM version, then select What's new in IBM Business Process Manager. At the bottom of the page, you can refer to the Deprecated and removed features of IBM Business Process Manager.
Database upgrade: When you upgrade your database to a higher level, you must upgrade your JDBC driver to the matched level.
|
From version-to-version, the IBM BPM might have some minor behavior changes. For more information about how IBM BPM v857 behavior changes when compared with v856, see the following websites:
– Process Portal:
– ECM:
Dry-run migration
As a best practice, dry run the migration before it is used in a production environment. Consider the following points:
•Practice the migration steps and troubleshooting.
•Write your migration cookbook.
•Estimate the maintenance window if you use the production clone as the dry-run environment.
•Create post-migration validation processes for the real data.
The clone is based on the UAT and production environments. If you plan only one environment for the dry run, the production environment is recommended. With a dry run of your production migration, issues can be detected that exist only within a production environment (such as data integrity, special configurations, and corrupted files).
Complete the following steps to clone the IBM BPM environment:
1. Stop the IBM BPM environment.
2. Replicate configuration data by cloning the WebSphere Application Server installation and configuration.
Strategies that accomplish this task by using file-by-file copies of the configuration data (from the source to the target) are called cloned cell topologies. The cell in the cloned IBM BPM environment is a copy of the cell that is in the original environment. The cell name, node name, and server names also are the same. The universally unique identifiers (UUIDs) that the WebSphere Application Server and IBM BPM code use to describe all the components of the cell also are identical.
If your transaction log is stored in the file system, it must be copied as a precaution. However, the first step is to stop the IBM BPM environment so that transactions in the IBM BPM system do not hang.
3. Clone the database.
The DB administrator can clone the database. Different database types might require different steps for cloning. After this step is complete, the administrator created another IBM BPM database instance. Be aware that the new instance is in another host and might be with another port.
4. Update the IBM BPM data sources in the cloned IBM BPM environment.
Starting with IBM BPM v856, you can use the BPMConfig –upgrade command to update the data sources that are used by the IBM BPM system.
For more information about this process, see the following IBM Knowledge Center website:
If your IBM BPM version is lower than v856, you must update the data sources by using the WebSphere Application Server administration console. The data sources that are shown in Figure 3-5 must be considered.
Figure 3-5 Data sources of IBM BPM
5. Change the host name and IP address mapping at the hosts.
If you have a DNS server, the host name in the IBM BPM configuration must point to the original IP address. You must map the host name in the cloned environment to its local IP address by editing the host file.
6. Stop the integration before you start the cloned IBM BPM environment.
If you integrate with any systems, the cloned IBM BPM server might insert or update data within these systems. In this situation, unexpected results might occur within the application system. To avoid this possibility, ensure that the integration stopped before the cloned IBM BPM environment is started.
Estimate the maintenance window
Estimating the maintenance window is key to planning your migration and affects which migration approach you select. For example, options are available if your business tolerates only a 12-hour maintenance window and the estimated maintenance window exceeds 24 hours. Instead of migrating the runtime data and applications, consider other solutions, such as artifact migration only or application-by-application migration.
The maintenance window includes the following steps:
1. Stopping the IBM BPM environment.
2. Backing up the IBM Installation Manager repository.
3. Backing up the database and the IBM BPM configuration.
4. Running the migration procedure.
5. Testing regression.
6. Rolling back the changes if you experience a failure and cannot resolve it in your remaining time.
The data volume in the IBM BPM database impacts the database backup time and the database upgrade time. If you can purge the data before migration, it can reduce the maintenance window significantly. Refer to Chapter 4, “Purging and archiving in IBM BPM systems” on page 51, for more detailed information.
3.2.3 Quiescing IBM BPM system
Quiescing the IBM BPM system ensures that you can receive a stable status before you migrate or upgrade the data. Consider the following points regarding quiescing the system:
•Do not install any other new process applications to the Process Server (PS).
•Turn off all incoming client requests:
– Stop user operations.
– If a front-end HTTP server is used, stop the flow of incoming HTTP traffic to IBM BPM.
– Stop the portal.
– Schedule an Event Manager blackout period.
– For JMS, IBM MQ, IBM MQ/JMS, and web services with SOAP/JMS inbound requests, refer to your operational procedures for more information about how to stop the applications that generate the request messages into queues.
•Allow messages get to a steady state:
– Wait until the eventqueue is empty and check that eventerrorqueue is empty (reprocess and delete any errors).
– Wait for all the following queues to finish processing (which might take a few minutes):
• DataDefLoaderQueue
• PostLoadCalculationQueue
• RepresentationManagerQueue (in WLE 7.x)
– Check that the errors queues are empty and reprocess or delete those error messages.
– For IBM BPM Advanced with JMS, IBM MQ binding, you can pause the processing of IBM MQ binding in the JMS messages. For more information about how to pause the messaging, see step 2a at the following website:
•Stop the Event Manager.
•Stop the Application cluster.
•Stop Messaging and Support clusters.
•Stop Deployment Manager and nodes.
3.3 Upgrading IBM BPM
Although upgrading is simpler than migrating the IBM BPM, upgrading still requires planning. For more information about migration, see “Migrating the artifacts first” on page 41, “Dry-run migration” on page 42, and “Estimate the maintenance window” on page 44.
From version 850 forward, IBM BPM followed an update only constraint on every new 8.5 release. Therefore, instead of migrating, you can upgrade your system after that release.
Compared to migration, the upgrade does not move artifacts side by side. Upgrading uses the following actions:
•In-place upgrade of the IBM BPM binaries.
•In-place upgrade of the database schema and transforms the data, if necessary.
•The profile is upgraded when the Dmgr starts.
In most cases, the upgrade procedure can be finished in 1 hour. However, regression testing time still needs to be factored into the maintenance window.
3.3.1 Rolling upgrade
You can roll out maintenance incrementally in an IBM BPM installation that consists of a Process Center and multiple Process Servers. This roll out allows for continuous running of production applications during the upgrade and regression test periods.
A rolling upgrade can be performed only when applying fix packs, refresh packs, or interim fixes. It cannot be used for migration between major releases.
Consider the following points regarding rolling upgrades:
•You can use rolling upgrade methodologies to upgrade your IBM BPM systems:
– In-place Rolling Upgrade
– Side-by-side Rolling Upgrade
•Do not upgrade the Development environment of your Process Center until you prove 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.
•The version of Process Center and Process Server must match for the Process Server to be connected as online.
•An application that is developed by using an older version of the IBM BPM product can be deployed to run on a newer version of IBM BPM if it is not using features that were removed.
•IBM BPM strives to maintain API compatibility in IBM BPM mod and fix pack releases.
•In IBM BPM 85xx, IBM BPM enabled the support of online rolling upgrades to facilitate the debugging of upgraded applications and allow a gradual roll out of the upgrades:
– IBM BPM 8500 Process Designer and Integration Designer can connect to IBM BPM 8501 of Process Center and Process Server (for debugging).
– A IBM BPM 8501 Process Server can connect in online mode to IBM BPM 8500 Process Center.
In-place rolling upgrade
In this procedure, you upgrade the Process Server (PS) first. Start with the Test PS, then the Staging PS. Next, the Production PS follows. Finally, you upgrade the Process Center Server (PC), as shown in Figure 3-6.
Figure 3-6 Process of in-place rolling upgrade
This process includes following advantages and disadvantages:
•Advantages:
– Upgrade and certify one Process Server environment at a time in an orderly fashion.
– Upgrade the PC last as you want to ensure you can continue to provide application fixes to the PS running at the current version.
•Disadvantages:
– Upgrading the PC last means developers cannot use new features until the entire system is upgraded.
– Except for 8501, any other upgrade forces the PS to go offline to the previous PC, which requires offline deployment until the PC is upgraded.
|
Note: Always take a full backup of your environment before the upgrade. The backup ensures the ability to restore any environment during this period in case an upgrade failed and cannot be fixed in the maintenance window.
|
Side-by-side rolling upgrade
In this procedure, you set up a new upgraded PC side by side and then proceed to upgrade each of the PS environments, as shown in Figure 3-7.
Figure 3-7 Procedure of side by side rolling upgrade
This process includes following advantages and disadvantages:
•Advantages:
– An upgraded PC is available immediately for new development and tests.
– Customers can certify new product versions on a per-application basis without affecting development and test environments.
– All Process Server environments can maintain online status all of the time.
•Disadvantages:
– The set-up for a side-by-side upgraded PC requires more IT resources and might incur extra licensing costs.
– Might require more work if the customers’ configuration is not well-documented.
– Depending on the approach that is used to set up the side-by-side PC, playback instances data can be lost.
3.3.2 Estimating the upgrade time
Before planning the upgrade, use Figure 3-8 to estimate the maintenance window. The times that are in the table are based on experimental data.
Figure 3-8 Estimate the upgrade time
3.4 Topology refactoring
In this section, the following definitions within topology refactoring are described:
•Number of clusters, such as changing a four-cluster topology to a three-cluster topology
•Number of the nodes in IBM BPM cluster, such as horizontal extension – add node
•Managed node location, such as moving the node from Windows to Linux
•IBM BPM database type, such as changing the database type from SQL server to DB2
•IBM BPM database location, such as moving the database from Windows to UNIX
•IBM BPM edition, such as shifting from Standard to Advanced edition
•Cell location, such as moving the whole cell to different machines
3.4.1 Changing the number of clusters
Each of the IBM BPM versions has a recommended topology. For example, in IBM BPM v857 three clusters is the recommended topology. If you are operating on an older version, you can notice immediate benefits in the use of the recommended topology in your target version. The migration can include the topology change.
3.4.2 Adding a node in a cluster
Notes can be added to increase the performance of the IBM BPM. For example, if only one or two nodes are in the cluster that uses most of the CPU and memory resources in the machine, consider horizontally extending to new hardware by adding nodes.
Complete the following steps to add nodes in a cluster:
1. Add new managed nodes.
a. Create custom nodes on the new machine by using the Profile Management Tool (PMT)
|
Note: Select the federated option later in the creation wizard.
|
b. Federate the node in the deployment manager. For more information, see the following website:
2. Add managed nodes to the cluster:
a. At the WebSphere Application Server admin console, click Deployment Environment → DE_NAME → deployment topology panel.
b. Choose the new node in the drop-down node list, and click Add.
c. Edit the number of Application deployment targets (if you have single cluster). The number indicates how many cluster members you must create on the new node.
d. Click Save.
3.4.3 Managing node location
In some instances, you might need to move the IBM BPM node to another powerful machine. This move can be needed because of the limitations of CPU, memory, I/O of the current machine, or changing operating systems (such as from Windows to Linux).
To move the IBM BPM node, follow the steps that are described in 3.4.2, “Adding a node in a cluster” on page 48. However, you want to remove (instead of add) the node by using the Deployment Environment.
3.4.4 Changing the IBM BPM database type
If you want to change your database type, use the artifact migration or the application-by-application migration for this process.
The artifact migration can change from or to any database type. However, it cannot maintain your processes at the target database. Therefore, you cannot access the process instances and monitor data in the target IBM BPM system. All runtime data is left in the old system and drains out. For the development PC, migrate individual application artifacts by exporting active snapshots (in chronological order) from the source environment to the target environment.
For the applications that must keep the runtime data in the target IBM BPM system, use the application-by-application migration method. This method changes the database type to the DB2 distributed database only. It does not support change to other database providers. This process has other limitations. For more information, see section “Application-by-application migration” on page 39.
3.4.5 Changing the IBM BPM database location
You might need to change your IBM BPM database location; for example, when moving to a powerful machine or to another operation system. Contact your DBA or database provider to move the database to another machine.
After the database location is changed, you can reset the data sources for the IBM BPM by using Step 4 that is described in “Update the BPM data sources in the cloned BPM environment” in section “Dry-run migration” on page 42.
3.4.6 Changing IBM BPM edition
IBM BPM support changed the IBM BPM edition from Standard to Advanced. There are no upgrade paths to or from the Express edition or the Advanced - Process Server edition. If you have the express edition and must change to the Standard or Advanced edition, you must use artifact migration. Artifact migration cannot migrate your runtime data.
To upgrade from the Standard edition to the Advanced edition, use the following documents that are available in the IBM Knowledge Center:
•Upgrading a product installation from IBM BPM Standard to IBM BPM Advanced:
•Upgrading a deployment environment from IBM BPM Standard to IBM BPM Advanced:
3.4.7 Changing cell location
If one IBM BPM cell must be moved to different hardware, see Migrating IBM BPM to the same version on new hardware, which is available at the following website:
|
Note: If you are using version v850x, upgrade to the later version first to receive the support that is described in Migrating IBM BPM to the same version on new hardware.
However, support for changing the cluster topology is not supported. Single cluster topology cannot add clusters.
|
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.