Use command BPMConfig to Clone BPM Deployment Environment
YuanShang 27000723E1 Comment (1) Visits (11677)
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 220.127.116.11 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 ‘Cre
BPMConfig.sh -export -profile DmgrProfile -de Depl
BPMConfig.bat -export -profile DmgrProfile -de Depl
** 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.
** 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 ‘Con
BPMConfig -validate -db outp
** 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 ‘Cre
BPMConfig -create -de outp
** 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
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.
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.
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 BPMS
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 ‘Mig
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.
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.
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.