Deploying Process Apps

Deployment is the act of taking a process app designed in SBM Composer and making it available on the SBM Application Engine server. You can configure your system so that deployments occur directly from SBM Composer, or you can deploy from the Process Apps tab in SBM Application Repository.

Endpoint and Target Server Considerations

Note the following important information:

Although Application Repository automatically creates all system endpoints and also creates environment endpoints dynamically with each deployment, the environment endpoints require some human attention in case the "location hint" provided to Application Repository by SBM Composer does not match the SBM Application Engine endpoint.
If you deploy a process app that contains a Web service, and the defining .wsdl file contains an incorrect service location for the environment to which you deployed, you need to edit the endpoint in Application Repository to point to the correct service location and then redeploy the process app so the changes can take effect. (You may also want to get the latest changes back to SBM Composer.)
If you then clone the environment and deploy the same process app to the cloned environment using default settings, the new deployment will not use the existing endpoints that you edited; it will instead create new endpoints with similar names. These new endpoints will contain the service location from the defining .wsdl file, so you need to edit them (as you did in the original environment) to point to the correct service location for the Web service. (Alternatively, you can edit the deployment in the Deploy Options dialog box in SBM Composer to use the correct endpoints and delete the duplicate ones.) In either case, you need to redeploy the process app to the cloned environment so these changes can take effect.

Parallel Development Considerations

In a scenario in which multiple process app developers are working on process apps and there are multiple process app versions and patches, make sure that you do not undo someone's work that has already been deployed to the target environment (for example, as a patch to version 2.0 labeled 2.0.1) by deploying a process app version (for example, version 3.0) that does not contain that person's updates. If version 3.0 was developed directly from version 2.0 by User A, and meanwhile User B has created 2.0.1 as a deployed patch to version 2.0, the changes made by User B must be manually applied to the to the latest version before deployment.

The best approach is to always perform a "get latest" from the repository before deploying. This guarantees that you have the latest changes from other process app designers. If you don't do this, you risk undoing someone else's work. For example, a script might have been deployed by a co-worker and will now no longer be in production after your deployment.

If you want to make incremental changes to a process app currently running in an environment, the "patch context" feature enables you to do so. For more information, refer to the SBM Composer Guide.