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.
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.
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:
- Applications, including these design elements:
- Tables
- Fields
- Selections for Single Selection and Multi-Selection fields
- Application Workflows
- States
- Report Definitions
- Roles
- Orchestrations and orchestration workflows
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.
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.
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.
