このコンテンツは選択した言語では利用できません。

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.
Expand
Table 3.2. Activities
Activity Type Additional Properties Usage
Script Tasks
  • 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:
kcontext.getKnowledgeRuntime())
Copy to Clipboard Toggle word wrap
When a Script Task is reached in the process, it will execute the action and then continue with the next node.
User Task
  • 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
  • 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., #{person.name.firstname}.
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
  • 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
  • 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:
    subprocess_node_id:variable_name
    Copy to Clipboard Toggle word wrap
  • 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
  • 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
  • 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();
    Copy to Clipboard Toggle word wrap
  • 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)
    Copy to Clipboard Toggle word wrap
  • 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.
Dialects

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., person.name 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( person.name );
Copy to Clipboard Toggle word wrap

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat