Activities can be run in multiple instances on execution. Individual instances are run in a sequential manner. The instances are run based on a collection of elements: for every element in the collection, a new Activity instance is created..

Every Activity has therefore the Collection Expression attribute that defines the collection with elements to iterate through.

A Task is the smallest unit of work in a Process flow and to help identify the various types of Tasks that can be performed, Red Hat JBoss BPM Suite uses the BPMN guidelines to separate them based on the types of inherent behavior that the Tasks might represent.

A Task that doesn’t serve a direct defined purpose is either called the None Task or the Abstract Task (deprecated).

The different types of tasks available in JBoss BPM Suite are listed here, except for the User Task.

We define the User Task in another section (see Section A.9.5, “User Task”).

A Service Task is used with the built-in ServiceTaskHandler to invoke Java methods or Web Services.

“A Business Rule Task provides a mechanism for the Process to provide input to a Business Rules Engine and to get the output of calculations that the Business Rules Engine might provide. ^[13]”

The Task defines a set of rules that need to be evaluated and fired on Task execution. Any rule defined as part of the ruleflow group in a rule resource is fired.

When a Rule Task is reached in the Process, the engine starts executing the rules with the defined ruleflow group. When there are no more active rules with the ruleflow group, the execution continues to the next Element. During the ruleflow group execution, new activations belonging to the active ruleflow group can be added to the Agenda as these are changed by the other rules. Note that the Process continues immediately to the next Element if there are no active rules of the ruleflow group.

If the ruleflow group was already active, the ruleflow group remains active and the execution continues if all active rules of the ruleflow group have been completed.

A Script Task represents a script that should be executed during the Process execution.

The associated Script can access any variables and globals.

When using a Script Task follow these rules:

When a Script Task is reached during execution, the script is performer and the outgoing Flow is taken.

From JBoss BPM Suite 6.2 onwards, JavaScript is supported as dialect in Script Tasks. To define a Script Task in Business Central and JBoss Developer Studio using the process design tool:

Example A.8. Script Task in Business Central using JavaScript

An Embedded Sub-Process is a Sub-Process that encapsulates a part of the process.

It must contain a Start Event and at least one End Event. Note that the Element allows you to define local Sub-Process variables, that are accessible to all Elements inside this container.

“An Ad-Hoc Sub-Process is a specialized type of Sub-Process that is a group of Activities that have no REQUIRED sequence relationships. A set of Activities can be defined for the Process, but the sequence and number of performances for the Activities is determined by the performers of the Activities. ^[15]”

“An Ad-Hoc Sub-Process or Process contains a number of embedded inner Activities and is intended to be executed with a more flexible ordering compared to the typical routing of Processes. Unlike regular Processes, it does not contain a complete, structured BPMN diagram description—i.e., from Start Event to End Event. Instead the Ad-Hoc Sub-Process contains only Activities, Sequence Flows, Gateways, and Intermediate Events. An Ad-Hoc Sub-Process MAY also contain Data Objects and Data Associations. The Activities within the Ad-Hoc Sub- Process are not REQUIRED to have incoming and outgoing Sequence Flows. However, it is possible to specify Sequence Flows between some of the contained Activities. When used, Sequence Flows will provide the same ordering constraints as in a regular Process. To have any meaning, Intermediate Events will have outgoing Sequence Flows and they can be triggered multiple times while the Ad-Hoc Sub-Process is active.^[16]”

The Elements of an AdHoc Sub-Process are executed in parallel.

A Multiple Instance Sub-Process is a Sub-Process that is instantiated/run multiple times when its execution is triggered. The instances are created in a sequential manner: a new Sub-Process instance is created only after the previous instance has finished.

A Multiple instance Sub-Process has one incoming Connection and one outgoing Connection.

An Event Sub-Process becomes active when its start event gets triggered. It can interrupt the parent process context or run in parallel to it.

With no outgoing or incoming connections, only an event or a timer can trigger these Sub-Processes. These Sub-Processes are not part of the regular control flow. Although self-contained, they are executed in the context of the bounding Sub-Process.

You would use these Sub-Processes within a process flow to handle events that happen external to the main process flow. For example, while booking a flight, two events may occur: (interrupting) cancel booking, or (non-interrupting) check booking status. Both these events can be modeled using the Event Sub-Process.

When a User Task element is encountered during Process execution, a User Task instance is created. The User Task instance execution is preformed by the User Task service of the Task Execution Engine (see the Red Hat JBoss BPM Suite Administration and Configuration Guide ). The Process instance leaves the User Task element and continues the execution only when the associated User Task has been completed or aborted.

When the Process instance enters the User Task element, the User Task is the Created stage. This is usually a transient state and the User Task enters the Ready state immediately: the User Task appears in the Task Lists of all actors that are allowed to execute the task. As soon as one of the actors claims the User Task to indicate they are executing it, the User Task becomes Reserved. If a User Task has only one potential actor, it is automatically assigned to that actor upon creation. When the user who has claimed the User Task starts the execution, the User Task status changes to InProgress. On completion, the status changes to Completed or Failed depending on the execution outcome.

Note that the User Task lifecycle can include other statuses if the User Task is reassigned (delegated or escalated), revoked, suspended, stopped, or skipped. For further details, on the User Task lifecycle see the Web Services Human Task specification.

The reassignment mechanism is the mechanism implementing the escalation and delegation capabilities for User Tasks, that is, automatic reassignment of a User Task to another actor or group after a User Task has remained inactive for a certain amount of time.

Reassignment can be defined to take place either if the given User Task is for a given time in either of the following states:

When the conditions defined in the reassignment are met, the User Task is reassigned to the users or groups defined in the reassignment. If the actual owner is included in the new users or groups definition, the User Task is reset and reset to the READY state.

Reassignment is defined in the Reassignment property of User Task elements. The property can take an arbitrary number of reassignment definitions with the following parameters:

The Notification mechanism provides the capability to send an e-mail notification if a User Task is at the given time in one of the following states:

Notification is defined in the Notification property of User Task elements. The property can take an arbitrary number of notification definitions with the following parameters:

Available variables

Notification can reference Process variables (#{processVariable}) and Task variables (${taskVariable}).

In addition to custom Task variables, the notification mechanism can make use of the following local Task variables:

<html>
	<body>
		<b>${owners[0].id} you have been assigned to a task (task-id ${taskId})</b><br>
		You can access it in your task
		<a href="http://localhost:8080/jbpm-console/app.html#errai_ToolSet_Tasks;Group_Tasks.3">inbox</a><br/>
		Important technical information that can be of use when working on it<br/>
		- process instance id - ${processInstanceId}<br/>
		- work item id - ${workItemId}<br/>

		<hr/>

		Here are some task variables available
		<ul>
			<li>ActorId = ${doc['ActorId']}</li>
			<li>GroupId = ${doc['GroupId']}</li>
			<li>Comment = ${doc['Comment']}</li>
		</ul>
		<hr/>
		Here are all potential owners for this task
		<ul>
		$foreach{orgEntity : owners}
			<li>Potential owner = ${orgEntity.id}</li>
		$end{}
		</ul>

		<i>Regards from jBPM team</i>
	</body>
</html>