Building BPM Assets into Composites

You can configure and run a build script that creates a composite and ACDL descriptor for specific process models. Deployer uses the resulting composite and descriptor files to deploy the process development assets as part of a deployment project.

Deployer does not deploy generation receipts when deploying Designer process models. The primary reason for this is that the generation receipt stores a logical-to-physical server mapping and the only information available to Deployer is in the composite file, which does not contain any mapping information.

When you regenerate a process, the regeneration process uses the mapping information to determine whether a logical server mapping has changed from the previous generation. If the mapping has changed, the regeneration process connects to the previous logical server and cleans up the process-related assets there (for example, deleting associated triggers and services), in addition to creating the new assets on the new logical server. With no generation receipt, this mapping information is not available and the clean-up procedure cannot occur.

Because repository-based deployment does not generate a generation receipt, when you deploy a process to a target environment using repository-based deployment, you cannot then redeploy that process using that target environment as a source for a runtime-based deployment project. In runtime-based deployment Deployer requires the generation receipt to determine dependencies. If you want to redeploy the process, you must first rebuild the process in the target environment.

Note:
If a user connects Designer to a target environment and regenerates a deployed process to servers other than those deployed to the original process, the wrapper services and triggers on the original servers are not deleted. Wrapper services and triggers are still generated on the new logical servers, and existing services and triggers on unchanged logical servers remain unchanged. You must perform a manual cleanup on old logical servers. If you do not, multiple triggers and services could run in the process.

If you regenerate a previously deployed process to the same logical servers, Designer creates a new generation receipt so that future regeneration processes are handled correctly.

When you deploy a process model, the associated process model image and icon images are not deployed with the model. As a result, any webMethods Monitor APIs that use the process or icon images will not perform as expected with the deployed process.

For a standard use in a defined deployment environment, configure the build properties in the build.properties file as described in Setting Build Properties. Run the master-level build script in the \bin directory of your installed Asset Build Environment environment as described in Running the Build Script.

Use the project-level build script, in which the build script is run in a process project directory. Running this build script is useful because process project directories can be located anywhere in a user’s file system (that is, outside the deployment environment). This approach enables you to create the composite and descriptor files in any process project directory, regardless of location. After the composites and descriptors are built, they can be moved or copied into a deployment repository and indexed by the build script in order to make them available to Deployer. Project-level build script behavior is governed by the build.xml file in the process project directory. For information about configuring the build.xml file, see Configuring the Process Project build.xml File.

Be aware that in either mode, the build script processes only those process projects that contain a build.xml file. Process projects without a build.xml file are ignored, even if a process model is explicitly named.

Software AG Designer adds a build.xml file to a process project automatically for projects created with Process Development version 8.2 SP1 and later. If a process project has no build.xml file, you can copy the build.xml file from any other project. If the build.xml was not modified in the originating project, you do not have to modify the build.xml file to copy it from one project to another.