Lifecycle of a regular process

This section describes the order of execution of a process, beginning with the initialization of a process and ending up with it reaching one of the final states (which may not necessarily happen). This section addresses only basic processes; the lifecycle of a subprocess is a bit different.

Regular Process

In general, a process lifecycle comprises initialization and occasional execution of effective work triggered by commands, timers or forced setting of a certain state.

Initialization

Process initialization starts immediately after the WorkflowInit.Runtime.CreateInstance() method is called. The following occurs during initialization in the order specified:

  • Scheme Id is identified. In case the relevant scheme was not found in the WorkflowProcessScheme table (object), a new scheme is built. For more details, refer to the Scheme versioning and Scheme generation sections.
  • A new process record is made in the WorkflowProcessInstance table (object). The name of the Initial Activity is attributed to the CurrentActivity. The value of the State from the InitialActivity is attributed to the CurrentState.
  • In case parameters with Purpose=Persistence were conveyed to the process during initialization, or in case Persistence Parameters with Initial Values were declared in the scheme, they get stored in the WorkflowProcessInstancePersistence table (object). In this case, the parameters conveyed to the CreateInstance method will prevail. In other words, in case a "ParameterName" parameter with InitialValue = "Value1" was declared in the scheme, and the "Value2" value was conveyed to the CreateInstance method, the parameter value will be "Value2".
  • In case there are any transitions from the initial Activity that are triggered by timers with undefined values (0 or -1; refer to the Timers section), the runtime.NeedTimerValue event will be called to specify these timers' values.
  • Process status is set to Initialized; the runtime.ProcessStatusChanged event is called.

The process initialization is completed.

In case the Implementation section of the Initial Activity is filled in, or there are any transitions triggered by automatic timers, then:

  • Process status is set to Running; the runtime.ProcessStatusChanged event is called.
  • Execution process is started and begins with the Initial Activity.

In case there is no implementation and Auto transitions, then:

  • Process status is set to Idled; the runtime.ProcessStatusChanged event is called.
  • The runtime.ProcessActivityChanged event is called.
  • In case there are transitions from the Initial Activity that are triggered by timers, the timers are registered and start keeping the time.

Triggering process execution

When executing a command or a timer, the execution process looks like this.

  • A process instance is fetched from the WorkflowProcessInstance and WorkflowProcessScheme tables. In case the scheme already exists in the scheme cache, it won't be transformed into its object representation.
  • Process status is set to Running; the runtime.ProcessStatusChanged event is called.
  • All saved process parameters are fetched from WorkflowProcessInstancePersistence. If any parameters were conveyed to the command, these process parameters will be updated with command parameter values. Besides, the name of a command or a timer, IdentityId and ImpersonatedIdentityId are written to process parameters.
  • All outgoing transitions triggered by a command or a timer with the corresponding name are identified for the current Activity.
  • A transition is selected according to the following rules:
    • In case there is a transition with Condition = Always, it will be executed as a matter of priority.
    • The conditions of transitions with Condition = Action are checked. In case Action Condition (or multiple Action Conditions) returns true, such a transition will be executed. The order for such a check is not defined.
    • In case no transition was selected upon checking of the conditions, a transition with Condition = Otherwise will be executed.

In case a transition was selected:

  • an execution process is launched with the final Activity of the selected transition.

In case no transition was selected:

  • Process status is set to Idled; the runtime.ProcessStatusChanged event is called.

Process execution launched via SetState (SetActivity)

After a forced setting of a state, an execution process looks like this.

  • A process instance is fetched from the WorkflowProcessInstance and WorkflowProcessScheme tables. In case the scheme already exists in the scheme cache, it won't be transformed into its object representation.
  • The initial Activity for the set state is searched for (refer to the Activity section). The Activity with State = set state and For set state = true is identified. In case Activity was not found, the ActivityNotFoundException exception will be thrown. Depending on whether process execution is required or not (determined by call parameters of the SetState method), two options are possible.

If process execution is not required:

  • Process status is set to Running; the runtime.ProcessStatusChanged event is called.
  • Both the Current Activity and the Current State of the process are changed and saved in the WorkflowProcessInstance table (object).
  • Process status is set to Idled; the runtime.ProcessStatusChanged event is called.

If process execution is required:

  • Process status is set to Running; the runtime.ProcessStatusChanged event is called.
  • All saved process parameters are fetched from WorkflowProcessInstancePersistence. If any parameters were conveyed in the SetState method call, these parameters will be updated with conveyed parameter values. Besides, the name of the command="SetState", IdentityId and ImpersonatedIdentityId is written to the process parameters.
  • Execution process starts with the Activity being set.

Activity execution process

Activity execution process runs in the following order:

  • The runtime.BeforeActivityExecutionevent is called.
  • The following process parameters are set: the value of the executed Activity is attributed to ExecutedActivity, the state of the executed Activity is attributed to ExecutedActivityState. In case no state is specified, the value of the current state will be attributed to CurrentState.
  • All Actions specified in the Implementation section are called successively.
  • Upon successful execution of all Actions, CurrentActivity = ExecutedActivity and CurrentState =ExecutedActivity are set.
  • Process state is updated in the WorkflowProcessInstance table (object); a record of the executed transition (in case there is any) is made in the WorkflowProcessTransitionHistory table (object); the process parameters are saved in the WorkflowProcessInstancePersistence table(object).
  • The runtime.ProcessActivityChanged event is called.
  • All outgoing automatic transitions for a new Current Activity are identified.
  • A transition to be executed is selected based on the following rules:
    • In case there is a transition with Condition = Always, it will be executed as a matter of priority.
    • The conditions of transitions with Condition = Action are checked. In case Action Condition (or multiple Action Conditions) returns true, such a transition will be executed. The order for such a check is not defined.
    • In case no transition was selected upon checking of the conditions, a transition with Condition = Otherwise will be executed.

In case a transition was selected:

  • Execution process is launched with the FinalActivity of the selected transition.

    In case no transition was selected:

  • Process status is changed to Idled; the runtime.ProcessStatusChanged event is called.
  • In case there are any transitions from the new Current Activity that are triggered by timers, these timers will be registered and start keeping the time. Old timers get removed (refer to the Timers section).

Process finalization

In case a process reaches an Activity with the IsFinal = true attribute, then its status will be changed to Finalized instead of Idled after execution is completed. Besides, if the process is a root one (i.e. not a subprocess), it is not automatically deleted from the database. You may, for instance, return a process to one of the previous states via SetState (SetActivity). In case your business logic requires automatic deletion of finalized processes, use the following code:

runtime.ProcessActivityChanged += (sender, args) =>
    {
        if (args.CurrentActivity.IsFinal)
            runtime.DeleteInstance(args.ProcessId);
    };

or

runtime.ProcessStatusChanged += (sender, args) =>
    {
        if (args.NewStatus == ProcessStatus.Finalized)
            runtime.DeleteInstance(args.ProcessId);
    };

Error handling

In case an unhandled exception occurs during Activity execution, the execution process will be interrupted, while the process itself will remain in the previous Activity, i.e. its state won’t be changed. However, the process will remain fully operational. We recommend you to capture and handle exceptions inside the Actions code or in OnWorkflowError event. The event handler enables you to change a process state or send an error notification.

runtime.OnWorkflowError += (sender, args) =>
{
    Exception exception = args.Exception;
    ProcessInstance processInstance = args.ProcessInstance;
    TransitionDefinition executedTransition = args.ExecutedTransition;
};
Top