The following Throw Events trigger signals:

Every signal defines its signal reference, that is the SignalRef property, which is unique in the respective session.

A signal can have one of the following scopes, which restricts its propagation to the selected elements:

To select the scope in the Process Designer, click Signal Scope under Core Properties of a Signal Throw Event.

Figure A.1. Selecting Signal Scope (Default)

Signalling External Deployments

When creating an external signal event, you need to specify the work item handler for the External Send Task manually. Use the org.jbpm.process.workitem.jms.JMSSendTaskWorkItemHandler work item handler, which is shipped with Red Hat JBoss BPM Suite. It is not registered by default because each supported application server handles JMS differently, mainly due to different JNDI names for queues and connection factories.

The JMSSendTaskWorkItemHandler handler has five different constructors. The parameterless constructor used in the procedure above has two default values:

You can specify custom values using one of the following constructors instead:

Both cross-project signalling and process instance signalling within a project is supported. To do so, specify the following data inputs in the DataInputAssociations property of the signal event in the Process Designer. See Section A.3.1.2, “Catching and Processing Signals” for more information.

Figure A.3. Specifying SignalDeploymentId Data Input

The data inputs provide information about the signal, target deployment, and target process instance. For external signalling, the deployment ID is required, because an unrestricted broadcast would negatively impact the performance in large environments.

To send signals and messages in asynchronous processes, you need to configure a receiver of the signals, that is to limit a number of sessions for a given endpoint. By default, the receiver message-driven bean (org.jbpm.process.workitem.jms.JMSSignalReceiver) does not limit a concurrent processing.

Open the EAP_HOME/standalone/deployments/business-central.war/WEB-INF/ejb-jar.xml file and add the following activation specification property to the JMSSignalReceiver message-driven bean:

<activation-config-property>
  <activation-config-property-name>maxSession</activation-config-property-name>
  <activation-config-property-value>1</activation-config-property-value>
</activation-config-property>

The message-driven bean should look like the following:

<message-driven>
  <ejb-name>JMSSignalReceiver</ejb-name>
  <ejb-class>org.jbpm.process.workitem.jms.JMSSignalReceiver</ejb-class>
  <transaction-type>Bean</transaction-type>
  <activation-config>
    <activation-config-property>
      <activation-config-property-name>destinationType</activation-config-property-name>
      <activation-config-property-value>javax.jms.Queue</activation-config-property-value>
    </activation-config-property>
    <activation-config-property>
      <activation-config-property-name>destination</activation-config-property-name>
      <activation-config-property-value>java:/queue/KIE.SIGNAL</activation-config-property-value>
    </activation-config-property>
    <activation-config-property>
      <activation-config-property-name>maxSession</activation-config-property-name>
      <activation-config-property-value>1</activation-config-property-value>
    </activation-config-property>
  </activation-config>
</message-driven>

This setting ensures that all messages, even the ones that were sent concurrently, will be processed serially and that notifications sent to the parent process instance will be delivered and will not cause any conflicts.

Signals are caught by the following catch event types:

To catch and process a signal, create an appropriate catching signal event in the Process Designer, and set the following properties:

To signal a process instance directly, that is equivalent to the process Instance scope, use the following API function:

ksession.signalEvent(eventType, data, processInstanceId)

Here, the parameters used are as follows:

You can use a more general version of the above function, which does not specify the parameter processInstanceId. That results in signalling all processes in the given ksession, that is equivalent to the Default scope:

ksession.signalEvent(eventType, data);

The usage of the arguments eventType and data is the same as above.

To trigger a Signal from a script, that is a Script Task, or using on-entry or on-exit actions of a node, use the following API function:

kcontext.getKieRuntime().signalEvent(
    eventType, data, kcontext.getProcessInstance().getId());

The usage of the arguments eventType and data is the same as above.

Like signals, messages are sent by throw events of one of the following types:

When creating the appropriate throw event, register a custom handler for the Send Task Work Item. Red Hat JBoss BPM Suite provides only dummy implementation by default. It is recommended to use the JMS-based org.jbpm.process.workitem.jms.JMSSendTaskWorkItemHandler.

The process for catching messages does not differ from receiving signals, with the exception of using the MessageRef element property instead of SignalRef. See Section A.3.1.2, “Catching and Processing Signals” for further information.

To send a message using the API, use the following method:

ksession.signalEvent(eventType, data, processInstanceId);

Here, the parameters used are as follows:

To send a message from a Script Task or using on-entry or on-exit actions of a node, use the following method:

kcontext.getKieRuntime().signalEvent(
    eventType, data, kcontext.getProcessInstance().getId());

The usage of the arguments eventType and data is the same as above.

“... the Intermediate Event indicates where something happens (an Event) somewhere between the start and end of a Process. It will affect the flow of the Process, but will not start or (directly) terminate the Process.^[3]”

An intermediate event handles a particular situation that occurs during process execution. The situation is a trigger for an intermediate event.

In a process, intermediate events can be placed as follows:

Based on the type of the event trigger, the following Intermediate Events are distinguished:

“The Event-Based Gateway has pass-through semantics for a set of incoming branches (merging behavior). Exactly one of the outgoing branches is activated afterwards (branching behavior), depending on which of Events of the Gateway configuration is first triggered. ^[5]”

The gateway is only diverging and allows you to react to possible events as opposed to the Data-based Exclusive Gateway, which reacts to the process data. The outgoing flow is taken based on the event that occurs. Only one outgoing flow is taken at a time.

The gateway might act as a start event, where the process is instantiated only if one the intermediate events connected to the Event-Based Gateway occurs.

“A Parallel Gateway is used to synchronize (combine) parallel flows and to create parallel flows.^[6]”

Attributes

Attributes

You can run activities in multiple instances during execution. Individual instances are executed in a sequence. The instances are run based on a collection of elements. For every element in the collection, a new activity instance is created.

Every multiple-instance activity has the Collection Expression attribute that maps the input collection of elements to a single element. The multiple-instance activity then iterates through all the elements of the collection.

Attributes

Attributes

Use a Service Task to invoke web services and Java methods.

org.jbpm.process.workitem.bpmn2.ServiceTaskHandler

“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 Business 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.

Attributes

A Script Task represents a script to be executed during the process execution.

The associated Script can access process variables and global variables. When using a Script Task:

When a Script Task is reached during execution, the script is executed and the outgoing flow is taken.

Attributes

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

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

An embedded sub-process 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]”

Attributes

A Multiple Instances Sub-Process is instantiated multiple times when its execution is triggered. The instances are created in a sequential manner, that means a new sub-process instance is created only after the previous instance has finished.

A Multiple Instances Sub-Process has one incoming connection and one outgoing connection.

Attributes

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 the sub-process. The sub-process is not part of the regular control flow. Although self-contained, it is executed in the context of the bounding sub-process.

Use an event sub-process within a process flow to handle events that happen outside of the main process flow. For example, while booking a flight, two events may occur:

Both these events can be modeled using the event sub-process.

When a User Task element is triggered 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. For further information about the Task Execution Engine, see the Red Hat JBoss BPM Suite Administration and Configuration Guide. The Process instance continues the execution only when the associated User Task has been completed or aborted.

See the User Task lifecycle:

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 implements 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.

A reassignment can start if a User Task is in one of the following states for a defined amount of time:

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 set 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 in one of the following states for the specified time:

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

Available variables

A notification can reference process variables by using the #{processVariable} syntax. Similarly, task variables use the ${taskVariable} syntax.

In addition to custom task variables, the notification mechanism can use 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>

A sequence flow represents the transition between two flow elements. It establishes an oriented relationship between activities, events, and gateways, and defines their execution order.