BPMN Elements :: Activities

 

Tasks

 

Abstract Task
Abstract Task represents a Task with no specialized behaviour.

 

User (Human) Task

User Task represents an atomic task to be executed by a human actor. It should have one incoming connection and one outgoing connection.

Life cycle – shortly:

Whenever a task is created, it starts in the Created stage. It usually automatically transfers to the Ready state, at which point the task will show up on the task list of all the actors that are allowed to execute the task. If you have already assigned the task to one user then the Task will transition to the Reserved phase. If you have not assigned the task to one actor, then the Task will stay in the Ready phase until an actor has claimed for it and then it will transition to the Reserved phase. Once in the Reserved phase, the user can then at some point decide to start executing the task, in which case the task status is changed to InProgress. Finally, once the task has been performed, the user must complete the task (and can specify the result data related to the task), in which case the status is changed to Completed.

Properties

A User Task contains the following properties:

  • Id: The id of the node (which is unique within one node container).
  • Name: The display name of the node.
  • TaskName: The name of the human task.
  • Priority: An integer indicating the priority of the human task.
  • Comment: A comment associated with the human task.
  • ActorId: The actor id that is responsible for executing the human task. A list of actor id’s can be specified using a comma (‘,’) as separator.
  • GroupId: The group id that is responsible for executing the human task. A list of group id’s can be specified using a comma (‘,’) as separator.
  • Skippable: Specifies whether the human task can be skipped, i.e., whether the actor may decide not to execute the task.
  • Content: The data associated with this task.
  • Swimlane: The swimlane this human task node is part of. Swimlanes make it easy to assign multiple human tasks to the same actor. See the human tasks chapter for more detail on how to use swimlanes.
  • On entry and on exit actions: Action scripts that are executed upon entry and exit of this node, respectively.
  • Parameter mapping: Allows copying the value of process variables to parameters of the human task. Upon creation of the human tasks, the values will be copied.
  • Result mapping: Allows copying the value of result parameters of the human task to a process variable. Upon completion of the human task, the values will be copied. A human task has a result variable “Result” that contains the data returned by the human actor. The variable “ActorId” contains the id of the actor that actually executed the task.

Human tasks can have a number of different states and substates. The state diagram for human tasks below shows the different states and the transitions between them.

 

Service Task

All work that is executed outside the process engine should be represented (in a declarative way) using a Service Task. Different types of services are predefined, e.g., sending an email, logging a message, etc. Users can define domain-specific services or work items, using a unique name and by defining the parameters (input) and results (output) that are associated with this type of work.

  • Id: The id of the node (which is unique within one node container).
  • Name: The display name of the node.
  • Parameter mapping: Allows copying the value of process variables to parameters of the work item. Upon creation of the work item, the values will be copied.
  • Result mapping: Allows copying the value of result parameters of the work item to a process variable. Each type of work can define result parameters that will (potentially) be returned after the work item has been completed. A result mapping can be used to copy the value of the given result parameter to the given variable in this process. For example, the “FileFinder” work item returns a list of files that match the given search criteria within the result parameter Files. This list of files can then be bound to a process variable for use within the process. Upon completion of the work item, the values will be copied.
  • On-entry and on-exit actions: Actions that are executed upon entry or exit of this node, respectively.
  • Additional parameters: Each type of work item can define additional parameters that are relevant for that type of work. For example, the “Email” work item defines additional parameters such as From, To, Subject and Body. The user can either provide values for these parameters directly, or define a parameter mapping that will copy the value of the given variable in this process to the given parameter; if both are specified, the mapping will have precedence. Parameters of type String can use #{expression} to embed a value in the string. The value will be retrieved when creating the work item, and the substitution expression will be replaced by the result of calling toString() on the variable. The expression could simply be the name of a variable (in which case it resolves to the value of the variable), but more advanced MVEL expressions are possible as well, e.g., \#{person.name.firstname}.

 

Send Task

A Send Task is a simple task that is designed to send a Message to an external Participant. Once the Message has been sent, the Task is completed. The actual Participant who sends the Message can be identified by connecting the Send Task to a Participant by using a Message Flow. Examples of a Send Task are as follows:

  • Inform the collaborator that the process is finished,
  • Send a document to the customer,
  • When the book is published, inform the author.

Send Task has the same behaviour as a throwing intermediate message event. However, when using a Task, one is able to attach a boundary event to capture the Task’s exception conditions.

Eclipse BPMN2 Modeler:

 

Receive Task

The Receive Task is the opposite of the Send Task. It is a simple Task that is designed to wait for a Message to arrive from an external Participant (usually another BPMN Pool). Once the Message has been received, the Task is completed. The actual Participant from which the Message is received can be identified by connecting the Receive Task to a Participant using a Message Flow. Examples of a Receive Task are as follows:

  • Wait for author’s approval before continuing with the
    publishing process,
  • Wait for customer information to resolve an open issue,
  • Begin with the delivery process as soon the shipping address
    is approved.

Eclipse BPMN2 Modeler:

The analogue to Send Task, a Receive Task has the same behaviour as a catching intermediate message event. However, a boundary event can be attached to a Receive Event to capture a Task’s exceptions.

 

Manual Task

A Manual Task is another type of BPMN Task which requires human involvement to complete. In contrast to a User Task, a Manual Task is a Task that is expected to be performed without the aid of a business process execution engine or application. A Manual Task provides no system interface to the performer, so it is inherently not executable in a BPMS.

 

Business Rule

A Business Rule Task Represents a set of rules that need to be evaluated. The rules are evaluated when the node is reached. A Rule Task should have one incoming connection and one outgoing connection. Rules are defined in separate files using the Drools rule format. Rules can become part of a specific ruleflow group using the ruleflow-group attribute in the header of the rule.

When a Rule Task is reached in the process, the engine will start executing rules that are part of the corresponding ruleflow-group (if any). Execution will automatically continue to the next node if there are no more active rules in this ruleflow group. As a result, during the execution of a ruleflow group, new activations belonging to the currently active ruleflow group can be added to the Agenda due to changes made to the facts by the other rules. Note that the process will immediately continue with the next node if it encounters a ruleflow group where there are no active rules at that time.

If the ruleflow group was already active, the ruleflow group will remain active and execution will only continue if all active rules of the ruleflow group has been completed. It contains the following properties:

  • Id: The id of the node (which is unique within one node container).
  • Name: The display name of the node.
  • RuleFlowGroup: The name of the ruleflow group that represents the set of rules of this RuleFlowGroup node.

 

Script Task

Represents a script that should be executed in this process. A Script Task should have one incoming connection and one outgoing connection. The associated action specifies what should be executed, the dialect used for coding the action (i.e., Java, JavaScript or MVEL), and the actual action code. This code can access any variables and globals. There is also a predefined variable kcontext that references the ProcessContext object (which can, for example, be used to access the current ProcessInstance or NodeInstance, and to get and set variables, or get access to the ksession using kcontext.getKieRuntime()). When a Script Task is reached in the process, it will execute the action and then continue with the next node. It contains the following properties:

  • Id: The id of the node (which is unique within one node container).
  • Name: The display name of the node.
  • Action: The action script associated with this action node.

Note that you can write any valid Java code inside a script node. This basically allows you to do anything inside such a script node. There are some caveats however:

  • When trying to create a higher-level business process, that should also be understood by business users, it is probably wise to avoid low-level implementation details inside the process, including inside these script tasks. A Script Task could still be used to quickly manipulate variables etc. but other concepts like a Service Task could be used to model more complex behaviour in a higher-level manner.
  • Scripts should be immediate. They are using the engine thread to execute the script. Scripts that could take some time to execute should probably be modeled as an asynchronous Service Task.
  • You should try to avoid contacting external services through a script node. Not only does this usually violate the first two caveats, it is also interacting with external services without the knowledge of the engine, which can be problematic, especially when using persistence and transactions. In general, it is probably wiser to model communication with an external service using a service task.
  • Scripts should not throw exceptions. Runtime exceptions should be caught and for example managed inside the script or transformed into signals or errors that can then be handled inside the process.

 


 

Leave a Reply