Concurrent Development

Version Control

In SBM Composer, process apps contain design elements that represent the smallest unit of design. Design elements include custom forms, workflows, rules, and tables. Each design element is independent and has its own version. You must check out a design element before changing it, so no other designer can work with a design element until you check it in again. However, you and other designers can work on different design elements in the same process app simultaneously.

When you check out a design element, it is stored in the Local Cache on your computer. When you check in a design element, its version is incremented and it is stored in the repository, which is a shared location that you and other designers can access. The repository supports standard version control operations, as described in Repository Menu.

Before publishing a process app, note the following:

• If you do not use the Get Latest command before publishing a process app, the repository may have newer versions of design elements than those in your Local Cache. By default, when you publish, you are prompted to specify which versions should be used.
• When the Get Latest option is selected, the older versions in your Local Cache are overwritten by the newer versions before publishing takes place.
• When the Ignore option is selected, the older versions of the design elements are published. The newer versions in the repository are not overwritten. You might use this option when you want to deliver changes that you have made to a process app without having to uptake changes made by someone else that might interfere with your tests or are not necessary for you to uptake at this time.

For information about setting these options permanently, see Repository Options.

Compare and Merge

SBM Composer provides the ability to visually compare two versions of a process app and manually copy selected additions and changes from one process app to another. The typical use case for this feature is customers who upgrade from one version of a solution to another and want to keep the custom changes they made to the process apps in the earlier version. In this way, customers can combine aspects of their design with aspects of the solution developer's design.

Patch Context

You can use a "patch context" to patch a production environment while continuing to work on a process app in a development environment. This involves opening the labeled version of the process app that was deployed to production. When you work in a patch context, the repository commands such as Check In, Check Out, and Get Latest are applied against the patch context label.