Workflow Lifecycle

From FlexRule Wiki
Jump to: navigation, search


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.

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


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


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


Info2.pngThe 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 then the Workflow Instance Id.


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()