A called data mappings) is provided graphically by the

A key feature of executable process models is their ability to be transferred, or deployed, to a run
time BPMS component called the process engine. When triggered by conditions specified by the
model, the engine creates a new instance of the process and executes it automatically. For each
instance, the process engine automates and monitors process flow. When routed to an interactive
step, the instance becomes a work item accessible from the assigned participant’s worklist.
For automated steps, the process engine invokes an executable object as specified by the model,
typically an integration component generated in the BPMS design tool. Integration components
receive a set of data elements from the process engine and use them to invoke an API or object
method on an external business system or enterprise application, via an integration adapter. Data
returned from the invocation is passed back to the process by the integration component. Conversion
of process data to the formats required by the integration component is performed by a data
transformation engine within the BPMS run time. Definition of transformations (also called data
mappings) is provided graphically by the BPMS design tool.
Another key capability for BPMS is in the handling of events. Events are signals received by the
process engine either from an external system, as a message, or from another part of the BPMS,
such as a rule engine. A process can respond to an event in one of two ways: it can launch a new
instance of a process, or it can complete an activity defined to wait for the event or message. The
list of events a BPMS can listen for and respond to (without custom programming) varies widely
from one offering to the next, depending on the vendor’s emphasis on process use cases.
The BPMS process engine provides exception handling and transaction management. Exceptions
come in two types: system exceptions and business exceptions. A system exception is typically a
fault raised by an automated step in the process. For example, the data passed to the integration
component may not match the required structure or schema, or the external system invoked may be
down, resulting in a timeout. A business exception is an event issued by a participating user or
system, such as a change or cancellation of an order in process. Upon detection of system exceptions,
the process engine suspends the normal flow of control and triggers a special exception handler flow
defined in the modeling tool and attached to an individual activity, a group of activities, or the
process. The process model also allows a block of activities to be grouped as a single transaction
scope, meaning if an exception occurs within that block, the effects of any completed activity within
the scope must be “undone,” a feature called compensation. In many BPMS process models, a
compensating activity can be defined for each normal activity in a transaction scope for this purpose.
Unlike classical atomicity, consistency, isolation, and durability (ACID) transactions using
protocols like two-phase commit, compensation works with long running transaction scopes. For example, during the order creation process, if the customer does not have sufficient funds, the BPMS
compensates by creating the order cancellation process. Some process engines, particularly those
that run in a JEE container, also support ACID transaction recovery (rollback, retry) for those
activities where it is applicable.