Live Instance Management

The Live Instance Management API (also known as LIM) provides methods for migrating existing, active instances of a workflow that are executing on a particular version of the process definition to a different version of the process definition.

Here is an example: suppose that you can deployed V1 of a workflow design, and 10 instances of that workflow start. Each of these instances will continue running on the V1 definition of the workflow for their entire lifetime, even if you deploy V2 of the workflow design. By default, Workflows start on the "Default" version of the workflow and this is usually the last version that was deployed when the workflow starts. While you can use the K2 management tools to declare a different version to be the default version of a workflow, this will not affect active instances of the workflow.

Suppose that there was a problem in the design of V1 of your workflow. You have fixed the issue and deployed V2 of the workflow, but you need to migrate all the remaining 5 active V1 instances to the V2 definition. This is where the Live Instance Management (LIM) API comes into play. The LIM API provides methods for migrating active instances of workflows (and only "Active" instances or instances in "Error" state; instances in "Running" or "Completed" state cannot be migrated) to a different version of the workflow definition. Additionally, the API includes methods to manage how current activities are expired when issuing a GoToActivity command.

The primary functionality of LIM resides in the Sourcecode.Workflow.Management namespace. and this is the only API that exposes the necessary methods to migrate in-flight workflow instances from one version to another. Note that the operations in Sourcecode.Workflow.Management require administration rights on the K2 environment.

Additional functionality to manage how workflows handle GoToActivity commands reside in the Sourcecode.KO and Sourcecode.Workflow.Client namespaces. The additional operations in Sourcecode.KO are used in the "code-behind" for server events inside a  workflow instance to move to different activities. Sourcecode.Workflow.Client is used to interact with tasks on the connected user’s worklist to move to other activities.

The following list shows the current live instance management capabilities:

• Stop a process instance, set the Process Version for a specific Process instance. Do a GoToActivity from a stopped state with the option to expire all activity instances or only the specified instance, The Server will set the process instance in a running state, and the GotoActivity will be performed.
• Stop the process version in error state, do a GotoActivity with the option to expire all activity instances or only the specified activity instance. This will cancel the error state of that process instance. The Server will set the process instance in a running state, and perform the GotoActivity.
• Retry/Repair the process instance by using the existing Retry/Repair functionality, to continue the process on another Process Version.
• Open Process Instance in any state except completed state, Set Process Instance Version, and GotoActivity with the Option of Expiring all activity instances or only the specified activity instance.

Considerations

• When a process instance is in ‘Running’ status, it means that K2 server is busy executing code for the specific process instance. It is NOT possible to intercept the executing code, or to manage the process instance while it is in ‘Running’ status. Therefore, the only statuses supported for managing process instances are ‘Active’, ‘Error’ or ‘Stopped’.