Body

 

There is an increasing tendency that more Business Process Manager (BPM) users are interested in creating an identical or similar deployment environment with current one for various purposes including testing, hardware migration, and disaster recovery etc. Starting from BPM 8.5.5, we officially recommend that you use our versatile command line BPMConfig -export/-create to clone any existing BPM deployment environment to fulfill your business requirements. And this article will cover the detailed steps for cloning a deployment environment and the typical scenarios on which you might want to consider using this approach. (Technically, the utility function is available for BPM 8.5.0.1 and later versions, but we did not fully test it until version 8.5.5.)

 

I. Detailed Steps Used To Clone A BPM Deployment Environment

The key principle behind our approach is to firstly export all of the configuration properties from source environment, then you can choose to modify the exported properties, and finally create a new deployment environment on a different BPM installation with similar or identical configuration settings. Please refer to the link ‘Creating a new deployment environment based on an existing configuration’ for more details.

Procedure:

1. Run command line BPMConfig -export to extract configuration data from an existing BPM deployment environment

Linux/Unix:

BPMConfig.sh -export -profile DmgrProfile -de DeploymentEnvironment1 -outputDir /home/user_name/DE1ConfigFolder

Windows:

BPMConfig.bat -export -profile DmgrProfile -de DeploymentEnvironment1 -outputDir C:\DE1ConfigFolder

 

** Please make sure you run this command under directory: BPM_Install/bin

** If there is only one deployment environment existing in the source cell, you could omit –de option.

** If there are more than one deployment environments, specify the unique output directory for each DE.

Expected Output Directory will be like picture below and the property file named De1.properties is the one we need to use for further editing.

 

 

 

2. Manually change the properties file exported or use IBM BPM Configuration editor to update the configuration properties to match your target deployment environment requirements.

** If you don’t plan to do hardware migration and keep connections to old databases, please make sure you at least modify your database information like host name, port, database name and schema to match the new DBs, and avoid sharing any BPM database between two DEs.

** IBM BPM Configuration editor can be only used on its supported OS platform. If your operating system is not supported by BPM Configuration Editor, you could copy its installation package to another machine that has the supported operating system running on it or just modify the property file directly using your text editor. Please refer to the link ‘Configuring your environment with the IBM BPM Configuration editor’ to check whether your OS is supported.

 

3. Save the updated properties file, keeping it in the same output directory. Copy the output directory to the computer where you want to create the new deployment environment.

 

4. Install a new BPM product binary on the machine where you want to create the new deployment environment.

 

5. Validate all database connections to make sure the modified database information is correctly configured.

BPMConfig -validate -db output_directory/updated_properties_file

** This command only validates that connections to the databases can be successfully established using the specified user names and passwords. It does not validate the contents of the databases, such as the schema.

** If you plan to use the new database, then please confirm the required databases (by default BPMDB, CMNDB, and PDWDB) are available before/after creating the database. If not, please check the link ‘Creating DB2/DB2for Zos/Oracle/SQL Server databases’ to generate the new databases.

 

6. Create the new deployment environment

BPMConfig -create -de output_directory/updated_properties_file

** If there are any remote nodes planned, please make sure this command will be run on each machine that hosts the managed nodes on it.

** If the property ‘bpm.de.deferSchemaCreation’ is set to true (by default), please make sure you run the generated database scripts manually and then run the command line bootstrapProcessServerData to load the database information to Process Server and Performance Data Warehouse.

 

 

II. Typical Scenarios

More importantly, we are going to introduce some typical scenarios where clients have used ‘clone DE approach’, to satisfy their various business requirements.

1. Build up a Testing Environment

Cloning an identical environment is particularly necessary for most users who need more than one testing environment to test their application's design and runtime implementation. Reducing the differences between two environments can be quite helpful on improving the testing accuracy and help you make correct decisions. Also a higher or lower environment with very similar configurations can always be used for complicated troubleshooting and help you avoid unnecessary downtime.

Besides, since BPM 8.5.5 we would encourage users to test their upgrade procedure before really getting started on production environments or other significant environments. Cloning an identical environment (and its databases) and testing the upgrade path beforehand, will increase the possibilities of a successful upgrade and eliminate some potential risks that you may not notice during regular maintenance.

 

2. Key Step of Hardware Migration

As the very first step of hardware migration, moving the current deployment environment from source to new hardware is exactly what we described above to clone an existing deployment environment on new hardware. Before BPM version 8.5.0, starting with dmgr, we used the command lines BPMSnapshotSourceProfile, BPMCreateTargetProfile, and BPMMigrateProfile to migrate the individual profiles one by one from source to target. It’s much more complicated. Sometimes, the synchronization issues happen when migrating different profiles.

The better use of our new command BPMConfig –export/-create dramatically removes the additional steps on migrating profiles. And the output properties files generated are relatively easy for reading and modifications.    

In addition, hardware migration does not only equal to clone a new deployment environment on new hardware, it also requires the migration of business applications and SIB messages (for Advanced and AdvancedOnly). The DE clone we are talking about only extracts the configuration data but not applications and SIB messages.

For more details about hardware migration, please check the link ‘Migrating IBM BPM to the same version on new hardware’ for more details.

 

3. Urgent Remedy for Installation Manager Data Corruption

First, the remedy point out here is referring to the partial hardware migration approach which does not need to clone new databases. This approach can only serve as a work-around for situations where you have no other solutions to recover your IM data. For example, if the Installation Manager data becomes corrupted during the installation of a new fix pack, and no IM backup is prepared. And users have to uninstall all of the installed packages as well as Installation Manager. In that case, if the hardware condition is acceptable, and only the BPM product is installed, moving the currently installed environment out and migrating all of its applications and connecting to old databases can be easily performed with the help of ‘BPMConfig –export/-create’ and the rest of the hardware migration steps. It can be treated as an alternative if the reinstall of BPM and Installation Manager have any problems.

 

4. Work-around for needs on Changing Database Schema or IP address

Another scenario I would like to cover here is that many users have requests about changing database information including database name, schema, URL, and port. Since BPM 8.5.6, we offered a new command option BPMConfig –update to modify the data source information like host, port, and DB name. However, the change on database schema is still not supported by current BPM functionalities. In this case, use the cloning DE path to create an identical new environment with modifications on database schema; this can be a good work-around to fulfill your specific needs.

 

5. Setting up a Secondary Site for Classic Disaster Recovery

From the perspective of planning and configuration of a classic DR topology, creating a new environment with exported configuration data can save more time on configuring a secondary DR site remotely. Also, BPMConfig –export/-create can ensure the configuration information is perfectly synchronized between the primary and secondary environment.

 

In short, cloning the deployment environment is indeed making better use of our versatile command line ‘BPMConfig’ and has been applied to more and more situations to help clients build up a similar environment in a much more effective and faster way.