Deployment rules and guidelines

When you deploy all or part of an integration solution to an integration server, you must adhere to a number of rules.

Check the following list for any rules or guidelines for deploying all or part of your integration solution:
  • If you are deploying an application that depends on a shared library, you must deploy the shared library with the application or before you deploy the application.
  • If you deploy a message flow that is contained in an application or static library, the whole application or library is deployed. You cannot deploy a message flow on its own if the message flow belongs to an application or static library. You cannot delete a message flow from a deployed application or library. You must delete the flow from the toolkit application project or library and then redeploy the application or library. For more information, see Deleting a message flow or subflow.
  • You cannot store a message flow in a shared library.
  • If you deploy a message flow that contains a subflow that is defined in a .subflow file, you must deploy the subflow to the same integration server. You must deploy the subflow with the message flow or before you deploy the message flow.
  • If you redeploy a subflow that is defined in a .subflow file to an integration server, any message flows that use the subflow in that integration server are stopped and restarted. When the message flows restart, they use the updated subflow.
  • If you deploy an application or library to an integration server where the application or library exists, the existing application or library and its contents are removed before the new application or library is deployed.
  • If you are deploying a message flow that uses one or more Mapping nodes, see Deploying message maps.
  • If you are deploying a message flow that uses WebSphere® Adapters, see WebSphere Adapters resources.
  • Windows platformIf your message flows call .NET code from a .NETCompute node or from ESQL, you must distribute the assemblies to every integration server that uses these message flows. For more information, see Deploying .NET assemblies.
  • If your BAR file contains a mixture of resources that are compiled and resources that are not compiled, you might see unexpected results. For example, if you select the Compile and in-line resources option to create a BAR file that contains an ESQL file and a message flow, the ESQL is embedded in the compiled message flow (.cmf) file. If you then update the ESQL and add it to the BAR file with the Compile and in-line resources option cleared, the ESQL file is added as an individual resource, but the .cmf file uses the original ESQL because the original ESQL remains embedded in the .cmf file. To avoid confusion, select one of the following deployment options:
    1. Deploy all the resources (for example .msgflow, .subflow, and .esql) as source code.
    2. Deploy all the resources in the compiled form. This deployment method requires that all the subflows are implemented in .msgflow files. As a result, all the flow, subflow, and ESQL code is in-lined into the parent CMF file. This method does not allow the same flexibility as the source code deployment, but it does provide an unambiguous runtime behavior.
    For other limitations when you use CMF files, see BAR file contents: Message flows.