An event in the Infinity Process Engine is a condition or situation affecting the behavior of a running process instance or activity instance. An arising event is normally associated with a set of actions, which will then execute. Specific for such actions is that they allow richer process behavior than straight modeled control flow.

However, an event itself can be caused by the workflow processing - see the explanation of engine events below.

The difference to triggers is that events always have the scope of already running process instances or activity instances.

For details on working with Event Handlers in the Eclipse Modeler and the Modeling perspective, please refer to chapters Working With Activity Event Handlers and Working with Process Definition Event Handlers in the Eclipse Modeling Guide and chapter Modeling the Organizational Structure in the Business Process Modeling Handbook respectively.

Event Types

The event types accepted by the Infinity Process Engine may be categorized as follows:

Engine Events

Engine events for an activity instance/process instance arise because of a change in the overall state of the activity instance/process instance:

Pull Events

Pull events are events which arise by meeting a time condition (e.g. a timer event).

Event Handlers

For an activity/process definition event handlers have to be defined to be aware of a specific event at runtime. An event handler defines the specific match condition to accept the event at runtime. Multiple event handlers are possible - even for the same event type.

An activity may define the following event handlers:

Event Actions

The ultimate goal of getting notified of event occurrence is to introduce custom side effects. Multiple event actions may be defined per event handler, which will execute consecutively at runtime if the event handler matches the event.

A couple of event actions are predefined:

The following table displays for which process or activity event handler specific event action types are supported:

Event Action Type Process Event Handler Types Activity Event Handler Types
Abort ProcessTimerTimer, On Exception
Abort ActivityTimer, On Exception
Delegate ActivityOn Activity State Change, Timer, On Exception
Send MailTimer, On Process State ChangeOn Activity State Change, Timer, On Exception, On Assignment
Process TriggerTimer, On Process State ChangeOn Activity State Change, Timer, On Exception, On Assignment
Schedule ActivityOn Activity State Change, Timer, On Exception
Set DataTimer, On Process State ChangeOn Activity State Change, Timer, On Exception, On Assignment
Activate ActivityTimer, On Exception, On Assignment
Complete ActivityTimer, On Exception
Exclude UserOn Assignment

Passing data to the actions

Event handlers can pass data to the subordinate actions. These data are offered as access points. The concrete set of available access points depends on the type of the event handler.

Custom Event Action Types

It is possible to extend the Infinity Process Engine by custom event action types. For details, refer to the Programming Guide.

Event Binding

Handlers for pull events are not automatically enabled by default but instead may be enabled programmatically at runtime by an operation called binding.

When binding an event handler the Infinity Process Platform API allows overriding the properties of the event handler and the subordinate event actions and bind actions (see below).

Binding Options

Auto Binding

Alternatively, it is possible to configure the timer event to be bound automatically. This will bind the timer event at activity instance creation time. However, the bind actions are executed in this case, too.

Log Handler

An enabled "Log Handler" specifies whether an occurrence of the corresponding event should be logged to the audit trail or not.

Consume on Match

If Consume on match is selected any logically following handler accepting the same event will not be executed, thus effectively terminates the processing of the current event.

Bind Actions

Beyond event actions it is possible to specify bind actions which are executed when the event is bound. Bind actions are executed in order of definition.


Bind actions are especially useful in a workflow scenario called resubmission. Resubmission (of an activity) means removing an interactive activity instance from a worklist and putting it back later, based on some criterion. Resubmission for an activity in Infinity Process Platform is modeled in the following way:

At runtime, this would allow the following resubmission scenario:

  1. A user having the activity instance in his worklist decides to schedule the activity instance for resubmission. He can do this in the Workflow Execution Perspective of the Infinity Portal or in a custom made embedded client. In both cases the event handler is bound and configured for resubmission at a certain time.
  2. As the result of the bind action the activity instance is hibernated and no longer visible in any standard worklist.
  3. After the configured time period, the bound event handler will be triggered, thus causing the event action to be executed and the activity instance is set to suspended state. The activity instance is again visible in the standard worklist.

There are obviously variants of this scenario, e.g. to auto bind the handler and leave out step 2 of the above modeling scenario. This would result in a behavior where the activity instance is always put to the worklist only after a certain amount of time. This could be useful in situations where it is sure that you have to wait a certain time, e.g to receive a document by mail.

Unbind Actions

Analog to the process of binding there is the process of unbinding an event handler, which removes the binding of the handler. This also has to be done programmatically. Unbind actions are defined similarly to bind actions. They are executed when unbinding happens.

To continue the preceding example, imagine you want to explicitly remove the activity instance from resubmission because the reason for being hibernated no longer exists. When unbinding this activity instance there has to be a mechanism to put it back to the worklist. This could be done by an appropriate scheduled unbind action.

Intermediate Events in the Portal Modeling perspective

The Modeling perspective uses intermediate events, following the BPMN 2.0 standards. As the name implies, the Intermediate Event indicates where an event happens somewhere between the start and end of a Process. It affects the flow of the Process, but does not start or (directly) terminate the Process. Intermediate Events can be used to:

The following diagram depicts the classification of intermediate events supported in the Portal Modeling perspective.

Figure: Intermediate Event

Boundary Events

Boundary events are Intermediate events attached to the boundary of an Activity. Boundary events can be:

You should use Timer Boundary event if an activity is not processed within specified time interval, explanation email should be sent.

You should use Error Boundary event in case an error occurs when executing an activity and the activity should get aborted.

Sequence Flow of Boundary Events

Boundary Events can have only one outbound exception flow, but multiple paths can be supported using a gateway. All Boundary Events in a model must have an outgoing sequence flow.

BPMN 2.0 allows multiple outbound exception flows from a boundary event. The IPP engine currently does not support this, but may provide it in a future release.

Non-Boundary Events

Non-boundary events are Intermediate events specified always between two activities, or gateway and activity. Only timer event can be added as a non-boundary event.

You can use the non-boundary timer event if you want a delay between the two activities.

Non-Boundary Events are not directly supported by the IPP engine, but it is shown as a Route Activity.

Sequence Flow of Non-Boundary Events

Non-boundary Intermediate Events can have both an inbound and outbound sequence flow. All Intermediate Events in a model must have both an incoming and outgoing sequence flow.

Interrupting and Non-interrupting Events

Interrupting Events

Interrupting events do:

Interrupting events can be timer or error boundary events.

Non-interrupting Events

Non-interrupting events do:

Non-interrupting events can be timer boundary or non-boundary events.

Exception Flow

The following elements can be the exception flow target:

Note that Data may not be connected directly to Events in the Portal Modeling perspective.

An existing exception flow (i.e., connection) is maintained when dropped onto another activity or onto the drawing canvas.