Workflow Lifecycle

◷ Reading Time: 2 minutes

New

When an application launches a Workflow, a new instance of the model is created and will be started. If execution reaches any of the states below, the instance will be stored in a durable storage:

1. Suspended
2. Waiting

When the Workflow Instance is stored in the storage (e.g., hibernated because of Suspended and Waiting states), the control returns to the application. The application can communicate back to the instance using the Resume method by having the latest execution context whenever required. The execution context can be loaded automatically by using the Workflow Instance Id.

Workflow may not go into hibernation if there is no Task, Suspend or Timeout activity reached during the execution.

Communication

When control is returned to the application, it can then communicate with the Workflow for multiple reasons:

1. Querying about the available actions
2. Resuming to continue the execution

Resume

When resuming a hibernated Workflow Instance, the application can simply pass the Workflow Instance Id for the resumption and the Workflow Engine takes care of everything.

The application itself can manage the execution context for its workflow Instance. In this case, the application should Resume the Workflow by providing the Execution Context Object rather than the Workflow Instance Id.

Query

Querying the Workflow Instance allows the application to understand the state of the Workflow Instance and decide what to provide back to the users for their input. When a Workflow Instance is hibernated, by accessing the stored context your application can query about:

1. The step that put the workflow into hibernate
2. The available task that workflow is waiting for (parallel and sequential tasks)
   1. Receive Task
   2. Human Task
3. Acceptable Outcomes of the Tasks that the user can choose from

To query the Workflow Instance, the GetReceivers method can be used.

Format: Context.GetReceivers()