Menu Close
Settings Close

Language and Page Formatting Options

3.5. Activities

Activities are actions that need to be performed during the execution of the process. Each activity has one incoming connection and one outgoing connection.
Every activity has an ID, which identifies the node, and a name, which is the display name of the node. Additional properties are listed in the table below.

Table 3.2. Activities

Activity Type Additional Properties Usage
Script Tasks
This image shows the Script Task icon associated with the node.
  • Action:
    The action script associated with the node.
The Script Task represents a script that should be executed in this process. The associated action specifies what should be executed, the dialect used for coding the action (i.e., Java 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 be used to access the current ProcessInstance or NodeInstance; this object can also be used to get and set variables, or for it to get access to the ksession using:
When a Script Task is reached in the process, it will execute the action and then continue with the next node.
User Task
This image shows the User Task icon associated with 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 responsible for executing the human task. A list of actor ID's can be specified using a comma (',') as a separator.
  • GroupId:
    The group ID responsible for executing the human task. A list of group ID's can be specified using a comma (',') as a separator.
  • Skippable:
    Specifies whether the human task is optional.
  • Content:
    The data associated with this task.
  • Swimlane:
    The swimlane this human task node is part of.
  • On entry and on exit actions:
    Action scripts that are executed upon entry and exit of this node.
  • Parameter mapping:
    Copies the value of process variables to the human task parameters. The values are copied when the human task is created.
  • Result mapping:
    Copies the result parameters from a human task to a process variable. A human task with a variable called result will contain the data return by the human actor; the result variable ActorId will contain the ID of the actor who completed the task.
Processes can involve tasks that need to be executed by human actors. A user task represents an atomic task to be completed by a human actor. User tasks can be used in combination with swim lanes to assign multiple human tasks to similar actors. For more information about swim lanes and human tasks, see Human Tasks chapter.
Service Tasks
This image shows the Service Task icon associated with the node.
  • Parameter mapping:
    Copies the value of process variables to the work item parameters. The values are copied when the work item is created.
  • Result mapping:
    Copies the result parameters from work items to a process variable when the work item has completed. For example, the FileFinder work item has the parameter Files, which returns a list of files that match a search criteria. This list of files can then be bound to a process variable for use within the process.
  • On-entry and on-exit actions:
    Actions that are executed upon entry or exit of the node.
  • Additional parameters:
    Each type of work item can define additional parameters that are relevant for that type of work item. The user can either provide these values directly or define a parameter mapping. If both methods are used, the parameter mapping will override parameters provided by the user. 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 be the name of a variable (so that it resolves to the value of the variable) but more advanced MVEL expressions are possible as well, e.g., #{}.
Service Tasks represent an abstract unit of work that should be executed in this process. 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. however, users can define domain-specific services or work items. For further details, see Domain-Specific Processes chapter.
Business Rule Task
This image shows the Business Rules Task icon associated with the node.
  • RuleFlowGroup
    The name of the ruleflow group that represents the set of rules of this RuleFlowGroup node.
Business Rule Task represents a set of rules that need to be evaluated. 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. This means that during the execution of a ruleflow group, it is possible that new activations belonging to the currently active ruleflow group are added to the Agenda; this occurs because of changes made to the facts by the other rules. 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 have been completed.
Embedded Sub-Process
This icon illustrates an Embeded Sub-Process that acts as a node container.
  • VariableID
    Unlike other variables which have a variable ID which is derived from variable_name, embedded sub-process have a variable ID in the form:
  • Variables
    Additional variables can be defined to store data during the execution of this node. For more details see Section 3.7, “Data”
A sub-process is a node that can contain other nodes so that it acts as a node container. This allows not only the embedding of a part of the process within such a sub-process node, but also the definition of additional variables that are accessible for all nodes inside this container. A sub-process needs a start event and one or more end events.
Reusable Sub-process
This icon illustrates a Reusable Sub-Process which represents the initiation of a process within another process.
  • ProcessId:
    The ID of the process that should be executed.
  • Wait for Completion:
    If false, the process will continue as soon as the sub-process has been started.
    If true, it will wait for the sub-process to finish (complete or abort).
  • Independent:
    If true, the child process is started as an independent process and will not be terminated if the parent process completes.
    Independent can only be set to false when Wait for Completion is set to true. If set to false, the sub-process will be canceled on termination of the parent process.
  • On-entry and on-exit actions:
    Actions that are executed upon entry or exit of this node.
  • Parameter in/out mapping:
    A sub-process node can define "in" and "out" mappings for variables. The variables given in the "in" mapping will be used as parameters (with the associated parameter name) when starting the process. The variables of the child process that are defined for the "out" mappings will be copied to the variables of this process when the child process has been completed. Note that "out" mappings can only be used when "Wait for completion" is set to true.
Reusable sub-processes represent the invocation of another process from within a process. When a reusable sub-process node is reached in the process, the engine will start the process with the given ID.
Multi-Instance Sub-Process
This icon illustrates a Multi-Instance Sub-Process which allows the execution of the contained process segment multiple times.
  • CollectionExpression:
    A collection of elements either in the form of an array or the type java.util.Collection.
  • VariableName
    The name of the variable to contain the current element from the collection. This gives nodes within the composite node access to the selected element.
A Multiple Instance sub-process is a special kind of sub-process that allows you to execute the contained process segment multiple times, once for each element in a collection. It waits until the embedded process fragment is completed for each of the elements in the given collection before continuing. If the collection expression evaluates to null or an empty collection, the multiple instances sub-process will be completed immediately and follow its outgoing connection.
Any valid Java code can be used inside a script node. Some points to consider when writing code for a script node:
  • Avoid low level implementation details inside the process when defining high-level business processes that need to be understood by business users. A Script Task could be used to manipulate variables, but other concepts like a service task could be used to model more complex behavior in a higher-level manner.
  • Scripts should be immediate as they use the engine thread to execute the script. Scripts that take some time to execute should be modeled as an asynchronous Service Task.
  • Avoid contacting external services through a script node; instead, model communication with an external service using a service task.
  • Scripts should not throw exceptions. Runtime exceptions should be caught and managed inside the script or transformed into signals or errors that can then be handled inside the process.
kcontext variable

This variable is of type org.drools.runtime.process.ProcessContext and can be used for several tasks:

  • Getting the current node instance (if applicable). The node instance could be queried for data, such as its name and type. You can also cancel the current node instance.
    NodeInstance node = kcontext.getNodeInstance();
    String name = node.getNodeName();
  • Getting the current process instance. A process instance can be queried for data (name, id, processId, etc.), aborted or signaled an internal event.
    ksession.signalEvent(eventType, data,  processInstanceId)
  • Getting or setting the value of variables.
  • Accessing the Knowledge Runtime allows you do things like starting a process, signaling (external) events, inserting data, etc.

Both Java and MVEL can be used. Java actions should be valid Java code. MVEL actions can use the business scripting language MVEL to express the action. MVEL accepts any valid Java code but additionally provides support for nested accesses of parameters (e.g., instead of person.getName()), and it provides many other scripting improvements. Thus, MVEL expressions are more convenient for the business user. For example, an action that prints out the name of the person in the "requester" variable of the process would look like this:

// Java dialect
System.out.println( person.getName() );

//  MVEL dialect
System.out.println( );