Working in a Patch Context

A patch context allows parallel and concurrent development to occur on the same process app, so that patches can be applied to production process apps as ongoing development of the main process app continues. When performing maintenance work, a designer can create a patch context by opening a published process app by its label.

The patch context serves as the baseline for the maintenance work. Any number of process app designers can do concurrent development in a patch context.
Restriction: Only one process app designer can work on a single design element at the same time.

Changes a designer makes when working in a patch context apply only to the patch context. They do not affect ongoing development of the head (tip) version of the process app.

Note: A patch context is not the same thing as a branch in a version control application.

Some changes can be made directly in a patch context. If you want these changes to also apply to the head version, make them manually in the head version. Other changes cannot be made directly in a patch context, and are described in the following section.

Adding Design Elements to a Patch Context

To protect against data loss, the following design elements cannot be added directly to a patch context:

You can, however, copy these design elements from the head version to the patch version. If a design element does not exist in the head version, create it there first.

Restriction: Applications and orchestrations are exceptions to this. You cannot add applications or orchestrations to a patch context, and cannot copy them from the head version.

When you right-click the design element heading in App Explorer in the patch context, and then select Add Existing <Design Element>, the Add Existing <Design Element> from the Head (Tip) Version dialog box opens. In this dialog box, select the design element that you want to add and then click the Add button.

Note: Design elements containing fields, states, tables, and so on in the head version must be checked in before you can copy these entities to the patch context.

When adding items from the head version, the parent design element in the patch context must be checked out. For example, to add a workflow from the head version, make sure the application in the patch context is checked out.

After a table, application workflow, report definition, or role is added from the head version, that version of the design element is immediately labeled with the patch label, and the parent design element in the patch context is checked in (and checked out again if it was previously checked out).

After a field or state is added from the head version, the field or state is simply added to the parent design element and the parent design element in the patch context is checked in (and checked out again if it was previously checked out).

Example of Working in the Patch Context

Version 1.0 of a process app is in production. Susan checks out Version 1.0 (the head version) to continue main development on the process app.

At the same time, a patch needs to be applied to Version 1.0 for customers using the process app in production. The owner of a state needs to change. Bill opens Version 1.0 by its label in the Open Labeled Version dialog box. The Version 1.0 label becomes Version 1.0 PATCH. Bill changes the owner of the state in the patch context (Version 1.0 PATCH).

Bill deploys Version 1.0 PATCH, and its label becomes Version 1.1. He manually changes the owner of the state in the head version so it matches the patch context. When he deploys the head version, its label becomes Version 1.2.

The Open Labeled Version dialog box resulting from this example is shown in the following illustration.


Related Topics

Create Patch Context Dialog Box

Open Labeled Version Dialog Box

Add Existing Design Element from the Head (Tip) Version Dialog Box