Workflow Modeler Events

Start Event

Start events define where a Process or Sub Process starts. The engine requires exactly one start event to start the process.

Image

A start event can be placed into the diagram from the pallete and can be changed to one of the following types from settings context menu.

When left as vanilla start event, the process simply starts without any special behavior.

Message Start Event

Listens for message throw events and resumes the flow once message event arrives. In the settings panel, you can add a new message identifier to listen to or select one of the existing message identifiers from dropdown.

Timer Start Event

Waits for the specified duration and resumes the flow once timer expires. You can define the wait duration in the settings panel. Timer duration can be specified in ISO 8601 format or as a number of milli-seconds. Refer guide on timer definition for more details.

Conditional Start Event

Evaluates the specified condition to decide whether or not to start the flow. The process flow starts only if the payload meets the specified condition.

This feature is not supported currently

Signal Start Event

Waits for a signal throw event and resumes the flow once signal event arrives. In the settings panel, you can add a new signal name to listen to or select one of the existing signal names from dropdown.

End Event

End events specify the end of workflow process. Often, the end of one process can initiate other behaviors within a business process.

Image

A end event can be placed into the diagram from the pallete and can be changed to one of the following types from settings context menu.

When left as vanilla end event, the process simply completes without any special behavior.

Message End Event

Completes the current flow and throws a message to other nodes. This is generally used as end-node within lanes or subflows. In the settings panel, you can add a new message identifier to throw or select one of the existing message identifiers from dropdown.

Signal End Event

Completes the current flow and throws a signal event to other nodes. This is generally used as end-node within lanes or subflows.

Signals are identified by their signal name. In the settings panel, you can add a new signal name to throw or select one of the existing signal names from dropdown.

Terminate End Event

When a process reaches an end node while other paths have one or more pending steps, the flow execution would continue till all outstanding paths complete. A Terminate End Event on the other hand, will interrupt all pending paths/nodes and force complete the flow.

Error End Event

An Error End Event node can be used to terminate a particular path in error. The node throws an error event, which is caught else-where in the flow (or in parent flow/another lane) to resume with appropriate alternative actions.

Escalation End Event

Completes the flow raising an escalation event. As with other end event types, you must specify the escalation event identifier.

Intermediate Events

Timer Intermediate Catch Event

Waits for the specified duration and resumes the flow once timer expires. You can define the wait duration in the settings panel. Timer duration can be specified in ISO 8601 format or as a number of milli-seconds. Refer guide on timer definition for more details.

Image

Message Intermediate Events

Message events act as notification to another message node within same process and can transcend pools boundaries. Message event can be of throw or catch type. As the names suggest, a throw type node throws the message event and catch type node waits for message event to be thrown before resuming the process execution. A message event is targeted at a single receiver. The correlation between throw and catch is defined by means of a common message identifier specified in the node’s properties.

Signal Intermediate Events

Signal events act similar to message events with the difference that throw signal events are broadcasted and are targetted at all listening nodes across processes. Signal event can be of throw or catch type.

Link throw and catch events specify Go-To semantics.

Escalation Intermediate Throw Event

Escalation events are non-critical exception conditions and are generally used to communicate from a sub-process to the parent. Semantically they are similar to message events. While message event specifies a normal step in process flow the escalation event signifies an unusual scenario like delay in shipment.

Conditional Catch Event

A conditional catch event waits on a condition to be evaluated to true before it resumes the process flow.

Image

Variable Name signifies when the condition is evaluated. When specified, a change only in the specified process variable will trigger the condition to be evaluated again. If left blank, condition is evaluated for any change in any of the process variable. Variable Event data is not used.

Boundary Events

Boundary events are intermediate catch event handlers placed at the boundary of a task node (e.g. user task or sub-process) that can trigger alternate path while the underlying task is active. Boundary events could be interrupting or non-interrupting.

  • An interrupting boundary event would force entire alternative path to be followed, interrupting the underlying activity.
  • A non-interrupting boundary event triggers alternative flow while keeping underlying task active.

Image

In example below Manual Action task is appended with one non-interrupting timer event and another interrupting timer event. After the task is assigned to user, the timers start. If user completes the task before any timer expiry the normal execution continues. When non-interrupting timer expires (Day 2 and Day 3), it activates the flow to send reminder. The user task remains active and assigned to same user. Non-interrupting boundary event can trigger multiple times.

When non-interrupting timer expires the underlying user task is interrupted and normal path is abandoned. In this case, a new assignee is identified and task is recreated.

Image

External Events

External events raises a event on to external service with the given payload. As of now workflow supports raising events on to redis instance with the help of Message Intermediate Throw and Message End nodes.

Configuring Payload

Payload should be configured via Script Task node before the Message Intermediate Throw Event and Message End Event nodes. Both Message Intermediate Throw Event and Message End Event will look for the payload to post on redis by extracting payload from message (i.e. message.payload).

The script inside Script Task should be in the below form

var msg = {
  payload: {
    name: 'tony',
    age: 35,
    location: 'USA'
  }
};
sendMsg(msg);

Image

The above payload will be posted on redis instance with the messageName as id. messageName also can be specified from message as message.messageRef. If you specify message.messageRef, then the messageName on message intermediate throw or message end event will be ignored.

var obj = {
  messageRef: 'sampleMsg',
  payload: {
    name: 'tony',
    age: 35,
    location: 'USA'
  }
};
sendMsg(obj);

Configuring Message Intermediate Throw and Message End nodes

The configuration procedure is same for both Message Intermediate Throw and Message End nodes. The only difference is

  • Message Intermediate Throw Event will raise the redis event from any point in the worklfow with the specified payload.
  • Message End Event will raise the event at the end of the workflow (once worklfow is completed its execution and arrived at end node)

Example

Image

Image

When configuring the event, select External option from implemenation dropdown and set the topic name to which payload has to be posted. Topic name can also be set using dollar pv expression. (Example: ${pv.topic})

Image