This topic applies only to the IBM Business Process Manager Advanced configuration.

Considerations for multiple deployment environments in the same cell

Before you implement this advanced topology, there are several important things to consider.

Restriction: IBM BPM does not support the use of different database types between deployment environments in the same cell. IBM BPM also does not support the use of different service integration (SI) bus topologies between deployment environments in the same cell. All deployments environments must either use their isolated deployment environment-specific SI bus or share the legacy component-specific SI buses.

Isolation considerations

Consider how artifacts are shared between multiple deployment environments in the same cell.
  • The contents of the CellOnlyDB schema and the runtimes of the corresponding components (like Business Rules) are shared by all of the deployment environments. For information about the components that exist in the shared CellOnlyDB schema of the CMNDB database, see the topic Planning the number of databases for IBM BPM Advanced.
  • The Service Component Architecture (SCA) module names are cell-scoped, which means that the namespaces of the modules are shared across all of the deployment environments. For additional information, see the "Application considerations" section below.
  • The Module Browser widget can be used to list all the deployed SCA modules in a cell and select one for detailed inspection or administration. For more information, see the topic Module Browser widget.
  • In a multibus environment, such as a deployment environment that was migrated from WebSphere Process Server 7.0 or IBM BPM 7.5 or 8.0, the component-specific buses have the following naming conventions:
    Process Server
    PROCSVR.cell_name.Bus
    Performance Data Warehouse
    PERFDW.cell_name.Bus
    Business Process Choreographer
    BPC.cell_name.Bus
    SCA
    SCA.APPLICATION.cell_name.Bus and SCA.SYSTEM.cell_name.Bus
    These buses are shared among all deployment environments in the cell, which is not the case for the IBM BPM 8.5 deployment environment-scoped default bus BPM.de_name.Bus.
    Note: Regardless of whether the service integration buses are shared, the messaging engines are not shared between deployment environments.

Application considerations

Consider how applications are used with multiple deployment environments in the same cell.
  • You cannot install two instances of the same Service Component Architecture (SCA) application in the cell with the same name. You can install many SCA applications, but they must have different module names. How you provide them with unique names in the cell depends on how you are installing the module into the deployment environment:
    • If module is a stand-alone module, use the -uniqueCellID parameter in serviceDeploy utility to give it an unique identifier within the cell.
    • If the module is advanced content within a process application, set the AdvancedDeploymentDEScoped property for each deployment environment. By setting this property, the deployment environment name is automatically added to the module name to create a unique name for the module in the cell.

      For information, see the step that describes how to set the AdvancedDeploymentDEScoped property in Isolating deployment environments.

  • For late binding to work, new versions of a BPEL business process or human task (template) must be deployed to the same deployment environment as the earlier version. The correct target to bind to must be found in the same deployment environment. Make sure that parent-child relationships between processes or between human tasks are scoped to the deployment environment. There are some relationships, like parent-child flows, that should not cross JVMs.
  • Each Process Portal has one view to each deployment environment and requires unique context roots. Consider whether to use a different web server for each deployment environment. If not, you must provide different virtual hosts to ensure unique context roots for applications.

Administration considerations

Consider how administration works with more than one deployment environment in the same cell.
  • Each application cluster must have a corresponding support cluster and messaging engine cluster.
  • Selecting the correct failed event manager to retry events might be difficult when you have more than one deployment environment.
  • You must ensure unique names for all applications that contain SCA modules such as BPEL processes, calendars, rules, selectors, and relationships.
  • You must ensure unique names for IBM BPM applications as well as for customer applications.
  • You must add databases and schemas for each set of clusters, which increases administration responsibilities. Each set of clusters requires databases and schemas for:
    • Process database
    • Performance Data Warehouse database
    • Common database at the deployment environment level

Maintenance considerations

Maintenance is more difficult with more than one deployment environment in the same cell.
  • If there is an issue with one application in the cell, it is not possible to apply an interim fix only to the affected deployment environment. Interim fixes affect all servers, deployment environments, and clusters in the cell. Fixes for one application might have an unanticipated effect on the other applications that are running in the cell.
  • Testing an interim fix from IBM is more difficult when several deployment environments are in the same cell. Separate cells help ensure that fixes do not break other applications.
  • You might have to bring down all your servers to apply interim fixes for one set of clusters, resulting in downtime across all the sets of clusters using the cell. Although the exact arrangement of servers varies, a common arrangement of servers is to have one member of each cluster on each node. In such an arrangement, all servers and cluster members that share the node are affected by the steps to apply the interim fix.
Parent topic: Expanding your topology