Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec R -- By Mathias Weske

Representing Process Instances

Workflow nets cover the model level in process modelling and—by tokens—
the process instance level as well. This means that for each business process
model represented by a workflow net there can be multiple process instances
following this model. Each process instance is represented by a set of tokens
in the workflow net.
The workflow net represents a business
process in which claims are processed; the details of this process are not relevant
to introducing how process instances are represented in workflow nets.
The tokens are coloured; they contain values. If we abstract from any application
data that might be represented by tokens, each token carries at least
a process instance identifier.
Case 5 is in the initial place; it is
not yet started. Case 4 is reflected by two tokens, because it is currently on a
parallel branch. The same holds for case 3, but for case 3 the Contact Client
transition has already been conducted.

Discussion

Workflow nets are a well-known technique to model business processes in an
abstract and formal way. In order to provide a formal background, especially
in the context of soundness properties which will be investigated in Chapter
6, several restrictions were introduced. Without these restrictions, formal
analysis of workflow nets would not be feasible.

Data and Conditions
Data is not explicitly represented in workflow nets. Data is only handled in
an abstract way, by denoting that tokens can be coloured, but the usage of
these data structures in the process is not investigated.
While the workflow net represents the structure of a set of similar process
instances (i.e., the process model), the individual cases are represented by tokens.
Each case is represented by at least one token. In general, when the case
starts, there is one token in the source place i, and when the case completes,
there is one token in the sink place o.
The workflow management system that controls the enactment of cases
requires differentiating between the tokens that belong to different cases. A
transition t with incoming edges from places p and p0 realizes an and join.
This means that t can only be enabled when there are tokens in p and p0, and
these tokens need to belong to the same case.
Therefore, tokens need to be typed. Tokens need (at least) to include a
process instance identifier, so that t can synchronize the branches represented by p and p0 only, if these places have tokens that belong to the same case. As
a simplification often made in the context of workflow nets, each workflow net
contains tokens that belong to a single case. In this case, the tokens do not
need to be typed.
Decision transitions that realize or splits and exclusive or splits require
expressions that are evaluated for each process instance to decide which branch
to take. These decision expressions are also disregarded in workflow nets.
Decisions are abstracted from in the following way: wherever there is a
decision transition, each of the alternative branches will be taken eventually.
This assumption mirrors the non-determination of firing in traditional Petri
nets: multiple enabled transitions that share a common input place will fire
in a non deterministic fashion.
The same assumption is now in place for decision nodes in workflow nets:
each expression in a decision transition will eventually evaluate to true. When
analyzing workflow nets, this assumption is in place to detect structural errors
in workflow nets. Errors that result from erroneous conditions associated with
decision transitions, however, are not considered.

Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec Q -- By Mathias Weske

Control Flow In Workflow Nets

A work item list of a particular user contains items, each of which represents
an activity (more precisely, an activity instance) that is enabled and
that can be executed by that user. Whenever a transition with a user trigger
enters the enabled state, a work item representing this activity is sent to the
work item lists of the users who can perform it. Role information is used to
determine the knowledge workers. When a user selects a particular work item,
the activity is started and the work items reflecting it can be deleted from the
work item list.
Modelling organizational aspects like users or roles is not supported by
workflow nets. A transition marked with a user trigger indicates that the
activity represented by that transition requires a human to start it. Organizational
aspects need to be covered by tools that employ workflow nets for
process modelling and other techniques for modelling organizations. The same
applies for representing data, which is also not covered by workflow nets.
An external trigger is the main instrument for reacting to external events
like an incoming message. When the transition that carries an external trigger
enters the enabled state, it listens for this event. When the event occurs, for
instance, when an order arrives, the transition fires and the activity starts
execution.
Time triggers are used to specify situations where the start of an activity
depends on temporal aspects. Time triggers can be assigned a time-out value.
The timer is started when the transition enters the enabled state. When the
timer runs out, the enabled transition fires. If the transition is no longer
enabled, the timer is stopped.
In this
process, a request is sent, represented by the Send Request transition. The
workflow net implements an implicit exclusive or split that concurrently enables
(transitions that represent) activities to collect the response to the request
and to send a reminder.
The Collect Response activity is marked by an external trigger, so that
it is started once the response comes in. A reminder should be sent if after
a defined time interval, for instance, 14 days, no response is received. This
business logic can be implemented in a workflow net by attaching a timer
trigger to the Send Reminder transition.
The timer is started when the transition enters the enabled state, i.e.,
after the request is sent. If the response is received within the timer interval,
then the Collect Response transition fires. In this case, the Send Reminder
transition is no longer enabled, so that the timer can be stopped.
In an explicit exclusive or split (a), the decision on which branch to activate
is made by a decision transition, so that either transition A or transition B
is enabled. In this setting, the desired functionality is not realized, because if
A is enabled, the timer will not be started, and if B is activated, there is no
way for the user to start working on activity A.
The timer is started, and the user trigger is available. If the user starts the activity on time, i.e., before the
timer expires, then the timer is stopped. If the user fails to start the activity
on time, activity B is started to cater to this situation.
Trigger activities can formally be represented by places with an arc to the
respective transition. For instance, a user trigger of a transition A is represented
by a place p such that p 2 P and (p,A) 2 F, as shown in Figure 4.51.
The behaviour of the user is represented as follows. If and when the user selects
this activity, a token is put in place p, enabeling transition A. In this
case, A can fire, representing the execution of that activity.
While the behaviour of the user trigger is specified well using the additional
place and the additional arc, there is an issue to cope with: the Petri net
resulting from expanding the user trigger by a place and an arc is no longer a
Workflow net! This is due to the fact that p is not on a path from the initial
place i to the final place o. In the context of business processes involving
multiple parties, however, these trigger places are very useful to interconnect
the processes involved.
The diagram shows a business process involving a customer and a bookstore, and it contains
activities for the ordering of books by the customer and the processing of the
order by the bookstore.
All activities in this scenario are represented by transitions of one workflow
net. In order to satisfy the structural properties of workflow nets, the process
starts in the initial place i at the customer, and it ends in the final place o at
the customer. Later, in the context of business process choreographies, more
elaborate techniques will be introduced that separate an externally observable
behaviour of a business process from its internal realization. However, in the
current example, the workflow spans multiple parties.
The process starts with the customer browsing the online catalogue of a
bookstore and selecting books. If books are found, an order is assembled and
sent, represented by the send order transition. This transition spawns off two
concurrent threads, as shown by the and split symbol.
In one thread, the message is sent to the bookstore. The sending of the
order is represented by a token in the input place of the receive order transition.
When the order is received in the bookstore, the order is processed.
If the order is okay, the books are sent; otherwise, a message is sent to the
customer that informs him that not all books are available.
This means that the bookstore sends one of two possible messages for each
case. On the customer side, this situation is handled by an implicit exclusive
or split. In this split, two transitions can be enabled at the same time. If the
bookstore sends the books, the receive books transition of the customer is
enabled and will fire.
If on the other hand the information message is sent, the respective transition
on the customer side is enabled. Observe that the alternative branches
in the bookstore need to be joined, and the join transition is connected to
the customer side. This is required in workflow nets, because otherwise there
would be places in the workflow net (send books and send not available) that
are not on a path from the initial place to the final place.

Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec P -- By Mathias Weske

Control Flow in Workflow Nets

The ability to represent control flow structures in workflow nets is investigated.
As with any other process modelling language, the sequence control
construct can easily be expressed in workflow nets.

The firing rule of Petri nets makes sure that A puts a token on p only
after its termination. Hence, B is enabled only after there is a token in p.
Since only enabled transitions can fire, we have the following sequence of
events: A fires and puts a token in p enabling B, which can now start its
execution. Therefore, by transitivity of the ordering relation, B can only start
after A has terminated.
Observe that colouring information is not regarded when discussing control
flow in workflow nets. For the sequence pattern, the colouring of the tokens
can be disregarded. However, if transitions need to make decisions when they
fire, the colouring of the tokens needs to be taken into account; this will be
discussed in more detail below.
And split and and join control flow constructs can also be expressed in
workflow nets conveniently. Again, standard Petri net firing behaviour suffices.
A workflow net in which there is a transition A that puts
tokens in its output places p1 and p2, enabling B and C, respectively. As
a result, transition A realizes an and split. After B and C have terminated,
there are tokens in p3 and p4, enabling the and join transition D.
The exclusive or split and exclusive or join patterns can also be expressed
in standard Petri nets.These transitions are enabled at the same time. This type of exclusive
or split is called implicit exclusive split, because its behaviour depends on the
behaviour of the transitions involved, in this case, A and B.
Although both transitions are enabled—in the example, A and B—only
one transition can fire, withdrawing the token from p1 and adding a token
to p2. The exclusive or join is realized by a place that receives a token from
either A or B.
The transitions involved decide by
their firing behaviour about the branch of the workflow net that the process
instance takes. Since the decision is deferred to the latest point in time, this
pattern is also called deferred choice.
There is a second type of exclusive or split in workflow nets, in which the
decision on which path to take is made explicitly by a transition. This feature
takes advantage of coloured Petri nets, in which transitions can implement
decision rules, which are evaluated at run time to decide which of its output
places to put tokens on.
This also means that the behaviour of classical Petri nets is no longer valid
for workflow nets. As a consequence, as in coloured Petri nets, the graphical
representation of the workflow net does not fully specify the behaviour of the
process instance controlled by the workflow net.
Transition
A implements a decision rule by associating conditions with each of its
outgoing edges. An exclusive or semantics of this decision can be realized in
different ways (workflow nets do not prescribe any of them).
The first way to realize an exclusive or semantics is to make sure that
the conditions are chosen in a way that always one and only one condition
evaluates to true. The second way is to evaluate conditions of outgoing edges
in order. As soon as one condition evaluates to true, the respective edge is
chosen, and the token is put on the respective place.
The problem with this strategy is that there might be situations in which
no condition evaluates to true. If no additional measures are taken, then the
case gets stuck at this point. This problem can be tackled by defining a default
branch which is taken if none of the (expressions of the) other branches
evaluates to true.
To express the particular split and join behaviour of transitions in workflow
nets, the transitions are labelled with specific symbols.
It is the responsibility of the modeller of the workflow net to make sure
that the decisions associated with the transitions match their symbols. The
and split and and join markers indicate that the traditional Petri net firing
behaviour of transitions is in place.
If a transition is marked with an and split symbol, the reader of the workflow
net knows that the transition puts a token on all its output places. Split
transitions and join transitions that are based on an explicit decision are
marked accordingly to show that complex splitting behaviour can be expected.
Workflow nets represent business processes, focusing on activities and their
execution constraints. To enhance the representation of business processes
and to provide a means to represent in more detail the environment in which
these processes are enacted, triggers have been introduced. In the context of
workflow nets, triggers are annotations to transitions that provide information
on who or what is responsible for an enabled transition to fire.
Situations in real-world business processes that can be represented by triggers
are the receipt of an electronic message or a time-out of a timer to remind
an employee of an upcoming deadline. Generally, a business process management
system is a reactive system. It reacts to events in its environment by
enabling an activity. Triggers play an important role in informing the system
about events in the process environment that are relevant for the process.
Figure 4.48 shows the types of triggers used in workflow nets. Transitions
that can fire immediately after they have been enabled are not marked with a
trigger; triggering is therefore automatic. For example, automatic triggers are
used for transitions that are realized by invoking a software system, where no
user interaction is required.
A user trigger is attached to transitions that require human interaction.
By marking a transition with a user trigger, the process modeller expresses the
fact that a human user takes the initiative to start the activity represented by
the transition. This trigger is relevant in human interaction workflows, where
work items are used to communicate with human users.

Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec O -- By Mathias Weske

Workflow Nets

Event-driven process chains provide an informal notation for representing
business processes and their environment. To precisely specify and reason
about business processes, more formal approaches need to be investigated,
such as, Petri nets.
While Petri nets are very useful for representing simple types of processes,
complex processes such as business processes require advanced modelling
mechanisms. In particular, tokens need to carry information at least about
the process instance they belong to.
Workflow nets are an approach to enhance traditional Petri nets with
concepts and notations that ease the representation of business processes.
At the same time, workflow nets introduce structural restrictions that prove
useful for business processes.
The reasons for using Petri nets in general and workflow nets in particular
for business process modelling are as follows.
• Formal Semantics: Business processes can be defined in a formal manner.
This observation holds in particular for the control flow aspect of Petri
nets.
• Graphical Representation: Activities in a business process and their execution
constraints are expressed graphically in a Petri net, which eases
communication about business processes with the different stakeholders
involved (although some stakeholders prefer semiformal techniques like
event-driven process chains).
• Analysis of Process Properties: The formal semantics of business processes
expressed in Petri nets allows for the analysis of process properties.
• Tool Independence: Although several business process management tools
are based on Petri nets, the formalism itself is vendor independent.

Definitions

Like Petri nets, workflow nets focus on the control flow behaviour of a process. Places represent conditions and tokens represent process instances. Activities of a
business process are represented by transitions in the workflow net.
Because tokens represent business process instances, tokens hold application
data including process instance identifiers, i.e., the tokens are coloured.
However, in workflow nets, the colouring of tokens is not represented explicitly,
as will be discussed in more detail below.Workflow nets can be hierarchically structured.The internal structure of a complex
activity is realized by another dedicated workflow net. Hierarchical structuring
of workflow nets is not investigated in detail; in the context of the YAWL
process language, hierarchical structuring based on extended workflow nets is
studied.
Based on these considerations, workflow nets can be defined as Petri nets
with specific structural restrictions.
Definition 4.8 A Petri net PN = (P, T, F) is called workflow net if and only
if the following conditions hold.
• There is a distinguished place i 2 P (called initial place) that has no
incoming edge, i.e., •i = ;.
• There is a distinguished place o 2 P (called final place) that has no outgoing
edge, i.e., o• = ;.
• Every place and every transition is located on a path from the initial place
to the final place.
The rationale of this definition is as follows: a token in the initial place i
represents a process instance that has not yet started; a token in place o
represents a finished process instance. Each place and each transition in a
workflow net can participate in a process instance; therefore, each place and
each transition needs to be located on a path from i to o.
As a consequence of these structural properties of workflow nets, the initial
place i is the only place without incoming edges, and the final place is the
only place without any outgoing edges.
If there were another place i0 6= i 2 P without incoming edges, then i0
could not be located on a path from i to o, contradicting the definition of
workflow net. And if there were a place o0 6= o 2 P without outgoing edges,
then o0 could not be on a path from i to o. Therefore, places with the properties
of i0 and o0 cannot exist in workflow nets.
It represents a simple
claim management process in which, initially, the claim is recorded and, concurrently,
a witness report is created and the client status is checked. After
the results have been gathered, an assessment of the claim is performed. In
the case of a positive assessment, the damage is compensated. In the case of
a negative assessment, the claim is rejected. Finally the claim is filed and the
process completes.

Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec N -- By Mathias Weske

Event-driven Process Chains Definition

A tuple A = (E, F, V, m,C) is an event-driven process chain,
if
• E is a nonempty set of events
• F is a nonempty set of functions
• V is a set of connectors
• m : V 7! {and, or, xor} is a mapping that assigns to each connector a
connector type, representing and, or, and exclusive or semantics.
• Let K = E [ F [ V . C  K × K is a set of edges connecting events,
functions, and connectors such that the following conditions hold:
– (K,C) is a connected graph
– Each function has exactly one incoming edge and exactly one outgoing
edge.
– There is at least one start event and at least one end event. Each start
event has exactly one outgoing edge and no incoming edge. Each end
event has exactly one incoming edge and no outgoing edge. There is at
least one start event and one end event. All other events have exactly
one incoming edge and one outgoing edge.
– Each event can only be followed (possibly via connectors) by functions,
and each function can only be followed (possibly via connectors) by
events.
– There is no cycle in an event-driven process chain that consists of
connectors only.
– No event is followed by a decision node, i.e., an or split node or an
exclusive or split node.

Depending on the connector used, the occurrence of one event (exclusive
or join connector), the occurrence of two events (and join connector), or the
occurrence of any nonempty subset of events (or join connector) triggers a
function F. There is no surprise with respect to the semantics of the connectors:
an exclusive or connector triggers F after either E1 or E2 has occurred;
for the and connector to trigger the function, both events must occur, and
the or connector triggers F after any nonempty subset of events E1 and E2
has occurred.
The execution semantics of the split connectors follows the traditional way: an exclusive or split connector represents the business logic that after F,
either event E1 or event E2 occurs. The decision about which event actually
occurs during a particular process instance is made by function F. Analogous
considerations hold for the or split connector, where any nonempty subset of
events {E1,E2} can occur after F. The and split connector determines that
after function F, both events E1 and E2 occur.
Event-driven
process chains start with events (never with functions), since a function is always a consequence of an event and cannot therefore be performed without
the state change represented by the event.
When an order is received, it is analyzed and either accepted or rejected.
When it is accepted, the stock is checked for availability of the ordered products.
If all products are in stock, then the products are shipped and the bill
is sent. In case there are additional bills open, the payment will need to include
these open bills. The other parts of the event-driven process chains deal
with the manufacturing of products if the ordered products are not in stock.
While most constructs of event-driven process chains can be explained in this
example, the process is a severe simplification of real-world ordering processes.
While the process aspect in terms of the functions and events that occur in
business processes is well captured by event-driven process chains, there are
other types of diagrams that abstract from the relatively fine-granular level
of event-driven process chains.
Interaction flow diagrams provide a high-level view on the organizational
entities that participate in a business process, as well as their interactions.
An interaction flow diagram is a directed graph, whose nodes correspond to
organizational entities and whose edges represent interactions between the
organizations.
The interaction flow diagram shown describes at a high level of abstraction
a business process in which a customer sends an order to the marketing and
sales department, which triggers the purchase of raw material, before operations manufactures the products and finally ships them to the customer, who
pays for ordered products.
While the overall interactions are properly represented in interaction flow
diagrams, the ordering in which these interactions actually occur is not in the
scope of interaction flow diagrams. For instance, the two interactions between
customer and sales are not ordered in the diagram.
However, the reader of an interaction diagram might be able to deduce
the ordering of interactions by common sense. For instance, placing an order
is done before paying for the ordered item. The diagram itself abstracts from
these ordering relationships and, therefore, provides an abstract, high-level
representation of the organizational entities involved in a business process
and their relationships through interactions.
Function flow diagrams are a refinement of interaction flow diagrams in
the sense that they (i) represent the ordering of interactions and (ii) provide
coarse-grained functions for representing these interactions.The latter includes functions and
an ordering relationship between these functions, indicating that the entering
of the order precedes the processing of the order by the marketing and sales
department.
In addition to the functions and their ordering, split and branch ing nodes are introduced. Function flow diagrams provide information on the
coarse grained functions involved in a business process, as well as the organizational
entities that perform them. In addition, the ordering of these functions
is also represented in function flow diagrams.
In the sample function flow diagram it is clarified that planning the manufacturing
and purchasing of material are performed concurrently, but the item
is only manufactured after the supplier has processed the order and manufacturing
has received the material. The function flow diagram also models
the fact that payment of the received material is performed concurrently to
manufacturing the item.
To summarize, function flow diagrams provide high-level information on
the functions in a business process and on the organizational entities that perform
them and their ordering. Events of the business process are not covered
by function flow diagrams.
Additional views are represented by enhancing event-driven process chains
with notational symbols for data involved as well as for process paths and
process groups. Data and material are represented by rectangles, associated
with functions by solid arrows. The direction of the arrows indicates whether
the data is used for input or output (or both). Process groups hold a collection
of processes, and process paths indicate where the process continues.This part consists of a single function to analzye an order and its environment.
When the order arrives, the function is triggered, represented by the respective
event. In order to check the order, the order document and the stock status
are used as input data.
We assume the function is performed by the operations department. When
the function completes, the result is recorded in the check result data object.
The function is also responsible for creating the respective event: either the
products are in stock or the products are not in stock and need to be manufactured.
Event-driven process chains allow us to model business processes from a
business perspective. The explicit representation of the occurrence of relevant
situations by events and the bipartite structure, in which events and functions
alternate, lead to verbose and often actually quite complex process representations.
Due to their semiformal nature, business engineers and process designers
enjoy a fair degree of freedom when expressing business processes. When
it comes to implemented business processes, process designers and systems
engineers need to make explicit what was intended by the EPC.
The or join is an important control flow construct in EPCs, which is used
quite often, because it allows us to represent any type of join behaviour.
Due to the nonlocal semantics, the decision on when the join needs to be
performed cannot be taken without nonlocal knowledge.
Since event-driven process chains are primarily used to model business
processes at a business level, typically humans interpret event-driven process
chains. Since humans, when assessing an EPC, have nonlocal knowledge, the
semantics of the or join is clear to them.
The problems start when an EPC needs to be translated into an executabe
format, for instance, to serve as input for a workflow management system to
control the enactment of business processes. There are approaches in handling
the or join semantics, based on global state transition systems; for details,
the reader is referred to the bibliographical notes.

Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec M -- By Mathias Weske

Event-driven Process Chains

Event-driven process chains are an important notation to model the domain
aspects of business processes. The main focus of this rather informal notation
is on representing domain concepts and processes rather than their formal
aspects or their technical realization. Event-driven process chains are part
of a holistic modelling approach, called the ARIS framework; ARIS stands for Architecture of Integrated Information Systems, and it was developed by
August-Wilhelm Scheer.
The pillars reflect data, control and function,
while the roof reflects the overall organization. In each area, three levels of
abstraction are identified: a concept level, an architecture level, and an implementation
level, characterized by the terms Requirements Definition, Design
Specification, and Implementation Description, respectively.
The concept level is the highest level of abstraction in which data, control
and function are modelled. This level looks at nontechnical requirements of
business processes and their execution environment. Business goals and functions
are typical artefacts in the function view at this level. The data view is
expressed by data modelling techniques using Entity Relationship diagrams.
In the control view, business processes are described by event-driven
process chains, which are also used to integrate the different views. The organizational
view at the concept level deals with the organizational structures
of a company, described by organizational diagrams. The architecture level is
the intermediate level, and it aims at bridging the gap between the concept
level and the implementation level. At the implementation level, steps towards
concrete realization of the business process are addressed.
This framework is specified by a set of metamodels that describe various
views, similar to the business process perspectives introduced in Chapter 3.
The main views are as follows.
• Functional View: The functional view represents the goals and subgoals of
the enterprise and their relationships. In general, one subgoal might contribute
to a number of goals at the higher level. For instance, the subgoal
“reduce business process execution time” contributes to the goals “increase
customer satisfaction” and “reduce overall cost.”
At a lower level of abstraction, each subgoal is associated with a set of
functions that contribute to goals and subgoals. Functions are then hierarchically
decomposed until the desired granularity of functions is achieved,
similarly to functional decomposition in value chains.
• Organizational View: The organizational view describes the organizational
structure of an enterprise at a type level and at an instance level. There
are detailed specifications of organizational entities, including their relationships
and positions, roles, skills, and individuals associated with them.
Administration information such as the address of an organizational entity
can be represented. The organizational view also includes organizational
aspects of information technology of the enterprise, including its main
operational information systems, its storage facilities, and its network infrastructure.
• Data View: The data view characterizes business relevant data objects that
are manipulated by functions during business process execution. Entity
Relationship diagrams are used for data modelling.
• Business Value View or Output View: The business value view describes
the outcome of business processes, i.e., the products and services the enterprise
generates. These can be physical goods like automobiles or electronic
devices, as well as intangible goods, such as a processed order or a flight
booking.
These views are integrated in a control view. This control view provides linkage
between the artefacts in the different views. Functions, for instance, are
associated with the organizations that are responsible for conducting these
functions. Analogously, data and business value artefacts are associated with
functions, data, and organization, providing an integrated view of the business
processes of an enterprise.
Process modelling uses event-driven process chains. The main building
blocks of event-driven process chains are events, functions, connectors, and
control flow edges, as shown in Figure 4.33.
The entering of a business-relevant state is represented by an event in an
event-driven process chain. Examples of events are the receipt of an order, the
completion of processing an order, and the completion of shipping a product.
In event-driven process chains, events are represented by hexagons. Events
are marked by a string, often of the type order is received, indicating a business
relevant object (order) and the state change that has occurred to this object (is received). Events trigger functions, and functions are triggered by events.
Events are passive elements in the sense that they do not provide decisions.
Functions represent units of work. The granularity of these functions depends
on the modelling purpose. In general, functions in event-driven process
chains are at a rather low level of granularity; their contribution to functions
at higher levels of granularity or to business goals is specified in the functional
view.
Unlike events, functions are active elements that take input and transform
it to output. Input and output can be information products or physical products.
Functions can also make decisions that influence the behaviour of the
process through connector nodes associated with the function. Functions are
triggered by events, and on the completion of a function, an event occurs. In
event-driven process chains, functions are represented by rounded rectangles.
Connectors are used to model causal ordering relations, i.e., to represent
the process logic. There are three types of connectors, for logical and, or, and
exclusive or (xor). These connectors serve both as split nodes and as join
nodes. Depending on the number of incoming edges, it can be determined if
a connector is a split connector or a join connector.
It is also possible that connectors serve at the same time as split connector
and join connector. In case split and join realize the same semantics (for
instance, both have and semantics), a connector with an and symbol suffices.
In case the split and join have different semantics, the connector can be divided
into an upper and a lower part, each of which holds a notational symbol. Other combinations
are also possible. Edges are used to provide the glue between events, functions,
and connectors. Event-driven process chains are defined as follows.

Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec L -- By Mathias Weske

Coloured Petri Nets

In event condition nets and place transition nets it is impossible to distinguish
tokens from one another. This shortcoming in simple types of Petri nets is
addressed by the colour feature, which allows tokens to have values.
Like variables in programming languages, tokens have typed values. The
data type of a token defines the domain of values and the operations that are valid on the data. In the context of coloured Petri nets, data types are
also called colour sets, with the understanding that a colour set of a token
represents the set of values that the token can possibly have.
In coloured Petri nets, the enabling of a transition is determined the not
by only number of tokens in the input places of the transition, but also by
the values of these tokens. Whether the precondition of a transition is met or
not depends on the presence and values of the tokens to be consumed. This
behaviour is realized by attaching expressions to transitions that are evaluated
to decide whether a transition is enabled.
Similarly, the values of the tokens produced by a transition firing may
depend on values of the tokens consumed. This also means that not all of
the output places receive tokens upon the firing of a transition, realizing a
choice of branches of the net based on the values of the token consumed and
the conditions attached to the transition. The specific firing behaviour of a
transition is specified in the postcondition of the transition.
As a result, the graphical representation of coloured Petri nets is not complete,
since expressions that denote preconditions and postconditions, as well
as values of tokens, are not shown.
While there are several variants of coloured Petri nets, the reminder of
this section introduces them as developed by Kurt Jensen. The behaviour
of transitions is guided by tokens in the input places, in guards attached to
transitions, and in expressions attached to arcs, the arc expressions.
Arc expressions are used to determine whether a transition is enabled.
Arc expressions evaluate to multi-sets, where multi-sets can contain multiple
identical elements. These multi-sets determine the tokens removed from the
input places and added to the output places of a transition when it fires.
Definition 4.6 A coloured Petri net is a tuple (, P, T, A,N,C, G,E, I) such
that
•  is a finite set of nonempty types, called colour sets
• P is a finite set of places
• T is a finite set of transitions
• A is a finite set of arc identifiers, such that P \ T = P \ A = T \ A = ;
• N : A ! (P ×T)[(T ×P) is a node function that maps each arc identifier
to a pair (start node, end node) of the arc
• C : P !  is a colour function that associates each place with a colour
set
• G : T ! BooleanExpr is a guard function that maps each transition to a
predicate
• E : A ! Expr is an arc expression that evaluates to a multi-set over the
colour set of the place
• I is an initial marking of the coloured Petri net
Bindings are used to associate data values to variables, i.e., colours to tokens.
For instance, the value “Paula” can be bound to a variable “name.” In coloured
Petri nets, the enabling of a transition depends on a binding. A transition t
is enabled in a binding b if its input places contain tokens that satisfy the
arc expressions under binding b and if in addition, the guard function of the
transition evaluates to true.
If a transition is enabled, it can fire. Depending on the evaluation of the arc
expressions, the respective tokens are removed from the input places. Guided
by the arc expressions of the outgoing edges, the respective tokens are added
to the output places. For a formal treatment of coloured Petri nets, the reader
is referred to the bibliographical notes at the end of this chapter.
The coloured Petri net has associated a colour set consisting of [Customer,
Amount] pairs of values, where Customer is a string and Amount is an integer
value. Coloured tokens represent specific [Customer, Amount] value pairs.
Initially, there are three tokens in the Credit Request place p1, representing
the credit requests by Paula, Mary, and Peter and their respective credit
amounts. The AssessRisk transition is enabled, because there is a token in
its input place and there is no additional guard function associated with that
transition.
The AssessRisk transition is enabled under binding c = Paula, and a =
15000, because there is a token [Paula,15000 ] at p1 that satisfies the arc
expression. Since there is no additional guard expression associated with that
transition, it is enabled, and it can fire.
The assess risk transition decides on which of its output places a token
should be put when it fires. The respective arcs are labelled postcon ditions that define the firing behaviour. Assuming a token carrying the value
[Paula,15000 ] is consumed, so that amount is below 20000, the AssessRisk
transition puts a token on p3 and not on p2, enabling the SimpleRiskAssessment
transition.
This behaviour of the coloured Petri net is due to the arc expressions
associated with the outgoing edges of the transition. When the transition fires,
the arc expressions of both outgoing edges are evaluated. Since the requested
amount is below 20000, only the arc expression if a <=20000 (c,a) is evaluated
to true, so that a token is put on p3, and no token is put on p2.
When the SimpleRiskAssessment transition fires, a token is put on p4.
The token also includes a value assessing the risk of the credit requested,
indicated by the arc expression (c, a, r), where r stands for a variable that
carries the assessed risk. Assuming there are two risk levels—represented by
values l for low and h for high—and Paula gets a low risk assessment, the
token [Paula, 15000, l] is put on p4.
Depending on the first letter of the credit requester’s name, the respective
inform customer transition is enabled. This decision is ruled by guard functions,
which are represented by functions placed on top of transitions. In the
example, the BeginsWith(name, interval) returns true if and only if name
begins with a letter in interval. Since the token for Paula is in p4, the transition
Inform Customer I-Z is enabled. After the customer is informed, the
process completes.
To summarize, the behaviour of a transition in a coloured Petri net is
defined by a guard function, by the tokens that reside in its input places, and
by arc expressions. Hence, transition firing in coloured Petri nets exhibits a
complex and highly customizable behaviour.
Therefore, it is valid to say that each transition in a coloured Petri net
has its own transition behaviour, which provides a high expressive power for
this class of Petri nets. At the same time, the graphical representation is no
longer sufficient to capture and understand the semantics of the Petri net.

Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec K -- By Mathias Weske

Condition Event Nets

Condition event nets are the fundamental class of Petri nets. In condition event
nets, at each point in time, each place can have at most one token. Tokens are
unstructured; they have no identity and can therefore not be distinguished
from one another. The rationale for the denomination of this Petri net class
is as follows. If a token is on a place p, then the condition p is met. When a
transition fires, an event occurs and changes the state of the condition event
net.
Definition 4.4 A Petri net (P, T, F) is a condition event net if M(p)  1 for
all places p 2 P and for all states M.
• A transition t is enabled in a state M if M(p) = 1 for all input places p
of t and M(q) = 0 for all output places q of t that are not input places at
the same time.
• The firing of a transition t in a state M results in state M0, where
(8p 2 •t)M0(p) = M(p) − 1 ^ (8p 2 t•)M0(p) = M(p) + 1.

Since, by definition, M(p) = 1 for all input places p of t and M(q) = 0 for all
output places q of t, it follows for the state M0 reached by this firing (assuming
output places and input places are disjoint),
(8p 2 •t)M0(p) = 0 ^ (8p 2 t•)M0(p) = 1.
Transition
t1 is enabled if and only if all input places have one token and all output places
have no tokens (a). This means that the conditions represented by the input
places of the transition are met and the conditions reflected by the output
places of the transition are not met.
The firing of t1 withdraws a token from each input place and puts a token
on each output place (b). Transition t1 is not enabled if there is a token in
one of its output places (c) or if not all input places of t1 have a token (d).
Since tokens in condition event nets are un-typed and cannot be distinguished
from each other, and due to the fact that the number of tokens are
limited to one in each place, condition event nets are not well suited to modelling
business processes. The reason for this is discussed in the context of
place transition nets that face the same problem.

Place Transition Nets

Place transition nets are an extension of condition event nets, because in any
state of the Petri net an arbitrary number of tokens can reside in any place.
Therefore, places can, for instance, serve as counters. However, tokens are still
unstructured objects that can not be distinguished from one another.
To account for multiple tokens in each place, transition enabling needs to
be reconsidered. In addition, multiple tokens can be consumed and withdrawn
from an input place when a transition fires, and multiple tokens can be produced
when a transition fires, according to the weights associated with the
arcs connected to the transition. This extension can be represented graphically
by multiple arcs from an input place to a transition or by arcs labelled
with natural numbers marking their weight.
Definition 4.5 (P, T, F, !) is a place transition net if (P, T, F) is a Petri net
and ! : F ! N is a weighting function that assigns a natural number to each
arc, the weight of the arc.
The dynamic behaviour of place transition is defined as follows:
• A transition t of a place transition net is enabled if each input place p
of t contains at least the number of tokens defined as the weight of the
connecting arc, i.e., if M(p)  !((p, t)).
• When a transition t fires, the number of tokens withdrawn from its input
places and the number of tokens added to its output places are determined
by the weights of the respective arcs. From each input place p of t, !((p, t))
tokens are withdrawn, and !((t, q)) tokens are added to each output place
q of t.
• The firing of a transition t in a state M results in a state M0, where
(8p 2 •t)M0(p) = M(p) − !((p, t)) ^ (8p 2 t•)M0(p) = M(p) + !((t, p))

The firing of t1 consumes the token from
p1 and adds a token to p2, so that two tokens reside in p2. Notice, however,
that t5 is not enabled, since p5 does not contain a token. In the example, each
arc has weight one.
While place transition nets allow multiple tokens in each place, they are
still not very useful for representing business processes, since the tokens cannot
be distinguished from each other. By closely looking
at the Petri net and its token distribution, one can detect which tokens
belong to which process instances.
There are three process instances active. One process instance is represented
by a token in place p1, while the second process instance has already
performed the receive order activity and is therefore represented by the token
in p2. The process order activity spawns two concurrent threads. Therefore,
the tokens in p3 and p6 must belong to the same process instance. When the
send order activity has been completed, a token is put in p5, and the complete
order activity can be performed, completing the third process instance.
In this case it is far from clear which tokens belong to the specific process
instance. The firing rule of place transition nets defines that the complete
order transition can fire as soon as there is a token in place p5 and a token in
place p6.
This is a severe problem, because the complete order activity could potentially
be conducted for two different process instances! If the first process
instance orders books A and B while the second process instance orders books
C and D, then a situation could occur in which the sending of books A and
B and the update of the inventory for books C and D could be joined, clearly
an unacceptable behaviour.
Therefore, the tokens need to carry values, so that in each state of the Petri
net it is clear which token belong to which process instance. This limitation
of condition event nets and of place transition nets will be lifted by coloured
Petri nets, discussed next.

Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec J -- By Mathias Weske

Petri Nets

Petri nets are one of the best known techniques for specifying business processes
in a formal and abstract way and, as such, Petri nets are an important
basis for process languages. “Formal” means that the semantics of process
instances resulting from process models specified in Petri nets is well defined
and not ambiguous. Petri nets are “abstract”, because they disregard the execution
environment of a business process, so that all aspects other than the
functional and process perspectives are not covered. The functional perspective
in itself is treated in an abstract way, as will be explained below.
In this section, Petri nets are introduced in a pragmatic manner. A large
body of literature is available in the Petri net area; the main references relevant
to business process management are discussed in the bibliographical notes.
In his Ph.D. thesis, Carl Adam Petri generalizes automata theory by concurrency.
He introduces a new modelling approach that has a graphical representation
as well as an equivalent mathematical formalization. Petri nets can
be used to model dynamic systems with a static structure. The static structure
is represented by a Petri net, and the dynamic behaviour is captured by
the token play of the Petri net.
Petri nets consist of places, transitions, and directed arcs connecting places
and transitions. They are bipartite graphs, so that arcs never connect two
places or two transitions. In graphical notations, places are represented by
circles, transitions by rectangles, and connectors by directed arcs. Transitions
have input and output places. The input places of a transition are the places
at the sources of its incoming arcs. Accordingly, a transition’s output places
are located at the end of its outgoing arcs.
The dynamics of the system represented by a Petri net is modelled by
tokens that reside on places. While the structure of Petri nets is fixed, the
tokens may change their position according to firing rules. The current distribution
of the tokens among the places determines the state of the Petri net
and, thus, of the system modelled by it.
A transition may fire if it is enabled. A transition is enabled if there is a
token in each of its input places. If the transitions fires, one token is removed
from each input place and one token is added to each output place. Different
classes of Petri nets exhibit different restrictions on the tokens in a Petri net;
this will be discussed later in this section.
The movement of the tokens in the Petri net according to firing rules is
called token play. The token play is often considered to be a flow of tokens, although this is not exactly true, since tokens are removed from input places
and added to output places; they do not flow from input places to output
places.
Because transitions can change the state of a Petri net, they are considered
active components, which typically represent events, operations, transformations,
or transportations. A place is a passive component, that stands for a
medium, a buffer, a state, or a condition. Tokens are used to represent physical
objects or information objects. In the context of business processes, transitions
represent activities and places containing tokens represent states of the
process instances.
Since Petri nets describe the structure of a system, a Petri net represents
a business process model, and its transitions represent activity models. The
instance level is captured by tokens. This means that the firing of a transition
represents an activity instance. Each process instance is represented by at least
one token; due to split and join nodes, the number of tokens that collectively
characterize one process instance may vary during the lifetime of the process
instance.
Since there can be multiple process instances of one process model, the
tokens in a Petri net may belong to different process instances. This will be
discussed in more detail in Section 4.4, where workflow nets, a Petri net class
specifically tailored towards representing business processes, are discussed.
A Petri net characterizing a business process model is shown in Figure 4.27.
The transitions in this Petri net correspond to activity instances, while the
places and the arcs characterize the execution constraints of the activity instances.
The process starts when a token is put on place p1. The token is
represented by a black dot in that place. Since there is a token on all input
places of the receive order transition, this transition is enabled, and it can
fire.
Once the receive order transition fires, a token is removed from p1 and
a token is put on p2, representing the execution of the receive order activity
instance. The execution time of this activity instance is not represented; in
Petri nets, transitions fire instantly without consuming time.
After the process order transition has fired, concurrent branches are
opened, since the firing of the process order transition puts tokens on both p3 and p4, enabling the send order and update inventory transitions. The
complete order transition is enabled only when both of these transitions have
fired. When the process completes there is one token in p7.
To summarize, the Petri net represents the process model, while the tokens
represent process instances. Since tokens in classical Petri nets cannot
be distinguished from each other, classical Petri nets can only host a single
process instance.
After informally discussing the basic structure of Petri nets and the dynamic
behaviour of the systems represented, we give a formal definition:
Definition 4.1 A Petri net is a tuple (P, T, F) with
• a finite set P of places,
• a finite set T of transitions such that T \ P = ;, and
• a flow relation F  (P × T) [ (T × P).
• A place p 2 P is an input place of a transition t 2 T if and only if there
exists a directed arc from p to t, i.e., if and only if (p, t) 2 F. The set of
input places for a transition t is denoted •t.
• A place p is an output place of a transition t if and only if there exists a
directed arc from t to p, i.e., if and only if (t, p) 2 F. The set of output
places for a transition t is denoted t•.
• p• and •p denote the sets of transitions that share p as input places and
output places, respectively.

Graphical representations of Petri nets can be mapped onto a tuple (P, T, F),
and vice versa. For instance, the Petri net shown in Figure 4.27 can be represented
by (P, T, F) such that
• P = {p1, p2, p3, p4, p5, p6, p7},
• T = {t1, t2, t3, t4, t5},
• F = {(p1, t1), (t1, p2), (p2, t2), (t2, p3), (t2, p4), (p3, t3), (p4, t4), (t3, p5),
(t4, p6), (p5, t5), (p6, t5), (t5, p7)}.
The state of the Petri net is characterized by the distribution of tokens on
the places of the net. The dynamic behaviour of a system is represented by
state changes, which are subject to firing rules. As detailed below, there are
different firing rules for different classes of Petri nets.
Definition 4.2 The marking (or state) of a Petri (P, T, F) net is defined by
a function M : P ! N mapping the set of places onto the natural numbers,
where N is the set of natural numbers including 0. 
The marking of a Petri net represents its state. The state of the Petri net
shown in Figure 4.28 is represented by M(p1) = M(p3) = M(p6) = 1 and
M(p2) = M(p4) = M(p5) = M(p7) = 0. If the places are totally ordered
by their identifier (as, for instance, in p1, p2, . . . , p7), the marking can be
expressed by an array. In the example, M = [1, 0, 1, 0, 0, 1, 0].
After having discussed the structure of a Petri net and its state, the dynamic
behaviour of a Petri net is addressed.
Definition 4.3 Let (P, T, F) be a Petri net and M a marking. The firing of
a transition is represented by a state change of the Petri net.
• M t! M0 indicates that by firing t, the state of the Petri net changes from
M to M0.
• M ! M0 indicates that there is a transition t such that M t! M0.
• M1 ! Mn means that there is a sequence of transitions t1, t2, . . . tn−1 such
that Mi
ti! Mi+1, for 1  i < n.
• A state M0 is reachable from a state M if and only if M ! M0.

Based on these fundamental definitions, a number of Petri net classes are
introduced that differ with respect to their firing behaviour and the structure
of their tokens.

Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec I -- By Mathias Weske

Milestone

The milestone pattern can be used to define that an activity is only enabled
if a certain milestone has been reached that has not expired yet.
This pattern is illustrated by an example. Consider a process model with
activity models A,B, and C. With a milestone pattern, the process designer
can determine that activity instance a is enabled only if b has been executed
and c has not been completed. As a result a is not enabled before the execution
of b and after the execution of c.
Since the informal process modelling
notation that served well in presenting the patterns so far does not
provide an explicit notation for state, Petri nets are used to express the milestone
pattern (Petri nets will be introduced in the next section in detail).
The milestone indicates that the execution of an activity a is possible only
after activity b is executed and before activity c is started. There can also be
multiple instances a1, a2, . . . of activity model A, as long as c has not started.

Run Time Patterns

In addition to the patterns introduced above, there are run time patterns
defined that are—strictly speaking—not part of a process model. They, rather,
characterize the functionality provided by a business process management
system.
The first of these patterns is the cancel activity pattern. When an activity
instance is cancelled, it enters the cancelled state.
The second run time pattern is the cancel case pattern, in which all activity
instances of a process instance are cancelled so that the process instance
comes to a halt. To cancel an activity instance, there are different options that
depend on the environment in which the activity instance is being executed.
If it is a manual activity, then the knowledge worker needs to be informed
about the cancellation, so that the person ceases working on the case. She
could also perform some cleanup activities, if need be.
If the functionality to execute the activity instance is provided by an information
system, then the realization of the cancel activity pattern depends
on the type of information system used. If the information system is realized
by a database application, then terminating the application is a valid option.
If the database application runs—at least the parts that realize the activity
instance to be cancelled—in a single database transaction, then cancellation
can be realized by aborting the transaction. The database management system
guarantees that the database is restored to the state before the execution of
the activity instance.
If on the other hand the information system is not based on a transactional
information system, cancelling an activity can be much harder. There might
be certain parts that are already stored in some kind of non-transactional
data store. Identifying these parts and manually undoing the effects of the
partial activity instance is a cumbersome and in some cases infeasible task.
Also in manual activities, actions might already have been performed that
cannot be undone easily, such as sending an email message. In this case, the cancellation of an activity instance involves manual activities, such as sending
another email message withdrawing the former, or making a phone call.
To summarize, it is easy to indicate the behaviour of the cancel activity
and cancel case patterns; however, the realization of these patterns in realworld
business process management systems is far from that.