Activities

Activity is the first key object which composes a scheme. It determines the order, in which Actions are executed in your process. When they are executed, your process conducts efficient work and leaves artifacts in your system. If you open the Activity parameters window in Designer, the following properties are available:

• Name - it should necessarily be specified as far as all Activities are identified within a scheme by it. Besides, Name is case-sensitive and should be unique;
• State - the name of a particular state, which the Activity belongs to. It may be non-unique or even absent at all;
• Initial - if checked, the process will be executed starting with this Activity. There can be only one initial Activity in any scheme;
• Final - if checked, this Activity will be the final one within a process. In case of regular processes, it means that its status will be changed to finalized, and it may further be deleted or left in the system. Considering the subprocesses, they will be deleted automatically (read more in the Subprocesses section). A scheme may have any number of final Activities, or not have them at all;
• For set state - means that this Activity is initial for the state whose name is set in the State parameter. The process will be set to this Activity if you call the SetState method with the name of the state from the State parameter;
• Auto scheme update - enables automatic scheme update if the process is in this Activity. Refer to the Scheme Updates section for more details;
• Implementation - contains the list of Actions, that will be executed immediately after the process reaches this Activity. Each Implementation line includes the following fields:
  • Action - the name of the Action being called;
  • Action Parameter - a string value of the additional parameter conveyed to Action; may contain JSON. Read more about Actions in the Action Creation section.
• PreExecution Implementation - contains the same fields as Implementation. However, Actions in this section are called only in Pre-Execution mode.

State & Activity

Activity is a physical state of the process. When we need to clearly identify the stage of the process, we say what Activity it has reached so far. State is a business state of the process. One State can have a number of Activities belonging to it. Filling a State is optional.

If you want your process to have a "SomeState" state, which may be called via the GetAvailableStateToSet method and be set via the SetState method, the following conditions should be met:

• At least one Activity should have a State = "SomeState";
• One and only one Activity with a State = "SomeState" should have a 'For set state' checked. This Activity will be initial for this state. After calling the SetState method, the process will be set into this state, and if there are any automatic transitions, they will be executed immediately.

According to process transitions from one Activity to another, the following rules of state change are applied:

• If State of the Activity being executed is not filled - the current state does not change;
• If State of the Activity being executed is filled, and it is equal to the current one - the current state does not change;
• If State of the Activity being executed is filled, and it is not equal to the current one - the current state changes after the execution of all Actions listed in the Implementation section of this Activity.

Let's take a look at the examples.

For example, your document may exist only in three states - Created, Signing, Signed. Then, we have four Activities, because there's a timer which transits the document from the Signing state to an Activity, where a letter is sent, notifying that the document is being signed for too long. The SendNotification Activity does not have a State filled in, meaning that when the timer transits the document into it, the current state will not change. If you set For set state = true for Created, Signing and Signed activities, all three states will become available for setting. If you set the document into a Signing state via the SetState method, the timer will be reset and start counting the time elapsed from the moment the state was set. It is impossible to set the document via the SetState method in the SendNotification activity.

This scheme also has only three states - Created, Signing, Signed, but more Activities. After the process transits to the Signing Activity and executes all available Actions, its state is changed to Signing. Depending on conditions, it will further transit to one of the two Activities - SigningByManager or SigningByAccountant, but its state will change only after it reaches the Signed Activity. If you set For set state = true for Created, Signing and Signed Activities, all three states will become available for setting. If you change the document state to Signing via the SetState method, the process will automatically check conditions and transit to one of the two Activities - SigningByManager or SigningByAccountant. From the point of view of Workflow Engine, Signing, SigningByManager and SigningByAccountant Activities belong to the Signing state.

The State functionality might not be utilized. You may use it or not, it depends on your system requirements.

Activity settings in Default mode and Expert mode

An activity object properties can be customized easily in the Visual Scheme Designer (Modeller) by double-clicking on it. Once the object window is opened, there are two possible modes that can be used for working: the Default mode and the Expert mode.

1. In the Default mode, will be available the 'Implementation' functionality where might be created several Actions and its parameters. The parameters can be defined in 'Action parameter' field, and they might be customized through the JSON editor. For instance, an action 'FileDownload' for the activity 'Signing 'might be created. After that, the Action parameter values can be defined directly by clicking on the editor button, and then the required fields for downloading a file via FTP server can be filled out in the emergent window. The JSON editor may be used also to edit the values in this open standard format.

2. In the Expert mode, there is not only the default mode Implementation, but also the 'PreExecution Implementation'. It contains the same Actions as the 'Implementation' such as: 'GetInbox', 'HTTPRequest, 'SendEmail', 'CreateProcess', 'FileDownload', 'FileMove' and many others which might be used. Nevertheless, the Actions in this section are called only in Pre-Execution mode. In addition, Annotations can be created as well. These 'Annotations' are custom parameters or attributes that can be added in the form of a string or constant values. A more complex object might be aggregated by using the JSON editor. Moreover, 'Exceptions handling' may be created in a similar way, and the 'Timeouts' option is available also to be implemented in this mode.

   The 'Exceptions handling' in the Activity, it can be set to Error handling definition by listing the names of the exceptions that must be handled. Possible results to the exceptions are: Set Activity, Set State, Retry and Ignore.

   In reference to 'Timeouts', two possible options can be used: 'Execution timeout' and 'Idle timeout'. The first one, it is related to the limits of the execution time of all Actions of this Activity and the timeout value is the same as the interval timer value. An 'Execution timeout' can be defined also by considering an Activity, State, or it might be of the type Retry.

   In case of 'Idle Timeout', it refers to the limits of time that a process can be in this Activity without doing anything (for instance, Idled or Finalized status of the process). The timeout value is the same as the interval timer value. Possible results to timeout are: Set Activity, Set State.

   Be aware

   The Execution timeout only works for asynchronous Actions that process the Cancellation Token passed to them.

   The described options in Expert mode are indicated below:

   

   Once the process scheme has been executed:

   

   Furthermore, the Expert mode provides a property called 'Disable persist' which is available in the Activity parameters window in the Designer, and it can be enabled or not. It disables saving the state of the process to the database. In this case a customized set up can be done by disabling the following options:

   • Persist process state - everything related to the state of the process. It means the records in the table WorkflowProcessInstance.
   • Persist process parameters - that is, the registers in WorkflowProcessParameters table.
   • Persist transition history - thus, the registers in WorkflowProcessTransitionHistory table.

   Overall, performance enhancement is reached by implementing this feature. More information related to Persistence can be read here.

   

Major methods of utilizing Activity and State

• Getting current Activity, State, and executed Activity and State from ProcessInstance:

  ActivityDefinition currentActivity = processInstance.CurrentActivity;
  string currentActivityName = processInstance.CurrentActivityName;
  string currentState = processInstance.CurrentState;
  ActivityDefinition executedActivity = processInstance.ExecutedActivity;
  string executedActivityState = processInstance.ExecutedActivityState;

• Getting current Activity and State from WorkflowRuntime:

  ActivityDefinition currentActivity = runtime.GetProcessInstanceAndFillProcessParameters().CurrentActivity;
  string currentActivityName = runtime.GetCurrentActivityName(processId);
  string currentState = processInstance.GetCurrentStateName(processId);

• Gaining access to all scheme Activities:

  List<ActivityDefinition> activities = processInstance.ProcessScheme.Activities;
  ActivityDefinition initialActivity = processInstance.ProcessScheme.InitialActivity;
  ActivityDefinition someActivity = processInstance.ProcessScheme.FindActivity("ActivityName");

• Setting the process to an Activity. Unlike SetState, it works without filling in State:

  var parameters = new Dictionary<string, object>();
  var doNotSetRunningStatus = false;
  var activityToSet = processInstance.ProcessScheme.FindActivity("ActivityName");
  WorkflowInit.Runtime.SetActivityWithExecution(identityId, impersonatedIdentityId, parameters,
      activityToSet, processInstance, doNotSetRunningStatus);
  WorkflowInit.Runtime.SetActivityWithoutExecution(activityToSet, processInstance, doNotSetRunningStatus);

Difference between SetState, SetActivity and Resume methods

The SetState method is set simply by enabling the checkbox called 'For set state' that is available in the Activity window, and also filling out the field called 'State'. This method allows skipping the process from one state to specific one.

If the field 'State' is not set in an Activity, the process state is not updated when this activity is being completed. This method can only be called for Activities where the 'State' field is specified and the 'For set state' box is checked.

Another useful method that can be implemented is Resume. It is called when failures occur for resetting the system from a specified State. This method allows restoring the process from any available Activity or State. However, we suggest recovering from the current Activity or State. When a process is resetting from an indicated State, the implemented Actions are not executed once more.

If the SetState method called, the Activity and its Actions are executed and the process moves on. If for some reason the process workflow depends on this Activity state and the Resume method is called in this State, then the specified Actions in the Activity state won't be fulfilled, but the process will move forward.

The SetActivity method enables to run the process from any available Activity instead, and it may be used when statical analysis is required. Nevertheless, we do not recommend using this method or only exceptionally.

The SetState or Resume method can be used mostly.

example

An example that describes how these methods SetState, Resume and SetActivity can be implemented by creating a sample application is available in Tutorials section.