3.4. Events

Processes include start events, intermediate events, and end events. Every event 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.1. Events

Event Type Additional Properties Usage
Start Event
A green button which indicates the starting of an event.
 Processes have one start node with one outgoing connection. Execution of a process always starts at the start node.
End Event
A red/pink button indicating the end of an event.
  • Terminate:
    An end event terminates either the entire process or just the current path of execution.
Processes have one or more end events. Each end event has one incoming connection and no outgoing connections.
If the process is terminated, all active nodes (on parallel paths of execution) are cancelled. Non-terminating end events end the current path of execution but allow other paths to continue. Terminating end events are visualized with a full circle inside the event node; non-terminating event nodes are empty. Note that if you use a terminating event node inside a sub-process, you are terminating the top-level process instance, not just that sub-process.
Throwing Error Event
A pink button with a red zig-zag icon in the middle.
  • FaultName:
    Provides the name of the fault, which is used to search for appropriate exception handlers that are capable of handling this kind of fault.
  • FaultVariable:
    Provides the name of the variable where the data associated with this fault is stored. This data is also passed on to the exception handler (if one is found).
Error events are used to signal an exceptional condition in the process. It should have one incoming connection and no outgoing connections. When an Error Event is reached in the process, it will throw an error with the given name. The process will search for an appropriate error handler that is capable of handling this kind of fault. If no error handler is found, the process instance will be aborted.
Error handlers can be specified using boundary events when working with XML.
Catching Timer Event
A gold button that resembles a clock timepiece.
  • Timer period:
    The period between two subsequent triggers. If the period is 0, the timer should only be triggered once.
Catching timer events represent a timer that can trigger one or multiple times after a given period of time. A Timer Event should have one incoming connection and one outgoing connection. When a Timer Event is reached in the process, it will start the associated timer.
See Section 3.9, “Timers” for expression syntax and further details.
Catching Signal Event
A gold icon with a triangle in the center.
  • EventType:
    The type of event that is expected.
  • VariableName:
    The name of the variable where the data associated with this event will be stored.
A Signal Event can be used to respond to internal or external events during the execution of the process. A Signal Event should have no incoming connections and one outgoing connection. It specifies the type of event that is expected. Whenever that type of event is detected, the node connected to this event node will be triggered.
A process instance can be signaled that a specific event occurred using: 
ksession.signalEvent(eventType, data, processInstanceId)
This triggers all (active) signal event nodes in the process instance that are waiting for that event type. Data related to the event can be passed using the data parameter. If the event node specifies a variable name, this data will be copied to that variable when the event occurs.
Events can be used inside sub-processes; however, these event nodes will only be active when the sub-process is active.
A signal can be generated from inside a process instance with a script, for instance: 
kcontext.getKnowledgeRuntime().signalEvent(eventType, data, kcontext.getProcessInstance().getId());
In addition to ensuring all of the process tasks are executed in the correct order, the process engine can be instructed to respond to events that occur outside the process. By explicitly representing events that occur outside the process, the process author can specify how the process should react to the events.
Events have a type and can have data associated with them, and users can define their own event types and associated data.
A process can specify how to respond to events by using a message event. An event node needs to specify the type of event the node is interested in. It can also define the name of a variable, which will receive the data that is associated with the event. This allows subsequent nodes in the process to access the event data and take appropriate action based on this data.
An event can be signaled to a running instance of a process in a number of ways:
  • Internal event: Any action inside a process (e.g., the action of an action node or an on-entry or on-exit action of some node) can signal the occurrence of an internal event to the surrounding process instance. Example code of an internal event is demonstrated below. 
    kcontext.getProcessInstance().signalEvent(type, eventData);
  • External event: A process instance can be notified of an event from outside using code such as the following: 
    processInstance.signalEvent(type, eventData);
  • External event using event correlation: Instead of notifying a process instance directly, it is possible to have the engine automatically determine which process instances might be interested in an event using event correlation, which is based on the event type. A process instance that contains an event node listening to external events of some type is notified whenever such an event occurs. To signal such an event to the process engine, use the following code: 
    ksession.signalEvent(type, eventData);