BUSINESS PROCESS MANAGEMENT -- Solutions To Business Processing By Experienced Authors

Business Process Management (Part-2 Business Process Modelling[Chapter VI Properties Of Business Processes ] ) Sec D -- By Mathias Weske

2010-03-20T15:20:00.000+05:30

Soundness Theorem

Reachability analysis based on reachability graphs is a simple method to characterize
the cases that comply with a given workflow net. However, reachability
analysis only works well for small examples. The reachability graphs of
real world business processes involving dozens of activities suffer from state
explosion, which renders reachability graph analysis inappropriate in these
settings.
Besides manually creating a reachability graph and checking for the
three properties of workflow nets that collectively define soundness, there
are computer-supported ways to determine soundness. The first class of approaches
creates the reachability graph automatically and checks the soundness
property. Due to the state explosion problem, this approach suffers from
exponential run time behaviour. As a result, the creation of the reachability
graph might not be feasible for real-world applications.
But there are other options that take advantage of the rich set of tools
that have been developed by the Petri net community. In the reminder of this
section, one of these approaches is discussed. It is based on a theorem that boundedness.
The general idea is deriving a Petri net from the workflow net to be checked
for soundness, as sketched in Figure 6.10: By adding a transition t to a
workflow net PN, and linking the final place o to t and t to the initial place
i, a Petri net PN0 is created.
We can show that PN0 is live and bounded if and only if PN is sound. As
a consequence, existing techniques to analyze liveness and boundedness for
Petri nets can be used to check a workflow net for the soundness property.
For an important subclass of Petri nets, there are efficient analysis techniques
for liveness and boundedness. This renders the check for soundness of
workflow nets an efficient task, even for large workflow nets, which can be
found in real-world scenarios.
Theorem 6.1 A Workflow net PN = (P, T, F) is sound if and only if
(PN0, i), such that PN0 = (P0, T0, F0), P0 = P, T0 = T [ {t }, and
F0 = F [ {(o, t ), (t , i)}, is live and bounded.
To prove this theorem, we first show that if PN0 is live and bounded, then PN
is a sound workflow net. Then, it is shown that from the soundness property
of the workflow net, liveness and boundedness properties of the Petri net PN0
follow. The proof is illustrated in Figure 6.10.
Since PN0 is live, for each transition there is a firing sequence starting
in the initial state i that activates it. This is especially true for the added
transition t . Since o is the only input place of t , we can conclude that there
is a state M reachable from i with at least one token in o, i.e., M o.
When t fires, a token is put on the initial place i. Again, there is a firing
sequence that leads to a state in which there is a token in o. Since PN0 is
bounded, M = o, because otherwise tokens would aggregate in a place of the
Petri net.
Now we show that if PN is sound, PN0 is bounded. This is shown by
contradiction. Assume that PN is sound, but that PN0 is unbounded. Since
PN is sound and (by assumption) PN0 is unbounded, there exist states M,M0
such that i ! M ! M0 and M0 M, allowing the aggregation of tokens in
a place of PN0.
Since PN is a sound workflow net, there exists a firing sequence such
that i ! M ! o. Applying the same firing sequence to state M0 leads to
a state M00 > o. This means that in M00 there is a token in o; but there is
at least one additional token in the net! This is a violation of the soundness
property of PN and shows the contradiction.
Finally, we have to show that if PN is sound then PN0 is live. Soundness
implies that each transition can participate in a firing sequence leading from
the initial state i to the final state o. By firing t , the initial state i can be
reached, so that liveness of PN0 follows. For arbitrary Petri nets, liveness and boundedness are still complex to
compute, so that exponential run time behaviour can be expected. However, for an important subclass of Petri nets, liveness and boundedness can be
computed in polynomial time. This subclass is free choice nets. Free choice
nets have the property that the sets of input places of two transitions are
either disjoint or identical.

Business Process Management (Part-2 Business Process Modelling[Chapter VI Properties Of Business Processes ] ) Sec C -- By Mathias Weske

2010-03-20T15:19:00.001+05:30

Soundness

The first soundness criterion for business processes was developed by Wil van
der Aalst in the context of workflow nets; but this criterion is also applicable to
other process modelling notations. For this, the execution semantics of these
languages have to be taken into account. If formal proofs are required, then
process languages with a formal execution semantics, such as workflow nets
are needed.

Motivation of Soundness

In order to motivate the soundness criterion, a number of workflow nets with
errors are discussed. Figure 6.4 shows a workflow net with two transitions
which exhibit an exclusive or split behaviour and an and join behaviour.
The exclusive or split transition t1 puts a token either in the upper input
place of t2 or in the lower input place of t2, but not in both places. As a
consequence, the and join transition t2 can never be enabled, because not all
input places have tokens. Therefore, cases based on the workflow net shown
will suffer from deadlock—no case will ever terminate.

While in a deadlock the activities involved can never be executed, in a
livelock situation a set of activities are trapped in an infinite loop. Livelock
can be the consequence of different types of errors in process models. If a
condition to enter a loop is always evaluated to true, then the loop is never
left. This type of error cannot be detected on the basis of process models.
Not only can erroneous conditions in decision nodes lead to livelock, but
also erroneous process structures, as shown in Figure 6.5. This workflow net
suffers from the fact that the loop is entered by an and split transition and not
by an exclusive or split transition. Therefore, the loop is repeatedly iterated,
realizing a livelock situation.
In addition to the livelock, this workflow net also suffers from the fact that
each time the loop is iterated, one token is put in the output place. Therefore,
a token in the output place no longer indicates the completion of the process.
A workflow net that suffers from different problems is shown in Figure 6.6.
Depending on the decision made by the exclusive or split transition t1, either
a deadlock or an improper termination occurs. If t2 puts a token on p1, then the and join transition t3 cannot be enabled, since there will not be a token
at place p3. As a consequence, a deadlock situation will occur.
If, however, t1 puts a token in p2, then t2 can fire, putting a token in
the output condition o. At this point, there is still a token in p3, showing a
situation similar to that in the previous case: the process instance does not
terminate properly because the process runs even after a token is put in the
final place.6.3.2 Definition
Based on these observations, soundness in workflow nets is defined. The idea
of the soundness criterion is to make sure that all tasks can participate in
a process instance; each process instance eventually terminates, and when it
terminates there is exactly one token in the final place.
In order to formally specify sound workflow nets, the following definition
on the states of a workflow net is useful.
Definition 6.2 Let PN = (P, T, F) be a workflow net, i 2 P be its initial
place, o 2 P its final place, and M,M0 markings.
• i is the state in which there is exactly one token in place i 2 P and no
token in any other place of the workflow net
• o is the state in which there is exactly one token in place o 2 P and no
token in any other place of the workflow net
• M M0 if and only if M(p) M0(p), 8p 2 P
• M > M0 if and only if M M0 ^ 9p 2 P : M(p) > M0(p)

Using these definitions, the soundness criterion can be specified in a formal
way.Definition 6.3 A workflow system (PN, i) with a workflow net PN =
(P, T, F) is sound if and only if
• For every state M reachable from state i there exists a firing sequence
leading from M to o, i.e.,
8M(i ! M) =) (M ! o)
• State o is the only state reachable from state i with at least one token in
place o, i.e.,
8M(i ! M ^M o) =) (M = o)
• There are no dead transitions in the workflow net in state i, i.e.,
(8t 2 T) 9M,M0 : i ! M t! M0

Reachability analysis can be used to decide whether a given workflow net
is sound. The idea of reachability analysis is that the states and the state
changes of process instances are represented explicitly. Reachability graphs
are used to represent the different states that a process instance can take.
A reachability graph consists of nodes and labelled edges, where the nodes
correspond to states of the workflow net and the edges represent state transitions.
State transitions occur by firing transitions. Therefore, each state transition
is labelled with the transition that realized this state transition.
Definition 6.4 A directed graph G = (V,E, l) is called a reachability graph
of a workflow net PN if V corresponds to the set of reachable states of the
workflow net and E V × V corresponds to state transitions. The mapping
l : E 7! P(T) assigns to each edge a set of transitions, such that (M,M0) 2
E , M t! M0 for each t 2 l(E).
This definition is illustrated by the example shown in Figure 6.7. The workflow
net shown represents a business process for handling claims. The initial
place of that workflow net is called claim, and ready is the final place. The
initial state is (1, 0, 0), where the tuple contains the number of tokens at the
(claim, record, ready) places, in that order.
Note that the state transitions involving the under consideration and ready
places can be achieved by firing either the pay transition or the send letter
transition. Hence l((0, 1, 0), (0, 0, 1)) = {pay, send letter}.
A workflow net with a loop is shown in Figure 6.8. The exclusive or split
transition B is used to decide whether or not to iterate the loop. Figure 6.9
shows the corresponding reachability graph. In this case, the loop in the workflow
net is reflected by a loop in the reachability graph.

Business Process Management (Part-2 Business Process Modelling[Chapter VI Properties Of Business Processes ] ) Sec B -- By Mathias Weske

2010-03-20T15:17:00.001+05:30

Structural Soundness

In this section, the structure of business process models is investigated, and
an initial soundness criterion is introduced. While the considerations in this
section hold for process models represented in any of the process orchestration
languages introduced above, this section uses Petri nets, in most cases,
workflow nets, to represent these structural errors. The reasons are not only of
historical nature—workflow nets were the first approach for which soundness
was investigated—but also practical: the formal foundation of workflow nets
allows to formally specify and reason about soundness properties.
The type of structural error discussed in this section can be characterized
by dangling transitions or places, i.e., transitions without input places or output
places. Petri net with dangling places and transitions.
Notice that this Petri net is not a workflow net, since there are multiple places
without incoming edges and not all nodes, for instance, t5, are on a path from
i to o.
When a token enters the Petri net in place i, transition t1 is enabled. Note
that there is no way that t4 can ever be enabled. When t2 fires, t5 and t3
are enabled. When t3 terminates, the output place o is reached, signalling
the completion of the case. However, at this point in time, t5 could still be
running! As a consequence, the token at the output place o does not signal the
completion of the case. These types of errors are ruled out by the definition
of workflow nets.
This example motivates the development of correctness criteria for process
models to prevent the modelling errors discussed. The simplest correctness criterion uses the structure of business process models. It is inspired by the
definition of workflow nets and takes advantage of the definition of workflow
nets.
Definition 6.1 A process model is structurally sound if the following conditions
hold:
• There is exactly one initial node, which is the only node without any
incoming edges.
• There is exactly one final node, which is the only node without any outgoing
edges.
• Each node in the process model is on a path from the initial node to the
final node.

Structural soundness also goes well with the definition of business process
models, which states that business process models consist of related activities.
Structural soundness makes this relationship concrete by defining that each
activity is embedded in the context of the process and that no activities are
independent of other activities of the same business process.
Many business process languages enforce structural soundness, for instance,
event-driven process chains and business process diagrams expressed
in the Business Process Modeling Notation. However, the process designer has
the freedom to use these process languages to design process models that are
structurally sound.

Business Process Management (Part-2 Business Process Modelling[Chapter VI Properties Of Business Processes ] ) Sec A -- By Mathias Weske

2010-03-20T15:14:00.002+05:30

Data Dependencies

Application data are an integral part of business processes. Data can be created,
modified, and deleted during the execution of business processes. Since
business processes consist of a set of activities that are related, these activities
operate on an integrated set of application data.
Data in business process models has two aspects, both of which need to
be covered:
• Data that activity instances manipulate by invoking applications or services.
• Data dependencies between process activities.
The former issue is dealt with in the operations subdomain. In service-oriented
systems architectures, for instance, the parameters of service invocations are
specified, so that data can be communicated correctly with software systems
at run time.
At the process level, data dependencies between process activities is typically
described by data flow. An example of data flow in a business process in
the financial sector is given. A credit approval business process contains activities
to enter a credit request, to assess the risks of granting the credit, and
to inform the customer about the decision made by the financial institution.

The activities of this process model operate on case data, in particular,
the credit request. The credit request can be represented by a record data
type with fields for the name and address of the credit requester, the amount
requested, and other information, such as the risk related to granting the
credit.
There are data dependencies between the activities mentioned. The Collect
Credit Info activity is the first activity performed. Only when this data
is available, can the risk be assessed in the Assess Risk activity, the final
decision be made(Decide), and the requestor be notified (Notify). Therefore,
the ordering of the activities in the business process is strongly related to the
data dependencies of the activities.
The process model is illustrated , using a graph-based process
language that explicitly represents input and output parameters of activities and data dependencies. Observe that the actual data transfer can be performed
by passing references to data objects or values of data objects, as
described the context of workflow data patterns.
This diagram shows that data dependencies have implications on the ordering
of activities in the process: the Assess Risk activity can be started only
when the credit information is available. Since this data object is provided as
output parameter CreditInfo of the Collect Credit Info activity, this activity
needs to complete before the risk can be assessed, implying an ordering
between these activities.
This example shows that data dependencies between process activities are
reflected by data flow. A data flow edge between an output parameter of one
activity and an input parameter of another activity represents the fact that
the latter activity requires a data value that the former generates. In the
example, the Collect Credit Request activity generates an output parameter
CreditInfo that the Assess Risk activity requires for its start.
If, as assumed so far, output parameter values are only available when the
respective activity terminates, there is a direct implication of data flow on
control flow. This property is known as control flow follows data flow, and it
is explained as follows.
Control flow needs to follow data flow, since otherwise the process instance
would come to halt. This observation is illustrated in an example
where a data dependency from the Assess Risk activity to the
Decide activity is shown, while the control flow constraint exists, for some
reason, in the opposite direction.
As a result, neither of these activities can be started, because control flow
defines that Assess Risk can only start after Decide has completed, and Decide
can only start after Assess Risk has generated the risk factor data value.
Because the risk factor value is only available when the activity terminates,
both activities are stuck in a permanent waiting condition, and a deadlock
situation has occurred. The process model results from a
modelling mistake, and the control flow follows data flow rule can be used to
detect these kinds of modelling mistakes.

These considerations hold only if it is assumed that an activity instance
requires its input parameters at the start. If this constraint is relaxed and
input parameters can be consumed after an activity instance has started,
then in a process with a data flow A ! B, B can actually start before A
terminates. At some point—when the input values are required—B needs to
wait for A to deliver the required data.
This assumption can also be relaxed at the producer side of data. If we
allow activities to generate data while they are running, then the generated
data can be taken by the follow-up activity, so that activities can execute
concurrently, realizing a data value stream between them.
While most workflow management systems assume that input data is available
up front and that only on completion, does an activity instance write
output data values, some approaches, for instance, the BPMN, relax this assumption.
The use of data dependencies for process enactment control will be discussed
in more detail in the context of case handling , where
data dependencies—and not the proce

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

2009-12-20T17:28:00.001+05:30

Advanced Control Flow Relating Interactions

In addition to the basic control flow constructs, there are advanced control
flow constructs in Let’s Dance. Several interactions can belong to a composite
interaction. None of the contained interaction instances can become enabled
before the enclosing composite interaction instance has become enabled, and
the composite interaction instance can only complete after all contained interaction
instances have completed or been skipped.
Interactions can also be guarded, meaning that at the moment an interaction
instance could become enabled, a guard condition must be fulfilled. If this
condition is not fulfilled, the instance is skipped. Finally, repetitions and parallel
branching with an unbounded number of branches are modelled through
repeated interactions. There are four types of repeated interactions, similar
to those in programming languages: while, repeat, for each (sequential), and
for each (concurrent).
“For each” repetitions have an expression attached that determines a collection
over which the repetition is performed. The knowledge about how
many instances are to be created for this interaction might be available at
design time or might be known only at run time.
Repetitions can have stop conditions attached to them. For instance, a
repeated receive interaction should be stopped as soon as answers from ten
participants have arrived.
The expressions attached to guarded and repeated interactions can be
written in plain English, as Let’s Dance is not tied to any specific expression
language. However, it must be defined which actor is going to check whether
a condition evaluates to true or which collection results from a repetition
expression.
After a buyer has submitted her order to a supplier, the supplier
sends back an order response for every item in the order. After all responses
have been sent, the order cannot be cancelled by the buyer.
This desired semantics of the process choreography is expressed through
the inhibits relationship from the Order Response interaction to the Cancel Order interaction. If a cancellation is issued by the buyer on time, the supplier
can decide whether it can still be cancelled or not.
If cancellation is still possible, the remaining order responses are skipped
and the buyer does not need to pay. In the case where cancellation is not
possible, a corresponding rejection notice is sent to the buyer and the buyer
has to pay for the order. The buyer notifies the supplier through a payment
notice.

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

2009-12-20T17:25:00.002+05:30

Basic Control Flow Relating Interactions

As seen in the milestone example, a precedes relationship between two
interactions means that an instance of the target interaction can occur only
if the instance of the source interaction has already occurred. If in a logistics
environment a delivery acknowledgment message should be sent only after a
delivery notification has been received, a precedes relationship between the
respective elementary interactions can be used to represent this business rule.
An inhibits relationship indicates that an instance of the target interaction
can occur only if no instance of the source interaction has occurred yet. In
an example involving an order process, an invoice should not be sent after an
order cancellation by the buyer has been received.
Also, scenarios where two interactions inhibit each other, i.e., an instance
where either one or the other interaction can complete, are very common.
Consider, for instance, a travel agency that either receives a confirmation
message from the customer or a cancellation message from the airline. To
cater to these situations, a specific notational element for vice-versa-inhibits
is introduced.
A weak precedes relationship means that an instance of the target interaction
can occur only after the instance of the source interaction has already
completed or was skipped. Imagine a project management scenario where the
project leader expects status updates from a subcontractor that are merged
into a status report for the employer. However, in special cases the project
leader and the subcontractors can agree that no status update is needed.
Interaction
instances can be in the states initialized, enabled, completed, and skipped. An
interaction instance becomes skipped if any of the inhibiting instances has
completed.
An interaction instance becomes enabled if there are no precedes or weak
precedes relationships targeting the corresponding interaction or all preceding
instances are completed and all weakly preceding instances have been
completed or were skipped.
An instance must execute, i.e., the actual message exchange occurs, only
if it is enabled. After the message exchange, the instance is in the completed
state
The conversation starts with the Seller sending an Auction creation request
message to the Auctioning service. The precedes relationship defines that, if
this message arrived, an Account creation request message can be sent to the
Seller. Then, the Seller sends a Registration info message to the Auctioning
service, which responds with an Registration confirmation message.
The weak precedes relationship connecting the last elementary interactions
defines that the Auctioning service can send an Auction creation confirmation
to the Seller if it has either sent a Registration confirmation message before or if the sending of that message was skipped. The latter is used to cater to
situations in which a Seller is already registered at the Auctioning service.

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

2009-12-20T17:24:00.000+05:30

Modelling Interactions

The main focus of Let’s Dance is to capture interactions and their behavioural
dependencies. Elementary interactions are the building blocks by which complex
interaction rules can be defined.
An elementary interaction is a combination of a send activity model and
a receive activity model. An actor reference belonging to a role is given for
every activity model. This reference indicates which activity instances must
be performed by the same participant. Typically, there is only one participant
per role involved in a conversation. In these cases, the actor reference can be
omitted in the diagrams.
It defines an interaction
between a participant of role Seller and a participant of role Auctioning
Service. It also states that a message of type Auction creation request is sent
during the interaction.
At the right-hand side in that figure, a conditional elementary interaction
is shown. Conditional elementary interactions are valid only if the condition is
met. In the example shown, the Auctioning Service sends an Account creation
request message to the seller only if the seller is not registered.

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

2009-12-20T17:22:00.001+05:30

High-level Choreographies

In the design of high-level choreographies, a structural, role-based view and a
behavioural milestone view can be distinguished. Let’s Dance supports both
views. At the centre of attention are roles that describe the participants of a
process choreography; these roles are depicted as boxes. Typically, there is
at most one participant per role involved in a choreography. If potentially
multiple organizations of the same role participate, overlaid boxes are used to
represent such multiplicity, as shown for role B . Channels represent interaction dependencies between roles; they are depicted
as small circles on lines connecting the roles. In the figure, a channel
between roles A and B is shown. The meaning of such a channel is that participants
of roles that are connected through channels might interact. If on the other hand there is no channel between roles, then the participants cannot
interact • Part-of Relationship: One role is part of the other role. In this case, a
participant of the subrole is part of the participant of the super-role.
For instance, a car manufacturing company can be decomposed into a
number of production sites, warehouses, and management facilities. In
terms of interaction behaviour, interaction models assigned to the superrole
are assigned to one or several of the subroles in a refinement step. For
instance, a second company interacting with the car manufacturer might
in fact only be able to interact with the management division of the car
manufacturer.
• Specialization: A subrole can also be a specialization of the super-role. The
subroles therefore inherit the interaction behaviour of the super-role. If an
interaction is possible with a participant of the super-role, then such an
interaction must also be possible with the participants of all subroles.
As an example of role specialization, consider a super-role “Carrier” and
its specializations “Land Carrier” and “Air Carrier.”
Channels can be refined into message links. While channels are not directed,
message links are directed, because they describe the flow of a message
from a sender to a receiver. Message names need to be specified for every link,
A channel can be used to represent that a seller interacts with an auctioning
service. Different message links could then refine this channel. In this way,
it could be specified that an auction creation request link from the seller to the
auctioning service is available, as is a creation confirmation link in opposite
direction. The three roles Seller, Bidder, and Auctioning Service are interconnected
through channels. Furthermore, at most one seller, at most one auctioning
service, and potentially many bidders participate in a choreography instance Milestones represent goals and subgoals to be reached during the choreography,
and at the same time serve as synchronization points in the choreography.
Milestones in Let’s Dance are depicted by filled diamonds. For each
milestone, it can be specified which participants should be synchronized when
the milestone is reached.
Different control flow constructs are available to represent the dependencies
between milestones. At this point, we will only explain the semantics of
precedes relationships. The other relationship types will be introduced shortly.
If a milestone m1 precedes a milestone m2, then m1 has to be reached before
m2 can be reached. However, there is no guarantee that m2 will eventually be
reached once m1 has been reached.

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

2009-12-20T17:20:00.001+05:30

Let’s Dance

Petri nets were used to express process choreographies.
The main idea was to show the behavioural interfaces for the participants
of a process choreography and their interconnection using message flow. As
an alternative to modelling behavioural interfaces, languages for expressing
interaction models directly have been designed. The main difference to modelling
connected behavioural interfaces is that interactions are used as basic
building blocks for choreographies, and behavioural dependencies are defined
between these interactions.
Let’s Dance is a choreography language following this interaction-centric
approach. It is based on control flow patterns and service interaction patterns.
Control flow specification is the main focus, so the language abstracts
from concrete message formats. Let’s Dance comes with two different diagram
types for supporting high-level modelling of process choreographies through
milestones and for modelling detailed collaboration scenarios.

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

2009-12-20T17:18:00.001+05:30

Contingent Requests

In the contingent requests pattern, a participant sends a request to another
participant. If this participant does not answer within a given time, the request
is sent to a second participant. Again, if no response comes back, a third
participant is contacted, and so on. Delayed responses, i.e., responses arriving
after the time-out has already occurred, might or might not be discarded. If this employee does not accept the task on time, it is delegated
to another employee, and so on.

Atomic Multicast Notification

The atomic multicast notification pattern is explained as follows. A participant
sends out notifications to several other participants who have to accept the
notification. In specific cases, only one participant is required to accept it;
in other cases, a subset of the participants or all participants are required to
accept it.
Imagine a production scenario with just-in-time delivery of some of the
components while the remaining components are kept in stock. Sometimes,
some of the components are not delivered on time.
In order to avoid getting components out of different warehouses and piling
them in front of the production facilities, the availability of all needed
components is checked. Only if all of them are available are the components
ordered to the production facilities.

Request With Referral

The request with referral pattern is especially important in service-oriented
environments where a registry is in place that allows binding to services at run
time. But also simple types of dynamic behaviour can be represented by this
pattern, for instance, the transmission of a new collaboration partner during
an interaction. In particular, the request with referral pattern can be used if a participant
A sends a message to another participant B containing a reference to participant
C. Although B does not need to know C in advance, B can now interact
with C. This pattern describes the concept of link passing mobility. As an example of this pattern, consider a customer who buys a set of books
online. The bookstore redirects the customer’s Web browser to the Web page
of an external payment service. Conceptually, this means that the bookstore
refers the payment service to the customer, who can then use the service,
although the customer was not aware about this service beforehand.

Relayed Request

The relayed request pattern is common in emailing collaboration scenarios.
A participant A sends a request to another participant B who forwards it to
a third participant C who will actually interact with A. However, B always
gets copies of the messages exchanged in order to be able to observe the
conversation. As part of
a quality management program in the company and for legal reasons, all interactions
between the payroll services provider and the employees are being
tracked.

Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec H -- By Mathias Weske

2009-11-19T22:19:00.002+05:30

Send

The send pattern represents a one-way interaction between two participants
seen from the perspective of the sender. There are different flavours of this
pattern, considering, for instance, the moment when the sender selects the
receiver: The receiver is known either at design time of the choreography or
only during the execution of a conversation.

Receive

The receive pattern also describes a one-way interaction between two participants,
but this time seen from the perspective of the receiver. In terms of
message buffering behaviour of the receiver, two cases can be distinguished.
Messages that are not expected are either discarded or stored until a later
point in time, when they can be consumed.The receipt of the message is represented by a start
message event. On occurrence of this event, a process orchestration is started
in the facility management that checks the heating system and tries to find
the source of the problem.

Send/Receive

In the send/receive pattern, a participant sends a request to another participant
who then returns a response message. Both messages belong to the same conversation. Since there could be several send/receive interaction instances
happening in parallel, corresponding requests and responses need to
be correlated.If, for instance, a procurement department requests quotes for different
items from different suppliers, the different request/response pairs belong to
different conversations. In this situation the procurement department must be
able to tell which quote belongs to which request.
Therefore, correlation information must be placed inside the messages.
For instance, the request could carry a request identifier which is then also
contained inside the response message.

Racing Incoming Messages

Racing incoming messages are common in business-to-business scenarios; this
pattern is described as follows: a participant is waiting for a message to arrive,
but other participants have the chance to send a message. These messages by
different participants “race” with each other. Only the first message arriving
will be processed.
The type of the message sent or the category the sending participant belongs
to can be used to determine how the receiver processes the message.
The remaining messages may be discarded or kept for later consumption.
This aspect is not covered by the racing incoming messages pattern.

One-To-Many Send

A participant sends out several messages to other participants in parallel. It
might be the case that the list of recipients is already known at design-time of
the choreography or, alternatively, the selection of the recipients takes place
in the course of the conversation
In the BPMN, this pattern is represented by a multiple instances task
that sends election notices to all voting citizens. In this case, each citizen is
represented by an individual pool.
However, we could have used a single pool and assigned the role citizen to
this pool. In this case, the sending of election notices would be a single send
activity, and the multiplicity would only be introduced by multiple citizen
roles. Since the first alternative captures the one-to-many send pattern more
appropriately, we have chosen this illustration alternative.

One-From-Many Receive

In the one-from-many receive pattern, messages can be received from many
participants. In particular, one participant waits for messages to arrive from
other participants, and each of these participants can send exactly one message.
Typically, the receiver does not know the number of messages that will
arrive, and stops waiting as soon as a certain number of messages have arrived
or a time-out occurs.
Imagine an auctioning scenario in which the bidders bid by sending a
message directly to the seller. Each bidder can send exactly one message. The
seller accepts these messages until the auction is over, and then decides on
the highest bid.

One-To-Many Send/Receive

In the one-to-many send/receive pattern, a participant sends out several requests
to different other participants and waits for responses. Typically, not all responses need to be waited for. The requester rather waits for a certain
amount of time or stops waiting as soon as enough responses have arrived.
A travel agency looks for the best offer for a flight on a certain route. The
agent therefore initiates requests and the airlines give their prices and current availability.

Multi-Responses

In the multiple responses pattern, a participant sends a request to another
participant who sends back multiple messages. An important question in this
scenario is how the requester knows that there are no more messages to be
expected.
One option would be that the messages contain information about whether
there will be more messages or not. Another option could be that the last
message is of a special type. Finally, also a time-out could be used to stop
waiting for further messages.
In a logistics scenario, the shipper sends status messages about the delivery
to the owner of the goods at the end of every day. As soon as the goods have
arrived at their destination a delivery notification is sent.

Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec G -- By Mathias Weske

2009-11-19T22:17:00.001+05:30

Service Interaction Patterns

However, there are several differences between
process orchestrations and process choreographies that need specific consideration:
choreographies are based on message exchange, and potentially many
participants interact in a choreography, while orchestrations are based on
control flow between the activities of a single process performed by a single
organization.
Service interaction patterns aim at filling this gap by proposing small granular
types of interactions that can be combined to process choreographies. As
with control flow patterns for process orchestrations, service interaction patterns
can also be used to benchmark languages for their ability to express
advanced conversations. Service interaction patterns can be classified according
to the following schemes.
• Number of participants involved: Bilateral interactions involve two participants,
whereas multilateral interactions involve more than two participants.
• Number of messages exchanged: Single transmission versus multi-transmission
interactions.
• Variations in message receiver : In case of two-way interactions, round-trip
interaction means that the receiver of the message is necessarily the same
as the sender, whereas routed interaction means that the receiver of the
message in general differs from the sender.
The Business Process Modeling Notation is used to provide graphical representations
of service interaction patterns. Since this notation is not specifically
tailored to the needs of service interaction patterns, the graphical representations
of the patterns are not complete. Together with the textual representation
of the patterns, the service interaction patterns are described properly.

Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec F -- By Mathias Weske

2009-11-19T22:15:00.001+05:30

Process Choreography Implementation

After discussing the design of process choreographies, this section looks at the
implementation of choreographies. Behavioural interfaces serve as blueprints
for the internal realization of process orchestrations, because each process orchestration
needs to expose an externally visible behaviour that was specified
as the behavioural interface of the respective participant.
Assume that there is a set of behavioural interfaces compatible with each
other. These interfaces can now be refined to local process orchestrations. In
local process orchestrations, activities can be added or, in some cases, even
reordered, while the observable behaviour has to be preserved.
The relationship between the behavioural interface and the local process
orchestration needs to be investigated, so that the correctness of the overall
collaboration can be achieved. Each local process orchestration needs to be
consistent with the respective behavioural interface definition. This section
will introduce consistency criteria using a business-to-business collaboration
scenario.
Figure 5.16 provides an overview of the participants in that scenario: a
Buyer—for instance, a car manufacturer—uses reverse auctioning for procuring
specific components. To ease the selection of an appropriate Supplier and
to manage the auction, the buyer outsources these activities to a dedicated
Auctioning Service. A Shipper is selected to transport the ordered goods from
the supplier to the buyer.
As in the example discussed above, the auction is not public, so that
only registered parties can participate. Therefore, suppliers need to request
permission to participate in the auction beforehand. Once the auction has
started, suppliers can place their bids. When the auction completes, the buyer
selects a supplier according to the lowest bid or according to some other
evaluation criterion. Finally, the goods are shipped and payment is processed.
In this sample scenario, there are two alternatives for selecting a shipper:
either the selected supplier determines the shipper that would deliver the
goods to the buyer, or the supplier provides a list of shippers with different
transportation costs and quality levels, from which the buyer can choose a
shipper.
There can be several suppliers, shippers and—in
a generic setting—multiple buyers and auctioning services. In this figure, each
participant role is specified by a set of its behavioural interfaces, as discussed
in the previous section. These interfaces need to be compatible with each
other, so that the collaboration will be successful.

Each participant role can be potentially played by several process participants.
Each of these process participants develops a process orchestration.
These process orchestrations need to be consistent with the behavioural interface
of the participant role. For instance, the process orchestration of supplier
Su1 needs to be consistent with the behavioural interface (or with the behavioural
interfaces) of the Supplier role.
Using consistency rules, each participant can check locally whether its local
business process orchestration fits its behavioural interface. If the behavioural
interfaces are compatible with each other and if, in addition, for each
participant, the internal business process orchestration is consistent with its
behavioural interface, then a successful collaboration between the process participants
is realized—additional checks involving the internal business process
orchestrations of the participants are then not required.
The behavioural interface of a participant role leaves room for multiple
process orchestrations, i.e., there are multiple process orchestrations consistent
with a given behavioural interface.
In order to illustrate this, Figure presents three process orchestrations
for the buyer role in the reverse auctioning example, namely B1, B2, and B3.
While the structure of the process orchestrations is at first sight similar to the
behavioural interface, there are subtle differences between them.
First of all, the process orchestrations for participants B1 and B3 contain
additional internal activities. In B1, the buyer maintains a blacklist, consisting
of suppliers that have not been recommended for acceptance by an auctioning
service.
In B3, the received recommendation is stored in any case, represented by
the Store recommendation transition. Before the buyer decides whether to accept a supplier, the historical data is consulted, represented by the Look up
historical data transition.
Buyer B1 has the same set of communication places as the behavioural
interface of the Buyer role in Figure but different control flow. B2 and
B3 have different communication places than the behavioural interface. The
question now is whether any of these implementations is consistent with the
behavioural interface of the Buyer role.
The answer to this question depends on the consistency notion in place.
By common sense we can argue that all three local process orchestrations
are consistent with the behavioural interface of the buyer: B1 stores negative
recommendations in a blacklist, and it always follows the received recommendations
sent by the auctioning service. This realizes a behaviour that is
consistent with the interface, although not all possibilities of the buyer interface
are realized: B1 does not decide about accepting a seller on its own but
always follows the recommendation received.
Buyer B2 accepts every seller, so that the recommendations received are
discarded. We can argue that the behaviour of B2 is consistent with the buyer
interface, although not all behaviours are possible, i.e., B2 cannot reject a
seller.
B3 stores the recommendation received and makes an independent decision
about accepting a seller. We can argue that this behaviour is also consistent
with the buyer interface, because B3 can communicate as specified, at least
regarding recommendation and decision messages. However, B3 is not able to
receive a notification message. If we assume that this message is not essential
then also B3 is a valid implementation of the buyer interface.
This discussion shows that the decision on whether an implementation is
consistent with a behavioural interface is subject to consistency criteria. For
details on consistency in process choreographies, the reader is referred to the
bibliographical notes of this chapter.

Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec E -- By Mathias Weske

2009-11-19T22:13:00.000+05:30

Compatibility

Process choreography design needs to ensure that the process orchestrations of
the participants play together well in the overall collaboration. Compatibility
is the ability of a set of participants to interact successfully according to a
given process choreography.
Unsuccessful interaction behaviour could arise, if, for instance, different
message formats were used in a collaboration and one participant does not
understand the content of a message sent by another participant.
Another source of incompatibility—which this section will focus on—is due
to wrong and misaligned interactions. If, for instance, a participant expects
a notification at some point in its process before it can proceed, and none
of the other participants sends such a notification message, then the process
cannot continue, so a deadlock situation emerges. Compatibility of interacting
processes aims at avoiding this type of undesired behaviour due to erroneous
interactions between process orchestrations.
The bidding example illustrates the different aspects of compatibility introduced
in this section. Figure shows an auctioning scenario with three
participants involved. A potential bidder must be accepted for participation
before she can place her bid. Therefore, the bidder first needs to send a Participation
request to the auctioning service.
As a response, the auctioning service can send an Acceptance notification
or a Rejection notification. In some cases, the seller is requested to make the
final decision on whether a bidder can be accepted. In order to perform this interaction, the auctioning service forwards the request of the bidder to the
seller. It might also give a recommendation for accepting the bidder. The seller
can send a notification about his decision back to the auctioning service.
The auctioning scenario depicted in Figure 5.10 represents the participants
by pools that interact by sending and receiving messages. However, the figure
does not show any behavioural dependencies between the different message
exchanges. Nevertheless, compatibility can be investigated based on this highlevel
representation of the scenario.
Different types of structural compatibility are introduced to describe structural
properties of process choreographies. A process choreography is structurally
compatible if messages that can be sent by a participant correspond to
messages that other participants can receive. This property makes sure that
all messages that are sent can actually be received by participants. However,
it does not rule out that participants can receive additional messages that
none of the partners can send.
Strong structural compatibility of a process choreography is given if, for
every message that can be sent there is a participant who can receive it, and
if for every message that can be received, there is a participant who can send
it. Because each message flow connects exactly two participants
strong structural compatibility is satisfied in this example.
Weak structural compatibility is given if all messages sent by participants
can be received by other participants. However, it is not required that all
messages that participants can ever receive will actually be sent by other
participants.
Since the individual process orchestrations have in most cases been developed
independently of each other, a complete structural match between
participants cannot always be achieved. The occurrence of weak structural
compatibility is more likely. In this case, all messages sent can be received,
but it is not required that for every message that can be received there be a
participant who can actually send such a message.
The rationale behind this definition is that the interaction can take place,
even though some participants are able to receive additional messages. It is
assumed that these messages are not essential for the overall process choreography.
This will be discussed in more detail below.
In an alternative setting, a new auctioning service, for example, always
forwards the request by the bidder to the seller without providing recommendations.
In this case the seller will never receive any recommendation.
However, if these recommendations are not essential for the seller process orchestration,
as the example indicates, the cooperation can still be successful.
This example is shown in Figure 5.11, disregarding the bidder, who remains
unchanged.
Unlike structural compatibility, behavioural compatibility considers behavioural
dependencies, i.e., control flow between interaction instances of a
conversation. Therefore, the process orchestrations of the interacting partners
are interconnected, and the resulting process structure is analyzed. Such
analysis requires a formal, unambiguous representation.
In an approach for checking behavioural compatibility by Martens (2003c),
process orchestrations are represented by a specific class of Petri nets, namely
workflow modules. Workflow modules are basically workflow nets with additional
communication places that are used to represent message flow between
participants.
Whenever a participant sends a message, the process orchestration of that
partner features a transition with an output communication place that can
hold messages sent. At the receiver side, the workflow module requires a
matching input communication place. This place is an input place of the
transition that receives the message.
Each process orchestration is represented by a workflow module that defines
its internal behaviour and its external communication behaviour. Workflow
modules are defined as follows:

Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec D -- By Mathias Weske

2009-11-19T22:12:00.001+05:30

Collaboration Scenarios

Having identified the collaboration milestones, collaboration scenarios can be
addressed, as part of the choreography definition phase. In this phase, the
interactions needed to proceed from one milestone to another are specified.
One or several collaboration scenarios show the interactions and their dependencies
that need to occur between two milestones. To this end, interactions
between process participants serve as the building blocks for the resulting
collaboration scenarios.
Scenarios should be kept small, as it is easier to reach agreement on less
complex interaction behaviour. Additional scenario models might be introduced
to deal with special cases and exceptions.
An Auction creation
request initiates the conversation and, if not registered with the auctioning
service yet, the seller needs to be registered. Once the Auction creation confirmation
message is received by the seller, the Auction is set up milestone is
reached.
Notice that the Auction is set up milestone is the final milestone in this collaboration
scenario. Therefore, it is drawn in bold in Figure 5.8. However, this
milestone is an intermediate milestone in the high-level behavioural model, so
that it is drawn with a double border in Figure 5.6.
This example uses control flow patterns to express the relationships between
the interaction models. To this end, the interaction models between
participants can be represented as a specific kind of process, in which the
building blocks are interaction models, rather than business process activities,
as in process orchestrations.
Although scenario models define control flow between interactions, the
concrete message structures have not been addressed yet. Data interoperability
is an important aspect in process choreography projects. Therefore, data
models including possible data transformation rules need to be added. Once
these aspects are defined in sufficient detail, all artefacts are aggregated in
the final process choreography.
While the collaboration scenario depicted in Figure shows the milestones
and the resulting interactions, as well as their dependencies, the interfaces
of the individual participants need to be specified; these specifications
are called behavioural interfaces. A behavioural interface covers the individual
view of one specific participant in the process choreography; the internal
aspects of the own process orchestration, as well as the interactions involving
only other participants, are disregarded.
Behavioural interfaces consider parts of process orchestrations that exhibit externally visible behaviour, for instance, communication activities
and events that represent the sending or receiving of a message.

Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec C -- By Mathias Weske

2009-11-19T22:10:00.002+05:30

Process Choreography Design

The design of process choreographies involves a series of activities. In each
of these activities, artefacts are developed. These activities are described as
follows:
1. High-level Structure Design: In high-level choreography design, the participant
roles as well as their communication structures are identified. High level structure design is conducted during the Participant identification
phase.
2. High-level Behavioural Design: High-level behavioural models specify the
milestones of the collaboration and the order in which the milestones
are reached. High-level behavioural design is done during the milestone
definition phase.
3. Collaboration Scenarios: High-level choreographies are refined by introducing
dedicated collaboration scenarios that relate the reaching of milestones
to the communication between process participants. Collaboration
scenarios are developed during the choreography definition phase, based
on the scenarios informally specified during scenario modelling.
4. Behavioural Interfaces: From these collaboration scenarios, for each participant
role, a behavioural interface is derived.

High-Level Design

High-level process choreography design involves structure design and behaviour
design. In high-level structure design, participant roles of the choreography
are defined, as part of the participant identification phase. Figure 5.5
shows a high-level structure diagram for participants involved in a bidding
scenario. This diagram identifies a seller, an auctioning service, and multiple
bidders as participants. It also shows that these participants are pairwise interconnected.
Therefore, any participant can interact directly with any other.
High-level behaviour design uses milestones that are achieved during the
collaboration; it is therefore part of the milestone definition phase. Each milestone
represents a state in the overall collaboration that has a business meaning,
represented by some business value. Milestones correspond to subgoals
reached during the collaboration on the way to reaching its ultimate goal.
For instance, the ultimate goal in the bidding scenario is that the offered
goods are sold, paid for, and delivered to the bidder with the highest bid. Several
intermediate steps can be distinguished: the initial setup of the auction,
the entry of potential bidders into the auction, the actual bidding process,
and the delivery and payment.
Each milestone can be identified by an expression that describes the state
reached in that milestone. The milestones of (a part of) the bidding scenario
are depicted in Figure 5.6, where expressions like Auction is set up and
Bidding phase is over are used. These expressions indicate states during the
collaboration that have a business meaning.
In that figure, milestones are defined by circles, where the initial milestone
has a single border, the intermediate milestones have double borders, and the
ultimate goal milestone has a bold border. This notation follows the BPMN,
where start events, intermediate events, and end events are drawn in the same
manner. Mapping milestones to events is valid, because reaching a milestone
effectively realizes an event. For instance, the completion of the bidding phase
can be represented by an event Bidding phase is over.
Milestones have dependencies with respect to other milestones. For instance,
the auction has to be set up before the bidding process can be finished.
During the bidding scenario, first the auction is set up, defining the
first milestone, Auction is set up. The next milestone, Bidding phase is over, is
reached when the bidding phase completes. Then there is an and split gateway,
so that the next milestones Goods are delivered and Payment is completed,
can be reached concurrently. If both milestones are reached, the auction can
complete, reaching the final milestone, Auction has finished successfully.
It might also happen that a milestone is not reached in a certain conversation.
This situation occurs in the bidding scenario, for instance, if no single
bid is placed during the auction. In this case, delivery and payment cannot
occur, and the conversation ends without the final goal being reached. This
negative outcome can be modelled by introducing new milestones, reflecting
the positive and negative outcome of the bidding phase, respectively.

Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec B -- By Mathias Weske

2009-10-22T21:55:00.001+05:30

Development Phases

This section introduces the development of process choreographies, guided by
phases. The main goal of this section is to provide an understanding of the
concepts and artefacts involved in the design of process choreographies, rather
than on providing a reference methodology for choreography design These phases are organized into design phases and
implementation phases, shown in the upper and lower part of that figure,
respectively. There are three associated roles that represent the stakeholders
involved in choreography design and implementation. Based on the discussion
of these roles in Section 1.2, their specific responsibilities in the context of
process choreographies are highlighted.
Business engineers are mainly involved in the choreography design phases,
including scenario modelling, domain scoping, milestone definition, and participant
identification. Business engineers are responsible for business-related
aspects of the process choreography; they need to make sure that the collaboration
contributes to the goals of the enterprise, similarly to organizational
business processes.
System architects are responsible for the architectural aspects of the implemented
process choreography. This means that they are
involved in the design of process choreographies as well as in their implementation.
In particular, they are involved in the specification of the behavioural
interfaces, discussed later in this chapter.
Once the process choreography design is completed, developers are responsible
for realizing the process orchestrations in a way that the overall
business-to-business collaboration as specified in the process choreography is
realized. Behavioural interfaces are important artefacts for designing the individual
process orchestrations.
Based on this discussion of the stakeholders in process choreography design
and implementation, the phases are sketched.
Scenario modelling is at the heart of choreography design: scenarios describe
the overall setting and goals of the process choreography. They are also
useful for integrating the results of the other design phases. To model a particular
scenario, a domain in which the cooperation will take place needs to
be specified. This is performed during the domain scoping phase by business
engineers.
Formal notations are not required in scenario modelling and domain scoping,
so that the scenario and the domain can be described in a language that
allows expressing the relevant concepts. Depending on the specific setting of
the project, plain English text enriched with informally specified graphical
diagrams can be used.
The participant identification phase is devoted to defining different roles
of choreography participants. There are two options for doing this. These
roles are specified in a way that allows for the selecting of concrete process
participants on the basis of their properties as laid out in the participant roles.
In the context of process choreographies, the term process participant
refers to an organization, rather than to an individual. For instance, the role shipper can be played by multiple shipping companies, all of which are appropriate
for participation in the process choreography.
In the milestone definition phase, the participants define certain states of
the choreography in which the cooperation has achieved certain results, typically
characterized by intermediate products. These states are called milestones.
Milestones and their ordering describe behavioural aspects of the
choreography from a high level of abstraction.
In the message identification phase, the interactions in the scenario are
used to identify and design messages that realize the various interactions. This
phase has business aspects as well as technical aspects; it is therefore located
on the border of the design and implementation of process choreographies.
The design aspects include the business content of the messages, while the
implementation aspects include the technical realization of these messages
and concrete message formats.
Finally, the choreography definition phase combines the message identification
and the milestone definition phases of the modelled scenario. The
result of this phase is a detailed specification of the interactions between the
participants, the messages to realize the interactions, and the milestones that
are reached during the resulting conversation in the instance layer.
The choreography definition phase, just like the message identification
phase, includes business aspects as well as technical aspects. Unsuccessful
interaction behaviour would arise if, for instance, message formats were used
that one or more participants would not understand. To avoid this problem,
it is assumed that message formats as well as the semantics of the messages
are agreed upon by the participants.
Domain standards, like the ones mentioned above, are in place to provide
a common terminology, and, thereby, an understanding of the concepts
used. These standards are enhanced with technical information, so that data
structures and message formats are available. Business engineers, system architects,
and developers participate in choreography definition and message
identification.
In the lower part of Figure 5.4, the phases during implementation of
process choreographies are shown. Based on the choreography definition, behavioural
interfaces of all roles in the process choreography are defined. Behavioural
interfaces serve as blueprints for the design of the individual process
orchestrations realized by the participants of the process choreography.

Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec A -- By Mathias Weske

2009-10-22T21:53:00.001+05:30

Motivation and Terminology

In today’s business scenarios, companies increasingly join forces to combine
their services and products to provide added-value products to the market.
These products are typically realized by business processes, which in many
cases take advantage of the existing software infrastructures of the participating
companies.
Because business-to-business collaborations are quite complex, and any
failure in the collaboration might have an immediate effect on the operational
business of the company, the cooperation between companies should be designed
very carefully. Process choreographies can be used for this endeavour.
The requirements of process choreography development depend on the
number of interacting partners and the desired level of automation. In business
environments, where the cooperation of business partners is realized through
traditional means like fax messages being sent and read and understood by
humans, where humans can pick up the phone and settle any ambiguities,
detailed and formal process choreographies are not essential.
However, if the cooperation is to be realized—at least in part—by information
systems, so that a high level of automation is achieved, there need
to be unambiguous models that specify in detail the nature of the collaboration
of business partners in the context of a process choreography. These
considerations are illustrated by an example.
Consider a bidding scenario in which the owner of a car uses an auctioning
service to sell his car to the highest bidder. Potentially, thousands of people
can participate in the auction and place their bids. Such scenarios require
agreement on how the participants need to interact with each other in order
to avoid problems that could appear as the result of wrong interaction.
To illustrate the problems that could arise from erroneous interaction,
consider a collaboration involving process orchestrations run by two companies.
The first activity to be performed by Company 1 is receive activity A1.
This activity waits to receive a message sent by activity B2. Assuming that
communication is synchronous, i.e., the receive activity A1 is blocking, the
process orchestration run by Company 1 cannot proceed.
Analogously, Company 2 waits in activity A2 to receive a message from
activity C1 to be sent by Company 1. As a result, both process orchestrations
cannot proceed: they are stuck in a permanent deadlock situation. To avoid
these kinds of problems, the partners involved in a process choreography need
to agree on the process choreography.
The behaviours are valid because each
process instance will perform a set of activity instances before it completes.
Deadlock situations, infinite loops, and other types of undesired behaviour
cannot appear.
The problem encountered is due to links between send and receive activities
in the process orchestrations. As the example illustrates, the viewpoint of
an individual process orchestration does not suffice for reasoning about the
interaction between process orchestrations; a global view on the interactions
between process orchestrations is required.
At the metamodel level, the Process Choreography Metamodel is
shown which provides the concepts to express Process Choreographies at the
model level.
Concrete instances of process choreographies are called Process Conversations,
which appear at the instance level. A Process Choreography Language
provides constructs to express process choreographies based on a process
choreography metamodel.
Each interaction model is associated with two objects of the class Communication
Activity Model. Communication activity models are activity models
in process orchestrations that exhibit a communication behaviour by sending or receiving messages. For the time being we focus on simple interactions
involving two activities.
As with process orchestrations, we can distinguish between models and
instances. The term Process Conversation refers to the concrete messages that are exchanged
as specified in a given process choreography. Therefore, process choreographies
serve as conversation models. Each process conversation consists of
a set of Interaction Instances, each of which is the concrete realization of a
message exchange as specified by the associated interaction model. Each interaction
instance is associated with Communication Activity Instances, which
are the concrete activity instances that send and receive messages.

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

2009-10-15T17:29:00.002+05:30

Business Process Diagrams

The notational elements in business process diagrams are divided into four
basic categories, each of which consists of a set of elements.
Flow objects are the building blocks of business processes; they include
events, activities, and gateways. The occurrence of states in the real world that are relevant for business processes are represented by events. Activities
represent work performed during business processes. Gateways are used to
represent the split and join behaviour of the flow of control between activities,
events, and gateways.
Organizational aspects are represented in business process diagrams by
swimlanes. Swimlanes are restricted to a two-level hierarchy: pools and lanes.
Pools represent organizations that participate in the interaction of multiple
business processes, each of which is enacted by one organization. Lanes represent
organizational entities such as departments within a participating organization.
By drawing flow objects in swimlanes, the organizational entity
responsible for performing the specific objects can be represented graphically.
Artefacts are used to show additional information about a business process
that is “not directly relevant for sequence flow or message flow of the process”,
as the standard mentions. Data objects, groups, and annotations are supported
as artefacts. Each artefact can be associated with flow elements. Artefacts
serve only information purposes. The process flow is not influenced by
artefacts.
Data objects are represented simply by a name. The main purpose of data
object artefacts is documentation of the process. Using directed association
arcs, the modeller can represent the fact that a data object is used (or created/
modified) by an activity in the process. Paper documents and electronic
documents, as well as information on any type of medium; can be represented
by data objects.
Text annotations are used to document certain aspects of the business
process in textual form. The text is graphically associated with the object
in the business process diagram that the text explains. Group objects are
artefacts that are used to group elements of a process. Groups do not have a
formal meaning; they just serve documentation purposes. Groups may span
lanes and even pools.
Connecting objects connect flow objects, swimlanes, or artefacts. Sequence
flow is used to specify the ordering of flow objects, while message flow describes
the flow of messages between business partners represented by pools. Association
is a specific type of connecting object that is used to link artefacts to
elements in business process diagrams. The categories of notational elements
are shown Figure 4.78.
The core element set provides a small set of concepts and their graphical
representation for modelling business processes. The idea is to provide an
easy-to-use notation by concentrating on the main aspects of business process
modelling, without introducing complexity that might not be relevant.
The business process diagram shown represents a review
process for a scientific conference. The program committee chairperson is the
central role in the process; this role is represented by the PC Chair pool. There
are two additional roles involved, namely authors who submit their research
papers and reviewers who perform peer reviews for the submitted papers. Since the goal of this example is to introduce the core elements, simplifications
are in place: the business process model provides a simplified view of how
review processes are actually conducted. In addition, there are many authors
and there are also many reviewers. For convenience, just one author and one
reviewer are shown. As will be discussed below, situations in which multiple
participants are involved in the same role cannot be covered conveniently.
The pools in this example represent roles and not concrete participants in a
business process. Each role at run time has multiple concrete participants who
are actually involved in the business process instance. The BPMN standard
indicates that “a pool represents a participant in a process. It is also acts as a
“swimlane” and a graphical container for partitioning a set of activities from
other pools, usually in the context of B2B situations.”
The process starts when the PC Chair is asked to organize the scientific
program of a conference. This is reflected by the start event of the process at
the PC Chair. An event is something that ‘happens’ during the course of a
business process. These events affect the flow of the process and usually have
a cause (trigger) or an impact (result). Events are circles with open centres
to allow internal markers to differentiate different triggers or results.”
The activity enacted first is the publication of a call for papers with detailed
information on the conference, such as name and location, and also
information regarding the topics addressed by the conference. The receipt of
a message can be an event that is relevant for the process. This concept is
used in the sample process when the published call for papers activity sends
a message that the author receives. Receiving this message is represented by
the start event of the author process. The cause of this event is receiving the message and the effect is spawning the process. The same concept is used to
start the reviewer process in a later phase of the overall process.
Activities represent units of work that are actually conducted during the
course of the business process. The sample process contains, in the PC Chair
process, a set of activities that are enacted in sequence. The standard states
that “an activity is a generic term for work that a company performs. An
activity can be atomic or non-atomic (compound). The types of activities
that are a part of a process model are: process, subprocess, and task. Tasks
and subprocesses are rounded rectangles. Processes are either unbounded or
contained within a Pool.”
Business processes contain execution constraints between activities. The
simplest form of execution constraint is execution order. “A Sequence Flow is
used to show the order that activities will be performed in a process.”
More complex execution constraints are splits and joins of branches, where
different types of splits and joins are available. These structures are represented
by gateways. A gateway is graphically represented by a diamond. Split
nodes have multiple outgoing edges and join nodes have multiple incoming
edges. The notation for a gateway is identical to that for split and join nodes.
The split and join behaviour is represented only by the edges attached to
a gateway symbol. “A Gateway is used to control the divergence and convergence
of Sequence Flow. Thus, it will determine branching, forking, merging,
and joining of paths. Internal markers will indicate the type of behaviour
control.”
In the sample business process, the author pool contains a split gateway
and a join gateway. The split gateway evaluates the received notification information
and—in case the paper is accepted—triggers the preparation of the final version of the paper that will be printed in the conference proceedings.
In case the paper is rejected, the join gateway is triggered. To clarify the behaviour
of the split gateway, the outgoing sequence flows are associated with
the respective annotations.
The participants that cooperate in the context of a business process communicate
by sending and receiving messages. In business process diagrams,
messages are represented by message flow. Typically a message flow connects
an activity of one participant to an activity or an event of another participant.
Depending on the kind of business process diagram (abstract or global),
message flows can link pairs of flow objects, pools, and events. Detailed rules
on message flow connections are discussed below. “A Message Flow is used to
show the flow of messages between two participants that are prepared to send
and receive them. In BPMN, two separate Pools in the Diagram will represent
the two participants (e.g., business entities or business roles).”
The notational elements of the BPMN regarding transactional behaviour of
business processes (transaction groups, compensation flow, and cancellation)
will not be covered, because their semantics is not laid out in sufficient detail
and precision.

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

2009-10-15T17:27:00.002+05:30

Process Instances

Dead path elimination is used to describe the execution semantics of process instances that are represented in graph-based languages.In this example, the Accept Credit activity can only be enabled after request approval has signalled its outgoing edge. If Request Approval is executed, then the signalling is true; otherwise, the edge is signalled false. Therefore,
after the Assess Risk activity has provided a high risk factor as output value,
Accept Credit cannot be started, at least not immediately after Assess Risk
terminates.
Since the risk is assessed to be high, the start condition of the Request
Approval activity is evaluated to true. This activity is started and approves
the credit request; this approval is represented by changing the value of the
risk factor from high to low. When the edge to the Accept Credit activity is
signalled, the start condition of that activity is evaluated to true, and the
credit is granted In this process instance,
Assess Risk determines a low risk factor, so Request Approval is not required.
In this case, the edge from Assess Risk to Request Approval is signalled false,
indicating that request approval is not required.
On receiving this signal, Request Approval immediately relays a false signal
to its outgoing edge, in this case, to the Accept Credit activity. Now all incoming
edges of the Accept Credit activity have been signalled, so that the start
condition can be evaluated. Since the risk factor is low, the start condition is
evaluated to true, so that the credit can be granted.

Discussion
Graph-based workflow languages are useful for implementing business processes,
in which process activities are realized by software systems. Just as procedures realized by software systems read input parameters on their start
and write output parameters on their termination, so do process activities in
graph-based workflow languages.
Data flow can be expressed well by relating output parameters of process
activities to input parameters of follow-up activities. Since control flow is
defined by edges between activities and start conditions of activities, basic
control flow patterns, such as sequence, splits, and joins can be expressed.
Graph-based workflow languages do not support arbitrary cycles, because
in cyclic process models, dead path elimination causes problems. Advanced
control flow patterns, such as multiple instances patterns or discriminator
pattern, are also not supported by graph-based workflow languages.

Business Process Modeling Notation

In this section, the Business Process Modeling Notation (BPMN), developed
under the coordination of the Object Management Group, is introduced. The
focus of this section is not a complete presentation of the standard, but a
discussion of the main concepts of business process diagrams expressed in the
Business Process Modeling Notation.
The intent of the Business Process Modeling Notation in business process
modelling is very similar to the intent of the Unified Modeling Language for
object-oriented design and analysis. To identify the best practices of existing
approaches and to combine them into a new, generally accepted language. The set of ancestors of BPMN include not only graph-based and Petri-netbased
process modelling languages, but also UML activity diagrams and eventdriven
process chains.
While these modelling languages focus on different levels of abstraction,
ranging from a business level to a more technical level, the Business Process
Modeling Notation aims at supporting the complete range of abstraction levels,
including business levels and software technology levels. This goal is also
laid out in the standards document, which states, “The primary goal of BPMN
is to provide a notation that is readily understandable by all business users,
from the business analysts that create the initial drafts of the processes, to
the technical developers responsible for implementing the technology that will
perform those processes, and finally, to the business people who will manage
and monitor those processes.”

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

2009-10-04T18:54:00.001+05:30

Graph-Based Workflow Languag

In this section, a graph-based workflow language is introduced. This language
was developed in the context of a commercial workflow management system.
It exhibits a series of interesting concepts that are not addressed by the other
process languages discussed in this chapter. Explicit representation of data
dependencies between activities and dead path elimination as a technique to
describe the execution semantics of business processes.

Process Metamodel

To illustrate this modelling language, an example of a credit request process
is shown in Figure 4.72. The activities are shown as nodes of the graph,
control flow is represented by solid arcs, and dotted arrows indicate data flow.
Data flow, for instance, between activities Collect CreditInfo and Assess Risk
indicates that Assess Risk requires data that has been created or modified by
Collect CreditInfo.
The process starts with collecting credit information, followed by an assessment
of the credit risk. Then, either the credit is accepted or a request approval activity is started. The request approval activity determines the final
decision on the credit request; it either approves the credit or rejects it. In
any case, the requestor is informed by a notification message.
Data is covered by parameters of activities; each parameter has an associated
data type. Each activity has a set of input parameters and a set of
output parameters (might be empty). Whenever the output parameter of one
activity is used as an input parameter of another activity, a data flow occurs.
Transitive data flow is often not shown in process models.
Each control flow edge has an associated condition. This condition is evaluated
after the activity from which the control flow originates has terminated.
If the condition is evaluated to true, the edge is signalled, and the follow-up
activity can be started.
The execution semantics of process graphs is based on the signalling of
edges. There are two ways of signalling: true signalling and false signalling.
When an activity terminates, the conditions of its outgoing edges are evaluated.
For each edge that evaluates to true, the follow-up activity is signalled
true. For each edge that evaluates to false, the edge is signalled false.
When all incoming edges of an activity are signalled—i.e., each edge is
signalled true or false—the start condition of that activity is evaluated. The
start condition realizes the join behaviour of that node. If the start condition
of an activity evaluates to true, it is enabled. If it evaluates to false, the activity
is not enabled. In this case, all outgoing edges of this activity are signalled
false.
By using true and false signalling, the or join problem is solved, because
each incoming edge will be signalled eventually. This technique is called dead path elimination, because paths not taken in the execution of a process are
marked with the false signal; they are therefore somehow eliminated. Unfortunately,
dead path elimination only works in the absence of loops in process
models, but the iteration of activities guided by an exit condition is supported.
Each activity is associated with a start condition. This start condition is
evaluated if all incoming control flow edges have been signalled (either true or
false). The start condition uses this information as well as input parameters
received from previous activities to decide on the state transition. If the start
condition is evaluated to true. then the activity is enabled. If it is evaluated to
false, the activity is skipped and false signals are sent to each of its outgoing
edges, regardless of the conditions attached to these edges.
To illustrate these concepts, Figure 4.73 shows a refined version of the
process model shown above, which includes parameters, start conditions, and
data flow between process activities.
The Collect CreditInfo activity is responsible for providing information
about the credit, including customer information and the amount requested.
This information is stored in the output parameter CreditInfo of the Collect
CreditInfo activity. The Assess Risk activity takes the credit information as
input parameter and assesses the risk of granting the credit. The result of this
activity is stored in an output parameter RiskFactor that is made available
to the follow-up activities Accept Credit and Request Approval.
The use of start conditions can be illustrated in this example: the Request
Approval activity can be started if the credit amount is at least 10000 euros
and the risk factor is high. This start condition takes as input the risk factor
and the credit amount, values for both of which are provided to the Request
Approval activity by the output parameters of the Assess Risk activity.
The start condition of the AcceptCredit activity makes sure that it can
only be started if the credit amount is below 10000 euros or the risk factor
is low. The credit can also be accepted if the credit was approved by the
Request Approval activity. This information is made available to the Accept
Credit activity by the output parameter RiskFactor of Request Approval.
Depending on the particular implementation used to enact this process,
either data can be transferred between activities by the business process management
system, or references to data objects can be subject to data flow, so
that the system is not burdened with large amounts of data if complex data
needs to be transferred between process activities.
To organize these concepts, a workflow metamodel is shown in Figure 4.74.
The workflow class is the central class in the metamodel; it contains workflow
objects that can be either atomic or complex, and atomic workflows can
be executed either automatically or manually. This property of workflows is reflected
in the metamodel by complex and atomic as subclasses of the workflow
class. The workflow hierarchy is represented by the nesting class, an association
class that defines the relationship between a complex workflow and a
workflow, which can be complex or atomic. Atomic workflows are also called
activities.

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

2009-10-04T18:53:00.000+05:30

N-out-of-M Join

The N-out-of-M join has M incoming branches, and the follow-up activity
is triggered once N branches have completed. This behaviour can in part be
expressed in YAWL by multiple instances, as shown in Figure 4.67. The idea
is to start M instances and to define a threshold of N instances, so once N
instances have completed, the multiple instances task completes.
While multiple instances can be used to represent an N-out-of-M join
with identical activities, this approach falls short of representing concurrent
branches comprised of different activities. Therefore, only a very specific type
of N-out-of-M join can be realized in YAWL using multiple instances. Hence,
the N-out-of-M join is not completely expressed, since it should be able to
synchronize different branches of a process and not only multiple instances of
a given task.

Multiple Instances Tasks

Yet Another Workflow Language is tailored towards supporting multiple instances
patterns. The multiple instances without synchronization pattern is
shown in Figure 4.68. In this example, A spawns two concurrent branches,
consisting of multiple instances of task B and a single instance of task C.
The multiple instances of task B are not synchronized, which means that
B cannot have outgoing edges, because outgoing edges would indicate that
the follow-up activity can only be started if the task instances of task B have
completed.
The multiple instances with design time knowledge is shown in Figure 4.69.
In this pattern, the number of instances of task B is known at design time.
Therefore, the multiple instances attributes of task B can be set accordingly.
By setting the minimum number of instances, the maximum number of
instances, and the threshold to n, where n is the number of required instances
of task B, this pattern can be realized. The control flow edge from B to C
indicates that C can only start when all instances of task B have completed.
If the number of instances is known only at run time, but before the first instance
of B starts, a function is required to determine the number of instances
of B, as shown in Figure 4.70. This difference with the previous pattern is reflected
by using q for the number of instances, where q is determined at run time of the process instance, but before the start of multiple instances task
B. For example, the number of line items in an order can be determined at
run time. In the example, q reflects this number, so that exactly q instances
of task B are performed.
Figure 4.71 shows multiple instances without a priori run time knowledge.
In this pattern, the number of instances of B becomes available only while
instances of task B run. This means that new instances of B need to be
created dynamically. Parameters q1 and q2, and also the threshold value, can
be subject to change while task instances run, providing maximum flexibility
in determining the number of instances of a multiple instances task.

Discussion
Yet Another Workflow Language has a number of advantages, but also some
drawbacks. The graphical representation of process models is closely related to workflow nets, so that people familiar with workflow nets can use YAWL
immediately.
The execution semantics of YAWL is well-specified by state transition
systems. The representation of executing tasks by state transition systems
combines state transition diagrams—to describe the dynamic behaviour of
process activities, as shown in Figure 3.10—with Petri net markings.
One of the conceptual issues when representing business process activities
by Petri nets is the timeliness of the transition firing. Business process activities
take time, they have a start, they are active for a time interval, before
they complete. In contrast to Petri nets, the durations of process activities
are well captured by state transition systems in YAWL. At the same time,
process instances are represented by tokens, similar to markings in Petri nets.
YAWL has excellent support for multiple instances patterns. The specification
of multiple instances actually goes one step ahead of the control flow
patterns in that it allows us to define a threshold of completed task instances.
The construct to model multiple instances tasks in YAWL is very useful and
has many applications in real-world business processes.
The semantics of multiple instances tasks is handled very well by state
transition systems in YAWL. The add transition allows the dynamic creation
of new task instances while task instances are active; the exit transition can
realize the threshold semantics by cancelling all remaining task instances when
the threshold number of completed instances has been reached.
The state transition systems also capture in a very elegant way composite
tasks. By recursively applying the concept, subprocesses can easily be attached
to composite tasks. The multiple-instances property is orthogonal to
tasks being composite, so that any composite task can at the same time have
multiple instances.
The remove function rem associated to tasks allows us defining regions
of the workflow specification from where to withdraw tokens when the task
completes. Conceptually it is rather simple to “remove tokens” from process
instances to cancel tasks. It becomes much harder, however, when we look at
the concrete realization of these tasks.
In real-world business processes, many tasks are realized by software systems.
Removing a token from a task means to cancel the invocation of the
system. If the software system has transactional capabilities then the transaction
can be aborted, rolling back the software system to a consistent state.
Not all software systems used in business processes are, however, are transactional. In this case, the software might have already performed its work
partially at the time, the token is removed. In such situations, it is unclear,
how the business process management system should behave. In many cases,
human involvement is required to solve the resulting problems manually.
We have already discussed in some detail the weaknesses of YAWL in
representing some advanced control flow patterns, including the discriminator
and the M-out-of-N join. Despite these drawbacks, YAWL is a well-designed
process modelling language that also comes with prototypical implementations
for modelling and enactment, as referenced in the bibliographical notes.

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

2009-10-04T18:50:00.001+05:30

Nested Processes

The approach of defining the execution semantics of process instances by
state transition diagrams can be extended conveniently to nested processes.
Figure 4.64 shows the extended state transition diagrams for composite tasks.
When an instance of a composite task is started, one token is put on the
exec state, indicating that the task instance is now running. The detailed
status of the subprocess is shown in the lower part of Figure 4.64. Starting
the task also puts a token in the initial condition of the subprocess, marked
by imap.
The ellipsis summarizes the state transition diagram of the subprocess
(without the initial and the final condition, of course). When the subprocess
terminates, the condition omap is reached, and the complete transition can
fire, completing an instance of the subprocess.
The extension of the state transition diagram to composite tasks is orthogonal
to multiple instances tasks, so that by adding an add transition,
multiple instances of composite tasks, and therefore also multiple instances of
subprocesses, can be represented properly.
The example discussed above is used to investigate the execution of composite
task F realized by the extended workflow net W2, shown in Figure 4.62.
A partial state transition diagram focusing on the state of the composite task
is shown in Figure 4.65.
When an instance of the composite task F is executed, a token is put on
the exec state of the state transition diagram of that task. In addition, the
subprocess needs to be started, represented by a token in the start condition
of the extended workflow net that F maps to; since map(F) = W2, a token is
put on i2, the start condition of W2.
The token at i2 enables the subprocess. The first task to execute is H.
The lower part of Figure 4.65 shows the state during the execution of the
subprocess where task H is currently executing. When H terminates, a token
is put on state cHI , so that the execution of the subprocess can continue with the multiple instances task I. This example shows quite well the recursive
application of state transition diagrams for composite tasks.

Advanced Control Flow Patterns

Having discussed how the execution semantics is specified, we can investigate
advanced control flow patterns.

Discriminator
The discriminator is a specific type of join node that uses the first signal it
receives for triggering the outgoing task. The other signals are ignored. When
signals have been received from all incoming branches, the discriminator resets
itself. The authors of Yet AnotherWorkflow Language propose to simulate this
behaviour of the discriminator pattern by an exclusive or join in combination
with a cancellation region in the way shown in Figure 4.66.
In this example, assume that tasks B, C, and D are active concurrently,
following the and split task A. Assuming that B completes first, the discriminator
fires, and E is triggered. Since E is an exclusive or join task, it can
be executed. Since a cancellation region is defined for E, E deletes all tokens
from the region. In this case, tokens are withdrawn from tasks C and D.
This simulation of the discriminator pattern with exclusive or join and
cancellation region is now evaluated with respect to the semantics of the
discriminator. The simulation exhibits significant semantic differences with
the specification of the discriminator. First of all, the discriminator does not
cancel running activities.
All activities on the incoming branches of the discriminator can complete
without disturbances; only their termination will be ignored. Secondly, the
cancellation of the activities takes place on the termination of the task instance
E. So the activities are cancelled not before E starts, but after E terminates.
As a result, the proposed representation of the discriminator pattern in YAWL
is not completely satisfying.

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

2009-10-04T18:48:00.001+05:30

Process Instances

The discussion of state transition diagrams is extended from a localized view
of individual tasks to a process view. In order to do this, a number of definitions
are required. The first definition extends the compact representation
of extended workflow nets in a way that it syntactically complies with the
workflow net definition: wherever there is an arc connecting two tasks in an
extended workflow net, a new condition is added and the arcs are modified
accordingly.

Definition
Let N = (C, i, o, T, F, split, join, rem, nofi) be an extended
workflow net.
• Cext
N is an extended condition set, such that
Cext
= C [ {cij |(ti, tj) 2 F \ T × T}

The extended condition set and the extended flow relation are shown in
Figure 4.62. Observe that for each direct connection between tasks in the
original extended workflow net, one condition and the respective arcs are
added: Cext
1 = {i1, cAB, cBC, cCD, cCE, cCF , cDG, cEG, cFG, o1}.
The extended flow relation Fext
1 is given by the arrows in Figure 4.62. Analogously,
the extended condition set and the extended flow relation for W2 are
given by Cext
2 = {i2, cHI , o2} and Fext = {(i2,H), (H, cHI ), (cHI , I), (I, o2)}.
Since there are multiple process instances for which tasks are being executed,
the identity of these cases needs to be taken into account when describing
the state of tasks and their task instances. Therefore, the following
assumptions concerning process identifiers are made.
Each process instance has a unique case identifier.
Each task instance has a unique task instance identifier.
Identifiers are structured to allow for child/parent relationships. This
means that each task instance identifier can be associated with its process
instance or case.
I denotes the set of identifiers.
Based on case identifiers and the state transition system discussed above, a
workflow state can be characterized as a bag of tokens, where each token has
condition and a case identifier.

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

2009-10-04T18:45:00.001+05:30

Simple Control Flow Patterns

We now discuss how YAWL supports control flow patterns. It is obvious that
the basic control flow patterns are directly supported. The sequence pattern
is shown in Figure 4.55, where two alternative representations are shown: in
extended workflow nets, the control flow edge can directly connect A and B, so
that the condition place can be dropped. Notice that these two representations
are equivalent, i.e., any extended workflow net with conditions connecting two
tasks can be transformed to an equivalent extended workflow net with direct
connections, and vice versa.
And split and and join patterns are shown in part (a) of Figure 4.56.
On completion of the split task A (split(A) = and), tasks B, C, and D are enabled, and the three tasks can be executed concurrently. The join task
E (join(E) = and) is enabled only if B, C, and D have been completed.
The exclusive or split shown in part (b) of that figure selects exactly one
alternative, so that E can start if exactly one branch is completed. In this
case, split(A)= join(E) = Xor.
Workflow specifications require additional information that allows evaluating
conditions to decide, for instance, which path in an exclusive or split
to take. These conditions, however, are not part of the formal specification of
workflow specifications in YAWL.
Figure 4.57 shows the inclusive or split. From a notation point of view,
the or split and the or join can be defined similarly to the other control flow
structures. However, the decision on when the or join is activated is complex.
These aspects will be discussed in more detail when the execution semantics
of YAWL is investigated.

Execution Semantics

The execution semantics in YAWL is defined by state transition systems.
Each workflow specification has a corresponding state transition system that describes the execution semantics of process instances based on that workflow
specification. The rules implemented in this state transition system are of
a generic nature, so that they can be applied to any workflow specification
expressed in YAWL.
The overall idea for expressing the execution semantics is that each task
is represented by an individual state transition diagram. A state transition
diagram of a task specifies its current state. The state of the process instance
is then represented by the combined state of all tasks involved in the process
instance plus conditions that are currently met at the process level.

Task Instances

State transition diagrams consist of conditions represented by circles and transitions
represented by rectangles. Since multiple instances tasks can take more
states than single instance tasks, single instance tasks are investigated first.
The state transition diagram for single instance tasks is shown in Figure 4.58.
In this section, task instances are investigated before state transition diagrams
at the process level are investigated. To stay in line with terminology
in YAWL, this section uses the term task instance, which describes the same
concept as the term activity instance this book has used so far.
The following conditions are available for a task instance:
enabled: Task instance is enabled, but not yet executing
exec: Task instance is currently executing
completed: Task instance is completed
active: Task instance is currently active
The execution semantics of a task instance is specified by the state transition
diagram shown in Figure 4.58. Despite the fact that transitions do not use Petri net transition semantics, it is appropriate to discuss the basic operation
of state transition diagrams with Petri net terminology.
When the task instance is entered, a token is put on the active and enabled
conditions. An enabled task instance can start. Once the start transition fires,
the task instance enters the exec condition.When the task instance completes,
it enters the completed condition; finally, the task instance is terminated by
firing the exit transition. Note that the active condition and the exit transition
are somewhat artificial for single instance tasks; their role will become clear
when multiple instances tasks are addressed.
To summarize, the state transitions for a task t have the following semantics.
The state transition enable checks the join condition of t; t might be
a join node of type And, Xor, or Or, as specified by join(t). When the enable
transition occurs, the input tokens as defined by the join condition are
removed from the input conditions of the task.
In case of a single instance task, one token is put in the active condition and
one token is put in the enabled condition. When the start transition occurs,
one token is removed from the enabled condition and one token is added to
the exec condition. The task instance is now executing. The termination of a
task instance is represented by the completed transition in the state transition
diagram. In this case, one token is removed from the exec condition and one
token is added to the completed condition.
The exit transition is specifically relevant for multiple instances tasks,
because it fires if the termination condition of a multiple instances task is met.
In case there is a cancellation region defined for task t, the exit transition also
removes tokens from the cancellation region of the workflow specification, as
defined by rem(t). Finally, the exit state transition generates tokens depending
on its split behaviour, defined by split(t) The state transition diagram for multiple instances tasks is shown in Figure
4.59. There is an additional state transition, add, that spawns new task
instances. Arcs drawn in bold indicate that multiple tokens can flow along
these arcs.
To discuss the execution semantics of a multiple instances task, the static
case is considered first. In this case, all task instances are created up front,
and no task instances can be added while instances of the task run. Consider
a multiple instances task with [4, 6, 4, s]: four to six task instances are created,
and the multiple instances task terminates when the threshold of four
instances that have completed is reached.
Consider a process instance in which the enable transition creates five
task instances by putting five tokens in the active condition and five tokens
in the enabled condition. For each token in the enabled condition, the start
transition can fire.
The termination of the overall task (completion of the required task instances)
is realized by the exit transition. Exit can fire if the threshold number
of tokens are in the completed condition, indicating the completion of a
sufficient number of task instances. Assuming four task instances have been
completed, the threshold value is reached, and the exit transition removes
four tokens from the completed condition and four tokens from the active
condition.
However, since five task instances have been started, there is one additional
task instance present. This task instance is represented by one token in the
active condition and one token in either the enabled or the exec condition.
This task instance might also have already entered the completed condition.
In the example shown in Figure 4.60, the task instance is still executing To implement a proper completion of the task, the exit transition needs
to delete all remaining tokens from the state transition system of the task. In
this case, two tokens that collectively represent the fifth (and not required)
task instance are removed, completing the task and all its task instances, of
which four have been performed completely.
In the example discussed, the number of task instances was statically defined,
so that the dynamic creation of new task instances was not possible. In
the following example, additional task instances can be created at run time.
Let [3, 10, 8, d] define the multiple instances property of the task. This means
that there are at least three instances, at most ten instances, and the threshold
is eight completed task instances.
Assume that three task instances are started up front. In this case, the
enable transition puts three tokens in the active condition and three tokens
in the enabled condition. The enabled task instances can start.
The dynamic creation of new task instances is represented by the state
transition add. As soon as there is one task instance in the active condition,
the add transition can fire. When it fires, an additional token is put in the
enabled and active conditions, representing the creation of a new task instance
at run time. In this way add realizes the dynamic creation of task instances at
run time. Using this feature, YAWL directly supports the multiple instances
without a priori run time knowledge control flow pattern, introduced in Section
4.1.
The other parts of the state transition system remain unchanged, so that
the originally created task instances and the dynamically created task instances
are handled equivalently: the exit transition can fire if there are a
sufficient number of completed task instances available, in this case, eight.
The actual trigger for creating new task instances is not in the scope of
the state transition system. It is assumed that the user or a software system
spawns new task instances as desired. The state transition system is capable
of monitoring the state of a task, including the states of its task instances.

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

2009-10-04T18:44:00.001+05:30

Temporal Aspects

Activities in workflow nets are represented by transitions. When a transition
fires, it withdraws tokens from its input places and puts tokens in its
output places, depending on the decision made by the transition. These steps
(withdrawing tokens, determining where to put tokens, and finally putting the
tokens) in Petri nets are represented by the firing of the transition, which does
not consume time. This assumption is in contradiction with activity instances,
which do take time. The processing of an insurance claim, the preparation of
a quote, and the checking of a warehouse inventory are activities that take
time.
The fact that activities take time is also reflected by the state transition diagram
of activities. In state transition diagrams, state transitions are triggered
by events. For instance, the completion of an enter customer order activity
enables a check inventory activity. This means that activity instances have
lifecycles that consist of a number of steps, from their instantiation, their enabling,
and their execution to their termination. In workflow nets, these steps
are not represented, because firing puts an activity from the enabled state
immediately into the terminated state.
This contradiction is partly solved in workflow management systems using
Petri nets. Assume that a business activity represented by a transition is
realized by invoking a piece of software. The invocation of the software is
often represented by the firing of the transition. However, software procedures
also take time. In addition, the follow-up activities should not be enabled
when the previous activity is started, but when it completes. If an activity is
implemented in software, then the follow-up activities should not be enabled
when the software is invoked, but after it has completed.
The timeliness of activity instances represented by workflow nets also implies
that no events can occur during an activity instance. In real-world business
processes, however, this is not true. Many things do happen during the
execution of a business process activity. For instance, while an inventory is being
checked, new items may enter the warehouse. These issues are not covered
by workflow nets; it is the responsibility of business process management tools
to solve issues that might result from these abstractions in workflow nets.

Yet Another Workflow Language

The motivation for the development of Yet Another Workflow Language
(YAWL) was the lack of a process language that directly supported all control
flow patterns. While it uses workflow nets as a major ingredient, the execution
semantics of process instances is specified by state transition systems and not
by Petri nets. In this section, YAWL and its support for control flow patterns,
as well as its execution semantics, are investigated.
While Petri nets provide a sound formalism for expressing most control
flow patterns, the following deficiencies have been identified that hamper the
expression of the full set of control flow patterns.
• Multiple Instances: Multiple instances patterns describe business processes
with multiple instances of specific activities. The number of activity instances
of one particular activity model might not be known at design time.
Petri nets do not provide adequate means to describe multiple instances
tasks.
• Advanced Synchronization Patterns: Petri nets can directly express and
split/join and exclusive or split/join using places, transitions and firing
rules of traditional Petri nets. Advanced synchronization patterns such as,
for instance, or split and or join and discriminator patterns, however,
cannot be conveniently expressed in Petri nets.
• Nonlocal Firing Behaviour: The enabling of activities in a business process
is based onlocal knowledge only. In the context of Petri nets, the presence
of tokens in the input places of a transition indicates activation of that
transition. In business processes, there are situations in which nonlocal
parts of the process are affected by a decision. For instance, the cancellation
pattern somehow vacuum-cleans defined parts of the Petri net when being
activated. If used to cancel a customer order, different activities in different
parts of the Petri net need to be cancelled in order to cancel the overall
customer order.

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

2009-09-16T19:16:00.001+05:30

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

2009-09-16T19:13:00.001+05:30

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

2009-09-08T14:29:00.002+05:30

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

2009-09-08T14:25:00.002+05:30

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

2009-09-07T19:19:00.002+05:30

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

2009-09-07T19:17:00.002+05:30

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

2009-09-06T22:05:00.000+05:30

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

2009-09-06T22:02:00.002+05:30

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

2009-09-02T21:35:00.001+05:30

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

2009-09-02T21:33:00.001+05:30

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.

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

2009-08-29T20:58:00.001+05:30

Deferred Choice

Deferred choice is a state-based pattern. State-based patterns capture the implicit
behaviour of processes that is based not on the current case but rather on
the environment or other parts of the process. Some of the following patterns
require the existence of an external process that represents the environment.
This process is used as a source for external events.
A deferred choice is a point in a process model where one of several
branches is chosen. In contrast to the exclusive or split, the choice is not
made explicitly—for example, based on data values or a user decision—but
several alternatives are offered to the environment.
The environment activates one of the alternatives, and the other branches
are then withdrawn. Because the choice is delayed until one of the alternative
branches has actually been started, the moment of choice is deferred to a point
in time that is as late as possible.
Regarding the states of activity instances, each of the alternative branches
is represented by one activity instance in the init state. The state transition
from init to enabled is triggered by the environment, for instance, by sending
a message. After the state transition has occurred, the activity instances that
were not chosen enter the skipped state.
In that example, after a terminates, activity instances b, c, and d are created. Assuming that b is selected by receiving a message, b enters the enabled state, while c and d are
no longer required. Therefore, these activity instances are skipped.

Sequential Execution without A Priori Design Time Knowledge

The sequential execution without a prior design time knowledge pattern is
described as follows: a set of activity instances is executed sequentially in an
order that is decided at run time. No two activity instances of this set are
active at the same point in time.
Originally this pattern was called interleaved parallel routing; however,
this was somewhat misleading: The activity instances do not interleave, and
they are not executed in parallel. They are executed sequentially in an order
that is defined while the process instance runs. Therefore, in this book the
term sequential execution without a prior design time knowledge refers to this
pattern.
Activity models B,C,
and D are part of this pattern, so any sequential execution of activity instances
b, c and d are valid. This pattern is very useful in situations in which several
activities need to be executed sequentially and in any order. Since for any n
elements there are n! permutations, each of which corresponds to a sequential
execution ordering of n activity instances, modelling these explicitly is not
feasible.
The pattern can even be extended so that the execution ordering is not defined
before the first activity instance of the pattern has started. The sequence
can be defined also during the execution of the activity instances. A concrete
example is as follows: three persons need to work on a file, and each person
works on a separate part, so that the order in which the work is conducted is
not relevant. In this setting, after completing the first activity instance, one
person selects the next person to do his or her work.
The sequential execution in this case is induced by the single resource—
the file—that cannot be shared by the persons. Therefore, current allocation
of work to persons can be taken into account when deciding at run time on
the actual sequence in which the activities are executed.

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

2009-08-29T20:53:00.002+05:30

Multiple Instances With A Priori Design Time Knowledge

In the multiple instances with a priori design time knowledge pattern, the
number of activity instances of an activity model is known at design time.
These activity instances are synchronized, so that once all activity instances
have completed, the follow-up activity is enabled.
The follow-up activity c can only be enabled after the last activity instance
of B has completed, in this case b1. This property is shared by all multiple
instances patterns that are “synchronized.”
The specific property of the pattern at hand is that the number n = 2 of
activity instances of B is defined at design time, i.e., as part of the process
model. Depending on the process language used, there can be an attribute of
the activity model B that states, for instance, NrOfInstances = 2;.

Multiple Instances With A Priori Run Time Knowledge

In the multiple instances with a priori run time knowledge pattern, the number
of instances of a given activity model depends on the characteristics of the
case or the availability of resources. Therefore, it is only known at some stage
during run time of the process instance, but before the instances of the multiple
instances activity are created. This pattern also assumes synchronization
of the activity instances before the next activities can be enabled.
Rather than specifying the number of activity instances directly, we define
an expression. This expression is evaluated during run time to compute the number of activity instances for a specific process instance. This computation
occurs before the activity instances of the multiple instances activity are
created.
A process language might provide a functional representation of the number
of instances to create, so that, for instance,
NrOfInstances = GetNoOfLineitems(order);
might be a valid term. Here, the number of activity instances is computed by
a function that takes the current order and returns the number of line items
in it. An individual activity instance is then performed for each line item.

Multiple Instances Without A Priori Run Time Knowledge

In the multiple instances without a priori run time knowledge pattern, the
number of instances of a given activity is not known during design time; nor
is it known at any stage during run time before the instances of that activity
are enabled.
The difference with the previous pattern is that even while some of the
instances are being executed or have already completed, new activity instances
can still be created. During the
execution of these activity instances, new activity instances are created.When
all instances of B have terminated—in the example, b5 is the last activity
instance to complete—the next activity instance in the process can be enabled.
In order to realize this pattern in a process language and in a process
engine, there need to be additional assumptions in place. The main question in this context is, until what point in time is it possible to create new activity
instances of B?
One choice would be to indicate that while bs are running, new instances
of the multiple instances activity can be created. While this is a valid choice,
realization of this might not be practical, because it would assume that the
activity instances would include the creation of new instances, thereby intertwining
process management tasks (start new process instance) and doing the
actual work.
An alternative solution is to install a management activity related to the
multiple instances activity. This management activity explicitly defines the
end of the multiple instances activity. It is also responsible for creating new
instances of the multiple instances activity. It can even create new instances
after all instances have terminated. This is a valid approach, since in dynamic
settings, there might be an explicit decision about whether additional activity
instances are required to achieve the business goal related to the multiple
instances activity.
In the first alternative—if the follow-up activity is automatically enabled
after the current instances of the multiple instances activity have completed—
there are no options to create new instances of the multiple activity task once
all instances have completed.

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

2009-08-26T19:55:00.001+05:30

Implicit Termination

The implicit termination pattern is defined as follows: a given process instance
should be terminated when there is nothing else to be done. This means, there
is no activity instance in the process instance in the init, ready, or running
state and—as a result—no activity instance can be become enabled.
While implicit termination is defined as one of the control flow patterns,
its role differs with respect to the other patterns. It does not relate activity
instances with each other, such as, for instance, the sequence pattern or the
split and join patterns discussed. It represents a termination condition of an
overall process.
In several process languages, termination is explicit, because there is exactly
one state in the process that marks its termination. If there are many
states in which the process can terminate, then termination is implicit.

Multiple Instances Without Synchronization

More important than implicit termination are the patterns involving multiple
activity instances. These activity instances are based on a single activity model
in the context of a business process.
There are many situations that can be expressed properly by multiple
instances patterns. For instance, assume an order process in which an incoming
order contains a number of order lines. For each of these order lines, a check
activity needs to be executed. This means that only at run time can the
business process management system decide how many activities actually need
to be instantiated in order to perform the required checking activities.
The multiple instances without synchronization pattern is defined as follows.
In the context of a single process instance, multiple activity instances
of one activity model can be created. No synchronization of these activity
instances takes place.
In the process model shown, activity model B uses
the pattern. After the termination of activity instance a, a number of activity
instances are initiated and enabled for activity model B. In the event diagram,
activity instances b1, b2, and b3 are shown. These instances are enabled and
can be started.
The term “without synchronization” in the context of this example means
that the follow-up activity instance c can be enabled immediately after the
instances for B have been enabled. Since there are no assumptions on the
execution times of activity instances, c can terminate while activity instances
of the multiple instances activity are still running. In the event diagram shown,
b1 and b2 are still running when c has already completed.
This behaviour of the pattern has some consequences. First of all the control
flow between activity models B and C does not—strictly speaking—have
the semantics of a sequence pattern, since an instance of C can be enabled
while instances of B are still active. As a result, the sequence pattern is somehow
violated by the multiple instances without synchronization pattern.
This pattern causes problems not only with the sequence flow, but also
with the termination of the overall process. Since the activity instances are
not synchronized, it cannot be guaranteed that these activity instances have
terminated when the end of the process is reached. This means that certain
execution guarantees related to soundness properties (which will be discussed
in Chapter 6) cannot be satisfied.
Multiple instances patterns can be distinguished for the point in time
when the actual number of instances is determined. The multiple instances
without synchronization pattern does not make any assumptions on whether
the number of instances is defined at design time or at run time. This is
subject of the control flow patterns discussed next.

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

2009-08-26T19:53:00.001+05:30

N-out-of-M Join

The N-out-of-M join is a generalization of the discriminator. It is a point in
a process model where M parallel paths converge into one. The subsequent
activity is initiated after N M paths have completed and the respective
termination events have occurred. Completion of all remaining paths is ignored.
As with the discriminator, once all incoming branches have fired, the
join resets itself so that it can be performed again. The N-out-of-M join is
illustrated in Figure 4.16.
A concrete example of the N-out-of-M join is a request for quotation
process, in which quotations are invited from five companies, although the
process can continue after receiving three quotations. Without a dedicated Nout-
of-M join, this business rule would be complex to model, because at design time it is not known which of the companies will respond to the request in
time.
There are variations on this control flow pattern with respect to the time
when the number N of sufficient threads is determined: it can be determined
at design time or at run time. The run time specification of N needs to be
done in an activity instance that is executed before the join.
There might be additional variations in the design time specification of the
N-out-of-M join if it is part of a loop. Design time specification of N could
therefore be taken within the loop, so that different iterations of the loop use
different values N for the number of sufficient threads to complete.
The N-out-of-M join degenerates to an and join if N = M. For N = 1,
however, it does not realize an exclusive or join, because the assumption of
the exclusive or join is not met (only one thread will be activated).
Nor does it realize a multi-merge, because in the multi-merge the completion
of the second and following threads would enable additional instances of
follow-up activities, while the 1-out-of-M join ignores them. The 1-out-of-M
join, however, realizes the discriminator pattern.

Arbitrary Cycles

An arbitrary cycle is a point in a process model where one or more activities
can be executed repeatedly. An arbitrary cycle is graphically depicted in Figure 4.17. In this example,
a sequence consisting of activity models A, B, and C is iterated. The iteration
is represented by an exclusive or split that decides whether to iterate the cycle
or whether to leave it and continue with activity instance d, associated with
activity model D. In case the loop is iterated, the exclusive or join triggers
another instance associated with activity model A.
As this example shows, arbitrary cycles are expressed with other control
flow patterns, for instance, exclusive or split and exclusive or join. Since these
control flow patterns have been specified already, no additional definitions are
required in order to define the arbitrary cycles pattern.
The problem in this example is that the cycle enters
one of two concurrent branches of an and split whose branches are joined by
a multi-merge.
The process starts by activitiy instance a, followed by the concurrent execution
of b1 and c1. When c1 completes, the first firing of the multi-merge
spawns off d2. We assume that the loop is not taken, so that e2 is started.
While d2 is still active, b1 terminates, so that the multi-merge creates
another instance of activity model D, namely d3. If the loop is iterated, the
second instance of activity model B is created, i.e., b3 (it holds the same
thread identifier than the previous activity instance).
When b3 terminates, d4 is started, and the loop can be entered again by
spawning off b4. To reset itself, the multi-merge waits for c3. Since the loop
was entered only in one of the concurrent branches, however, c3 does not exist!
Therefore, the multi-merge will not enable new instances of activity model D
when additional instances of activity model B complete.
In this example, after b4 terminates, the process instance will enter a
deadlock, because the multi-merge does not enable a new instance d5. An
event diagram of this execution is depicted in Figure 4.19.
This example shows that the combination of the multi-merge pattern with
loops might cause problematic process behaviour that process designers need
to be aware of to avoid erroneous processes.

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

2009-08-23T16:38:00.000+05:30

Discriminator
The discriminator is a point in a process model that waits for one of the
incoming branches to complete before activating the subsequent activity. From
that moment on it waits for all remaining branches to complete and “ignores”
them. Once all incoming branches have been triggered, it resets itself so that
it can be triggered again. This allows a discriminator to be used in the context
of a loop.
If gathering the ignored branches were not part of the functional behaviour
of the discriminator pattern, there would be no way to distinguish a second
iteration of a loop from a late branch of its first iteration.
A process model with activity models B, C, and D, and a gateway G such
that E {(B,G), (C,G), (G,D)} and type(G) = Discriminator.To discuss the execution semantics of the discriminator, assume
that activity instance b terminates while c is still active. If this is the case, d
is triggered, and the discriminator continues to wait for the termination of c.
When c terminates, the discriminator is again ready for the next thread.
The process starts with activity instance a before an and split occurs that
spawns activity instances b1 and c1. Assuming b1 terminates first, the discriminator
fires and enables d1. When d1 terminates, assuming a new iteration of
the loop is required, new activity instances based on B and C are created. These activity instances are b2 and c2. What is remarkable in this example is
that there are two instances of activity model C active concurrently, assuming
c1 has not yet terminated.
Even if c2 terminates before c1, the semantics of the discriminator makes
sure that it can only fire and enable d2 after the first iteration has completed,
i.e., only after the remaining activity instance c1 has terminated. If this is
the case, the discriminator can fire a second time, to enable d2. Formally, for each enable event of d there are termination events of b and
c, and (at least) one of these termination events occurs prior to the enabling
event of d, i.e., 8ed 9tb, tc 2 Ep, such that tb < bd _ tc < bd.
In addition, the discriminator can become active only after the termination
events of all incoming edges that belong to the thread that has spawned the
current activities have occurred. In the example, d2 can only be enabled after
the termination operation of c1 has occurred.

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

2009-08-23T16:36:00.000+05:30

Multiple Merge

A multiple merge or multi-merge is a point in a process model where two or
more concurrent threads join without synchronization. The activity following
the merge is started for every activation of every incoming branch.
The multi-merge is functionally equivalent with the exclusive or join; the
only difference is that the latter assumes that only one of its incoming branches
gets activated. This assumption is not in place for the multi-merge pattern.
A process model with activity models B, C, and D, and a gateway G
such that E {(B,G), (C,G), (G,D)} and type(G) = MultiMerge.
For each terminating activity instance b and c, one activity
instance associated with activity model D is started. This means that for each
termination event ti 2 Ep, where i 2 {b, c}, there is an enable event ed that
occurs after the respective termination event, i.e., ti < ed, i 2 {b, c}.
The multiple merge pattern spawns off new threads of control. These
threads need to be identified so that future joins can be realized properly.
These aspects are illustrated in an example shown in Figure 4.11, where a
process model with an and split followed by a multi-merge is shown. As a
result, any of the threads induced by the and split will survive the multiple
merge and spawn a new instance for activity model D and of the activity
models following D in the process model.
Each of the threads of control spawned off by the multi-merge is subject
to the and split/and join shown in the process model. The and join requires
information on the identity of the threads that come in; otherwise, situations
could arise in which activity instances that belong to different threads of
control are synchronized. These issues can be illustrated by the event diagram This diagram can be considered an abstract form of an
event diagram in which the lifetime of each activity instance is shown as a line
with borders marking the enabling and terminating of the activity instance.
The process starts with activity instance a, followed by the concurrent
execution of b and c. Assuming b terminates before c does, the multi-merge
spawns off a new thread of control, called thread The first
activity instance of this thread is d1.
While d1 is still running, c terminates, and the multi-merge spawns off
thread 2, starting with d2. When d1 completes, the and split occurs, and
concurrent threads are created, realized by activity instances e1 and f1.
After d2 terminates, e2 and f2 are created. Assuming that f1 and e2 terminate,
the and join faces a situation in which there are termination events of
activity instances on its incoming edges. Knowing that these belong to different
threads of control (f1 belongs to thread 1, while e2 belongs to thread 2),
the and join can “decide” that these threads cannot be synchronized, although
they belong to the same process instances.

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

2009-08-16T14:39:00.002+05:30

And Split

An and split or parallel split is a point in a process model where a single
thread of control splits into multiple threads of control which are executed concurrently. Consider a process model with activity models A, B, and C and
a gateway G such that E {(A,G), (G,B), (G,C)} and type(G) = AndSplit.
Since thereby the process model P = (N,E, type) is well defined, we refrain
from providing the formal definition of P with the subsets of N. An and split determines that for each termination of an activity instance
a there are enable events of activity instances b and c, and these events occur
after the termination event of a. Therefore, for each ta 2 Ep there exist eb, ec 2
Ep such that ta < eb ^ ta < ec.

And Join

An and join is a point in a process model where multiple concurrent threads
converge into one single thread of control. It is an assumption of this pattern
that each incoming branch is executed exactly once.
Consider a process model with activity models B, C, and D, and a gateway
G such that E {(B,G), (C,G), (G,D)} and type(G) = AndJoin. For each enable event of an activity instance d, there are termination events of activity
instances b and c, such that the termination events occur before the enable
event. Therefore, for each ed 2 Ep 9tb, tc 2 Ep such that tb < ed ^ tc < ed.

Xor Split

An xor split or exclusive or split is a point in a process model where one of
several branches is chosen. A process model with activity models A, B, and
C and a gateway G such that E {(A,G), (G,B), (G,C)} and type(G) =
XorSplit The execution semantics of an exclusive or split determines that for each
termination of an activity instance a associated with activity model A there is
either an enable event of activity instance b or an enable event of an activity
instance c, but not both: for each ta 2 Ep: eb 2 Ep , ec /2 Ep, such that either
ta < eb or ta < ec.

Xor Join

An xor join or exclusive or join is a point in a process model where two
or more alternative threads come together without synchronization. It is an
assumption of this pattern that exactly one of the alternative branches is
executed.
Consider a process model with activity models B, C, and D, and a gateway
G such that E {(B,G), (C,G), (G,D)} and type(G) = XorJoin.
For each termination event of an activity instance b or c there is one and
only one enable event of an activity instance d. Therefore, for each ti 2 Ep,
such that i 2 {b, c} there is an event ed 2 Ep such that ti < ed.
While it is an assumption of this pattern that the branches are alternative
and none of them are ever executed in parallel, the branches can be part of
a loop. But even in this case, for each iteration of a loop, the branches are
alternative and have exclusive or semantics.

Or Split

An or split is a point in a process model where a number of branches are
chosen. Selection of any nonempty subset of branches is a proper behaviour of
an or split. Figure 4.8 shows a process model with activity models A, B, and
C and a gateway G such that E {(A,G), (G,B), (G,C)} and type(G) =
OrSplit.
An or split restricts the events of related activity instances as follows: for
each termination event of a there is a subset of enable events of b and c. In
general, for each termination event of a there can be enable events for any
subset of activity instances on the outgoing branches of the split.
In the example, the respective enable events are eb, ec 2 Ep, and any subset
of this event set reflects an acceptable behaviour of the or split, as long as
ta < eb and ta < ec are satisfied (if both branches are selected). In the general case where the or split has n
outgoing edges, 2n −1 options are possible: all nonempty subsets that can be
created out of n activities.

Or Join

An or join is a point in a process model where multiple threads of control
converge into one single thread. It is an assumption of this pattern that a
branch that has already been activated cannot be activated again while the
merge is still waiting for other branches to complete.
A process model with activity models B, C, and D, and a gateway G such
that E {(B,G), (C,G), (G,D)} and type(G) = OrJoin . Once all active branching paths are completed and the respective end events of the final activities in these paths have occurred, the synchronization takes place.
Either only
the upper thread is taken and only activity instance b is enabled, or only the
lower thread is taken and c is enabled, or both threads are performed and b
and c both are enabled. In general, any nonempty subset of the threads are
valid options, so that 2n − 1 options are allowed for n incoming edges of the
or join.
The or join is a problematic control flow pattern. The problem is that
the join cannot locally decide how long to wait for its activation. Even from
the simple process model fragment shown in Figure 4.9, this problem can be
explained: once one incoming branch is triggered, for instance, by termination
of b, how should the or join react? There are two options:
• Wait: The or join waits before the activity instance d is triggered, because
the other incoming path—which completes in activity instance c—can still
be executed.
• Trigger : The or join triggers d immediately after the termination of b.
The problem is that we cannot decide which of these alternatives the correct
one is. After the first incoming branch has terminated, how long should the
or join wait for the other branch to complete?
If no additional knowledge is available, there is no way of deciding whether
c will eventually terminate for the particular process instance. Since there is no upper bound on the waiting time, realizing the waiting alternative leads
to a deadlock situation if the second thread is never activated.
If the or join triggers d after one incoming branch is activated, a situation
might occur in which c terminates after d has already started! This behaviour
contradicts the semantics of the or join, since in this case it has to wait until
both branches complete.

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

2009-08-16T14:36:00.003+05:30

Control Flow Patterns

Control flow patterns provide a yardstick for expressing process orchestrations.
Control flow patterns are independent of concrete process languages, so that
each pattern can be expressed in different process languages. Control flow
patterns can also be used to compare the expressiveness of process languages.
Basic control flow patterns include sequence, and split, and and join, as
well as exclusive or split and exclusive or join. These control flow patterns
are supported by virtually any process metamodel. Control flow patterns are
defined at the process model level. Their execution semantics, however, applies
to process instances.
In this section, the semantics of control flow patterns will be investigated
on the basis of the events and event orderings they imply on process instances.
Due to its simplicity, the sequence pattern is well suited to explaining the
general approach.
Consider a process model P = (N,E, type) according to Definition 3.3
with activity models A and B and a sequence flow A ! B. This process
model defines an ordering on the activity instances associated with A and
B in the context of a single process instance: for each process instance, the
activity instance associated with B can only start after the activity instance
associated with A has terminated.
As a result, the process model restricts the ordering of events that occur
during process instances. In the example, the termination event of the activity
instance associated with activity model A must occur before the begin event
of the activity instance associated with activity model B.
Each control flow construct is represented in the process model by a gateway.
As with activity instances, there are instances for gateways, e.g., an
instance of a sequence flow ordering the execution of two activity instances.
Each gateway instance has a begin event and a termination event. For a uniform
treatment of control flow structures, sequences are also considered as
gateways, as discussed above.
Activity models are denoted by capital letters, A,B,C, . . ., while the associated
activity instances are denoted by a, b, c, . . .. In case multiple activity
instances are associated with an activity model in the context of a given
process model, subscripts are used, for instance, a1, a2, . . .. Gateways are typically
denoted by G, and g is an instance of a gateway. Let P be a process
model and p a process instance based on this model with an event set Ep.

Sequence

The sequence pattern defines that an activity instance b in a process instance p
is enabled after the completion of activity instance a in p, with process model P = (N,E, type) containing activity models A, B, and a gateway model
G such that A,B 2 NA, G 2 NG, E {(A,G), (G,B)}, and type(G) =
Sequence.
The application of the sequence pattern in A ! B induces an event ordering
between the termination event of a (and the activity instance of activity
model A) and b, such that b can only be enabled after a has terminated. This
approach relates the control flow patterns directly to the state transitions of
activity instances.
In particular, the state transition from init to enabled of an activity instance
b can only be done after the state transition from running of a to
terminated of a has occurred. In process instance p, for a termination event ta 2 Ep of an activity instance a, there is an enable event bb 2 Ep of an activity instance b, such that ta < eb.
The discussion captures well the case of a single activity instance per
activity model. However, if the activity models are part of a loop, then there
might be multiple activity instances based on activity models A and B.
Therefore, the execution semantics of the sequence control flow pattern
needs to be refined so that eventually for each termination event of some
activity instance a1, a2, . . . there is an enable event of an activity instance
b1, b2, . . ..
A fragment of a process model where A and B are part of a loop is shown
in Figure 4.3; to realize this loop, an exclusive split gateway, an exclusive or
join gateway, and a set of sequence flows are added.
A process instance based on this process model is shown in the lower part
of that figure. The loop is iterated three times, resulting in activity instances
a1, b1, . . . , a3, b3. Rather than showing all events of these activity instances,
just the enable and termination events are displayed. As can be seen in the
event diagram, in each iteration of the loop, the activity instance ai terminates
before bi can start, for i 2 {1, 2, 3}.
However, the ordering “first a then b” can be violated if a and b belong to
different iterations of the loop. For instance, the termination event of b1 occurs
before the start event of a2. In order to capture loops properly, it is necessary
to define that for each termination event of a there is an enable event of b such
that ta < bb. This condition is satisfied by the process instance: for ta1 < eb1,
ta2 < eb2, and ta3 < eb3.
These event orderings relate termination events to enable events and not
direcly to begin events. Since begin events can only occur after the respective
enable events have occurred, it is guaranteed that the termination event of ai
occurs before the begin event of bi.

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

2009-08-14T19:32:00.002+05:30

Architecture of Process Execution Environments

So far, this chapter has discussed the modelling of different aspects of a business
process. This section looks into the representation of a business process
management system capable of controlling the enactment of business processes
based on business process models.
The architecture
model contains the Business Process Environment, a Business Process Modelling
subsystem, a Business Process Model Repository, a Process Engine, and
a set of Service Providers. The roles of these constituents of the architecture
model are characterized as follows.
• Business Process Modelling: The business process modelling subsystem
is used for creating business process models, containing information on
activities, their operations, and the structure of the business process. This
architecture subsystem can be realized by business process modelling tools.
• Business Process Environment: The business process environment triggers
the instantiation and enactment of process instances based on process
models.
• Business Process Model Repository: The business process model repository
holds business process models that are created by the business process
modelling component.
• Process Engine: The process engine is responsible for instantiating and
controlling the execution of business processes. It is the core component
of a business process management system. This component is triggered by
the business process environment. It uses process models to instantiate and
control the enactment of process instances. To execute a particular activity
instance, it calls entities that act as providers of the required functionality.
In a service-oriented architecture, service providers are called to execute
individual services that realize business process activities.
• Service Providers: Service providers host application services that realize
business process activities. In the architecture model, service providers
represent an abstract entity that subsumes not only Web service providers
but also knowledge workers that realize particular activities in business
processes. The organizational and technical information that the process
engine needs in order to determine and access the service provider is also
stored in the business process model repository.
These components of the architectural model control the enactment of process
instances. To capture the distributed nature of business process executions,
the components and the service providers are represented by agents that communicate
by sending and receiving messages, i.e., the agents do not share
memory, but are distributed.
Gateways are nodes in a process model that are used to guide the process
flow. Therefore, for each gateway node the process engine needs to perform
some action. This work that the process engine conducts is represented by
a gateway instance, just as the work defined by an activity model is represented
by an activity instance. A property of gateway instances is that the
process engine executes them, whereas activity instances are executed by service
providers, requiring nonlocal communication.
The first event that occurs represents
the occurrence of the initial event in the process model. Let e1 be this
event.
The process engine detects that there is a process model defined for this
event. Therefore, a process instance is instantiated. For each activity model in
the process model, an activity instance is instantiated; for each gateway node,
a gateway instance is created, represented by events i2 through i6. When the
instances are initiated, the AnalyzeOrder activity instance can be started,
resulting in event b2. After the termination of this activity instance in event
t2, the gateway instance is started, represented by event b3.
After the gateway instance terminates in event t3, the process engine can
decide which path to take. In the process instance shown, the advanced check
activity instance is disregarded and the simple check path is taken. Therefore,
the AdvCheck activity instance is skipped, represented by event s5. The SimpleCheck
activity instance is started (event b4) and later terminates in event
t4. Finally, the execution of the gateway instance and the occurrence of the
final event n7 terminate the process instance.
The event diagrams introduced are extended to capture agents involved
in the enactment of process instances. Each agent is represented by a horizontal
line, on which the events that occur in this agent are drawn. Time
proceeds from left to right. In addition to the events directly associated with
the execution of activity instances, the begin and end of a computation and
the sending and receipt of a message are also represented by events. Message events of agents represented by directed arcs connecting the send event with
the corresponding receive event.
The business process environment, the process engine, and two service
providers are the agents represented in the event diagram. Since the operation
of the business process modelling component is not the focus of attention,
these components of the architecture model are not represented as agents in
the event diagram.
When the initial event of the process model occurs in the business process
environment, the process engine instantiates a process instance, including its
activity instances. Then, the process engine determines the first activity instance
to be executed. A service provider is determined for executing this
activity, in the example, Service Provider 1.
The service provider receives this message and starts an AnalyzeOrder
activity instance, marked by event b2. Once that activity instance is completed
(t2), the service provider returns a message to the process engine. This message
typically contains the return value of that invocation. Using this information
and possibly other information, the process engine can evaluate the condition
associated with the gateway node. Based on the decision made by the process
engine on behalf of the gateway, the AdvCheck activity instance is skipped
(skip event s5) and the SimpleCheck activity is started.
In order to realize this process instance, the process engine sends an invocation
message to the service provider responsible for executing the simple
check service. Service Provider 2 receives this message and starts the SimpleCheck
activity, marked by event b4.
Once this activity instance completes in event t4, the service provider
returns a message to the process engine, which then executes the join gateway
node (events omitted). The process instance completes with the final event and by sending the respective message to the business process environment,
informing it about the termination of the process instance.
As will be detailed in the next chapter for more complex workflow patterns,
control flow patterns restrict the ordering of execution events for activities
involved in a business process. For instance, an AnalyzeOrder activity can
only be started after the initial event has occurred, and a SimpleCheck activity
can only be started after the exclusive or gateway has completed, and so on.
The execution semantics of a process instance based on a process model is
described by restrictions on the events and their ordering during the execution
of process instances.

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

2009-08-14T19:30:00.001+05:30

Selection of Business Partners in Process ChoreographiesThe modelling of organizational aspects in business process management
can be extended to business partners, which is important in the context of
business-to-business processes.
Consider a business process choreography with multiple business partners,
each of which plays a specific role in the choreography. If there is a role Shipper
specified according to the requirements for shipping goods, it can be bound to
specific enterprises that can perform the work. Additional flexibility is gained
because the organizations participating in a choreography are not hardwired,
but represented at the model level.
There are different options for selecting a particular shipper. The selection
can be done before a particular process instance starts. This alternative is
useful if sufficient information on the goods to be shipped is available before
the process starts.
In scenarios where only during run time of the process instance are the
goods and the sender and receiver determined, the dynamic selection of a
shipper is useful. Based on the information on the shipment and on its additional
properties—such as dangerous goods—an appropriate shipper can be
selected at run time.
Before the process choreography can be realized, the broker requires information
on the suppliers available. This information is gathered by the broker in a
separate process choreography, whose message flow is not shown in the figure.
The process choreography starts with the creating of an order by the customer.
Then, the customer sends a Request Supplier Info message to the broker.
The broker receives this message and uses local information to find the
supplier most suitable for fulfilling the order. In the Send Supplier Info message,
the broker informs the customer about this supplier.
The customer receives this message and uses the information received to
send an order to the selected supplier, Supplier-A in this case. When the
supplier has processed the order, the supplier sends the goods to the customer,
and the process completes.
In the example shown, the selection is performed using a third party, the
broker. While this is a valid option in scenarios where a broker has rich information
on a set of business partners, the selection can also be done locally,
i.e., without the involvement of a third party.
In this case, the actual selection can be performed as a manual activity,
using information on suppliers available and capable of fulfilling the order.
Role resolution in this case is not performed by the business process management
system, but by a knowledge worker. This task also matches the
service-oriented approach, where a service requestor (the knowledge worker)
uses the broker to select from among a set of services (supplier services) the
one that is suited best for the task at hand.

Standardized Software Interfaces

Standardized interfaces to existing software systems are another means of
flexibility in business process management. A variety of techniques to specify
software interfaces are known from software engineering and software architectures.
It is a key concept to decouple the use of a software component from its
implementation, i.e., to hide implementation details from usage information,
following the information hiding principle.
In the context of business process management, standardized software interfaces
are of crucial importance in system workflows, and also in human
interaction workflows, since the overall process structure can be decoupled
from the implementation of particular activities realized by software components.
A flexible association of process activities with software systems allows us
to change the implementation of specific process activities without changing
the overall business process. There are two variations: the software system
realizing a particular activity can be defined at design time of the process or at
run time of the process instances.
We assume that an ERP system is deployed to provide the functionality
of the order management system and of the inventory management system in
an integrated, robust, and scalable manner.
By standardized software interfaces, the business process activities can use
the functionality of the new system without changing the business process.
This enhances the flexibility of the business process implementation, because
the realization of particular process activities can be changed without modifying
the business process.
This discussion describes an ideal setting, in which activity realizations
can easily be exchanged. However, specific properties of legacy systems make
the definition of clean, standardized interfaces cumbersome, because legacy
systems offer their functionality typically by proprietary and often not well
documented interfaces.
In addition, the granularity with which legacy systems provide functionality
often does not match the granularity required by the business process. In
particular, legacy systems often realize complex subprocesses rather than individual
activities in a business process. Sometimes, the processes realized by
legacy systems and the modelled business processes are not immediately comparable.
These issues have to be taken into account when software interfaces
to existing information systems are developed.
One option to solving this problem is developing software interfaces that
make available the functionality provided by legacy systems with a granularity
that allows reuse of functionality at a finer level of granularity. The granularity
should match the granularity required at the business process level.
Depending on the legacy system, its complexity, software architecture,
and documentation, as well as the availability of knowledgeable personnel,
the required effort can be very high. If the need for finer-grained granularity
and efficient reuse of functionality is sufficiently high, then partial or complete
reimplementation can be an option.

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

2009-08-09T14:09:00.001+05:30

Organizational Modelling

The modelling of organizational aspects also provides flexibility in business
process management. In this section, role resolution in an intra-company setting
is discussed, in which different approaches are investigated to associate
knowledge workers with business process activities .
In the case of human interaction workflows, the enactment environment of
the business process has to take into account the organizational structure of
the company that runs the business process. Flexibility in organizational modelling
is achieved by assigning roles to process activities, and not to specific
individuals.
By associating roles with activity models at design time and mapping roles
to personnel that is skilled, competent, and available to perform the activity
at run time, flexibility is improved, because changes in the personnel structure
of the organization do not affect the business processes.
For instance, absent knowledge workers are not with associated with specific
activity instances, as are persons who are currently available. Thereby, the dynamic aspect in the organization—knowledge workers might be temporarily
absent or there might be changes in the work force—can be represented
at the model level. Consequently, changes in the personnel are hidden from
the process, as long as the roles defined in the model can actually be filled by
persons in the organization.
Consider a business process with a set of activities that need to be executed
sequentially.These activities involve entering a credit request
(Enter Credit Request), gathering information on the financial situation of
the client (Analzye client), proposing a decision on the credit request, and
reviewing and submitting the decision.
A subset of these activities is assigned the same role. In the example,
a clerk is responsible for the first three activities, whereas the clerk’s boss
finally decides and submits the decision. This situation can be represented in
a business process model by associating the role Clerk and the role Boss with
their respective activities.
For each process instance by role resolution, the system offers these activities
to knowledge workers who can fulfil the respective role. Figure 3.35 shows
a situation in which three different knowledge workers with the role Clerk are
associated with the activity instances of that role.
While this role resolution is correct from a formal point of view, this situation
is undesirable in most cases because each clerk needs to understand the
context of the case, which leads to longer process durations and potentially
incorrect decisions.
In the example, the handover of work from Peter to Charles and from
Charles to Anne leads to delays in process executions and should therefore
be avoided. In addition, Charles needs to get familiar with the case entered
by Peter, and Anne needs to get familiar with the case that Charles analyzed
beforehand.
This figure also shows that at the business process instance level, knowledge
workers are associated with activity instances, while at the business
process model level, roles are associated with activity models.
To provide adequate support through role resolution, the business process
model needs to contain the information that whoever conducted the first clerk activity also has to conduct the other two clerk activities. In this case, all
clerk activities are associated with Charles, who then can perform them much
quicker than the three persons in the previous setting.
This advanced role resolution works well if the same knowledge worker
is available during the whole business process instance—or at least during
the steps that the person conducts. But there are cases where a person has
started on a process instance by conducting the first activity, but then becomes
unavailable.
In this case, a decision needs to be made: either the process is delayed
until the person returns to work or the case is transferred to another clerk.
This clerk needs to understand the overall context of the case before he can
start processing the activity. This decision is influenced by multiple factors,
such as the type of business process, the expected delay, and the effect of the
delay, and therefore cannot be performed automatically in general.

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

2009-08-09T14:06:00.002+05:30

Business Process Flexibility

The quest for flexibility can be regarded as the main driving force behind
business process management, both at an organizational level, where strategic
business processes are investigated, and at an operational level, where
human interaction workflows and system workflows are important concepts
for realizing business processes.
According to Wikipedia, flexibility refers to the “ability to easily bend an
object or the ability to adapt to different circumstances.”
In todays dynamic market environments, “different circumstances” are
induced by changes in the market environment of the company. Business processes
are objects that need to adapt easily to changes. Since products that
companies provide to the market are generated by business processes, flexible
business processes are an important asset for coping with market changes in
an effective manner.
Different aspects have to be taken into account when considering flexibility.
First of all, flexibility is provided by explicit representation of business
processes, because adaptations of explicit, graphically specified business processes
is much easier than adaptation of written organizational procedures or
business policies buried in software code.
Enactment platforms, such as workflow management systems, provide
powerful mechanisms for enacting business processes in diverse technical and
organizational environments. One area specific to human interaction workflows
is the assignment of knowledge workers to process activities.
In typical workflow environments, such as system workflows and human
interaction workflows, information systems are required for enacting workflow
activities. The interfaces to these systems might be hardcoded in the adapters
of the workflow management system. In dynamic software landscapes, where
functionality is provided through standardized interfaces, the ability to change
the binding of particular software to workflow activities is another source of
flexibility.

Explicit Process Representations
Business process management systems are created to narrow the gap between business goals and their realization by means of information technology. The
main way to provide this flexibility is based on explicit representations of
business processes at different levels. While organizational business processes
have a coarse-grained structure and are typically specified textually by forms,
operational business processes consist of process activities, and execution constraints
that relate them.
Explicit process representations provide flexibility, since changes to the
current process can be discussed and agreed upon by the different stakeholders
involved in the design of the business process. In this context, flexibility is achieved by changes at the business process model level that are immediately
translated to actual business process instances.
This process features a sequence of activities, where the first activity
to store the order is preceded by a start event. After the order is stored,
the inventory is checked. This version of the business process rules that the
shipment is prepared only after the invoice is sent and the funds are received.
Finally, the goods are shipped and the process terminates.
Due to the somewhat cautious policy realized by the business process—
prepare shipment only after receiving the funds—business process instances
based on this process model might suffer from long processing times, resulting
in insufficient customer satisfaction.
In order to solve this problem, the process owner starts a review of this
business process by inviting process participants and process consultants to
a joint workshop. The business process model is used as a communication
platform for these stakeholders at this workshop.
Discussing the problem of the process instances, the stakeholders find out
that concurrency can be exploited within the process. If activities can be
executed concurrently, their order of execution is irrelevant. For instance, the
preparation of the invoice can be started before the shipment is handled. The
new and improved version of the business process is shown in Figure 3.33.
Although in this example the deficits of the business process are obvious,
the improvement of the process by introducing concurrency shows quite well
how an explicit process model can foster response to change.
The translation of the business process model to the actual operational
environment can be realized in different ways. If the business process is realized
by a human interaction workflow, then the modified business process
model needs to be deployed in the workflow management system. Deployment
typically includes enrichment of the business process model with information
to make the process executable.
In particular, there needs to be a translation from the graphical model to
an executable format that is specified in a particular workflow language or—
in case the system workflow is realized in a service-oriented environment in a service composition language. In any of these realizations, the explicit
representation of business process models provides the flexibility to change
the process and to finally enact the modified process.
New process instances would then follow the new, improved business
process model. If, on the other hand, business processes are enacted without
any system support, then the business process model is translated manually
to a consistent set of procedures and policies that the knowledge workers need
to follow.
The flexibility resulting from the explicit modelling of business processes
is fundamental to business process management applications.

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

2009-08-07T13:58:00.001+05:30

Modelling Operation

While business process management organizes the work that a company performs
by focusing on organizational and functional aspects, the realization
of business process activities also needs to be taken into account. Activities
can be distinguished depending on the level of software system support. The
terms system workflows and human interaction workflows were introduced to
characterize the different kinds of business process enactment.
A classification of activities in business processes was introduced in Figure
3.1, consisting of system activities, user interaction activities, and manual
activities. To recapitulate, system activities are performed by software systems
without user interaction, user interaction activities require the involvement of
human users and manual activities do not involve the use of information systems.
During the enactment of human interaction workflows, knowledge workers
perform activity instances. When a knowledge worker starts working on a specific activity, the respective application program is started, and the input
data as specified in the process model is transferred to that application program.
When the knowledge worker completes that activity, the output data
generated is collected in the output parameters. These parameter values can
then be stored in the application program. They can also be transferred by
the business process management system to the next activity, as specified in
the business process model.
Business process modelling aims at mapping high-level and domain-specific
features of the application process; the technical details—the main components
of the operational perspective—are taken into account in the configuration
phase of the business process management lifecycle. The heterogeneous
nature of information technology landscapes led to various kinds of interface
definitions, most of which did not prove to be compatible. With the advent of
service-oriented computing, the operational aspects of business processes are
represented by services, providing the required uniformity.
This section discusses how activities realized by software functionality can
be modelled. Conceptually, the same levels of abstraction apply to modelling
the operational perspective as to modelling the other perspectives: at the
metamodel level, interface definition languages reside. They describe specific
interface definitions at the model level. At the instance level executing software
code is categorized.
This approach fits the modelling of activity instances (and, therefore, also
to process instances) well, because activity instances can be realized by executing
software code. It also fits the organizational perspective in which persons
reside at the instance level. Persons are—at least in human interaction
workflows—responsible for performing activity instances.
In order to automatically invoke this software functionality, business
process management systems require concepts and technology to access these
systems. The operational perspective of business process modelling provides
the information that equips a business process management system with information
required to invoke the functionality of external application systems.
The operational perspective includes the invocation environment of application
programs, the definition of the input and output parameters of the
application program, and their mapping to input and output parameters of
business process activities. Therefore, functional requirements need to be detailed
in order for us to evaluate whether a certain software system provides
the required functionality in the context of a business process.
This perspective is not limited to functional requirements. Non-functional
requirements also need to be represented, for instance, security properties
and quality of service properties of the invoked applications or services, such
as execution time and uptime constraints. In service-oriented architectures,
these properties are typically specified in service-level agreements between
collaborating business partners. These service-level agreements are part of a
legal contract that the parties sign.
Interface definition languages are used to specify the usage of procedures
and functions, implemented by software system. They are also essential to
connect software systems that have been developed independently from each
other. Therefore, they are essential for middleware systems. Middleware based
on service-oriented architectures play an increasingly important part as realization
platforms for enacting business processes. The reminder of this section
discusses aspects of service-oriented architectures that are relevant for business
process management.
The creation of service wrappers that encapsulate business-relevant functionality
of existing information systems is called service-enabling. While there
are environments in which one service is realized by one information system,
the typical case is where business functionality is realized by the interplay of
multiple existing application systems, making service-enabling a costly and
complex matter.
Service-enabling closes the gap between business process activities and
the technical infrastructure for realizing them.
AnalyzeOrder is realized by a
service called Analyze Order Service which combines the functionality of three
underlying software systems that run on a technical infrastructure. While
the definition and realization of the Analyze Order Service is a complex and
challenging task, this book assumes that dedicated business functionality is
available and can be used to realize activities in business processes.
Service-oriented computing also facilitates the dynamic binding of services
to particular business process activities. This situation is represented in the
conceptual model of these layers by a many-to-many relationship between
activity and service. This means that a given activity can be realized by multiple
services. Advanced concepts in service engineering facilitate the dynamic
binding of a business process activity to a service at run time, providing the potential to increase fault tolerance by selecting from a set of possible services
a service that is currently operational.
A more detailed picture is provided in Figure 3.31, where enterprise application
integration middleware is explicitly shown. Two legacy systems provide
their functionality via enterprise application integration middleware. For each
of these systems, an adapter is realized that hides the heterogeneity of the
legacy systems from higher levels. But there can also be existing software
systems that do not require the enterprise application integration middleware
layer.

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

2009-08-07T13:54:00.003+05:30

Deferred Allocation

In deferred allocation, the decision about who performs an activity instance
is only made at run time of the business process. To this end, there is no
distinction between deferred allocation and role-based allocation. However,
in deferred allocation, rather than using the role information defined during
design time, the allocation is performed as an explicit step in the business
process, and not influenced by role information

Authorization

Authorization allocates persons to activity instances based on their positions.
So, a list of positions is enumerated that specifies the persons who can perform
the activity instance. This could also be achieved by adding a new role
that captures the authorization. A specific type of authorization that uses
capabilities of the knowledge worker to perform allocation is also possible.

Separation of Duties

The separation of duties allocation scheme relates different allocations within
one business process. For instance, a document needs to be signed and countersigned
by two employees with a common role. In role-based allocation, these
activities could be performed by the same employee. Separation of duties allows
relating allocations in a way that this is ruled out, so that each document
is signed by two different employees.

Case Handling

In the case handling allocation scheme, certain activities in a business process
require an understanding of the overall case. In these environments, it is useful
that the same knowledge worker deals with all activities of one business
process instance. This avoids errors and reduces processing time, because the
knowledge worker already knows the case, and so can solve the issues at hand
more efficiently than a colleague to whom the case is not known “retain familiar” allocation scheme is very similar to case handling; however,
not all activity instances of a case are allocated to one specific knowledge
worker, but rather only a subset of them.

History-Based Allocation

The idea of history-based allocation is that a person is allocated to an activity
instance based on what this person worked on previously, i.e., on the history
of the activity instance that he or she completed. This includes other business
process instances. The goal is to allocate work to persons according to their
personal experiences and expertise that is not represented in the role information.
While this is not part of a role specification, this information needs
to be represented in the business process management system so that it can
decide on the allocation based on the history and personal experiences. This
allocation scheme is useful for realizing a “one face to the customer” strategy,
in which for each customer there is a dedicated individual responsible for all
aspects of communication with it.

Organizational Allocation

If organizational allocation is used, not roles but the positions within the
overall organization are used to allocate activity instances. For instance, to
authorize expenditure, the manager of the organizational unit that requested
the expenditure needs to approve. Depending on the particular language used
to express organizational allocation, complex allocation rules can be realized,
all of which take advantage of the organizational structure of the company.

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

2009-08-05T14:20:00.001+05:30

Direct Allocation

In direct allocation, an individual person, rather than a position in an organization,
is allocated to all activity instances of a particular activity model. This
resource allocation is useful in cases where there is exactly one person who is
suitable for performing these activities, such as the chairperson of a company,
who has to finally decide on investments exceeding a certain threshold.
Direct allocation can always be simulated by role-based allocation, discussed
next, simply by providing a role with one member, in our example
the company owner. However, if this property of the organization will remain
stable over a long period of time, introducing a separate role (owner) is not
required, so direct allocation can be used. The limitations of direct allocation
will be discussed in the context of role-based allocation.

Role-Based Allocation

Role-based allocation is the standard way of allocating work to the members of
organizations. It is based on the understanding that all members of a certain
role are somehow functionally equivalent, so that any member of the role can
perform a given unit of work.
To each activity model in a business process model, a is role assigned,
indicating that all members of the role are capable of performing the respective
activity instances. The mapping of role information to specific knowledge
workers is called role resolution. Current information on the availability of the
knowledge worker is used during role resolution.
There are two ways of realizing role-based allocation. In the first way, when
an activity instance enters the ready state, the work item is communicated
to the members of the group. Once one member of the group selects a work
item, the work items associated with the other group members are deleted. In
the second way, only one person is selected to perform the activity instance,
so only one work item is created.
Role-based allocation provides a set of interesting advantages with respect
to direct allocation, all of which are related to enhancing the flexibility of
business processes. Firstly, the business process model does not need to be
changed when there are changes in the personnel, i.e., employees retire and
new employees are hired. When using direct allocation, any change in the personnel related to the directly allocated persons would result in a change in
the business process model.
Secondly, by role resolution at run time of the business process, only available
persons are selected to perform activities. This approach avoids situations
in which persons are selected to perform activity instances that are currently
not available, for instance, due to meetings or absence. In direct role resolution,
when the person is not available, there is no way of continuing the
business process.

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

2009-08-05T14:17:00.001+05:30

Modelling Organization

An important task of a business process management system is the coordination
of work among the personnel of an enterprise. To fulfil this, the system
has to be provided with information on the organizational structures in which
the business process will execute.
As in process modelling and data modelling, the metamodel level
provides the means to express models, in this case organizational models.
Concepts at this level are positions, roles, teams, and relationships between
positions like supervisor. In organization modelling, there are a few formal
rules on how to express organizational structures, as well as notations to express
them.
The general principle behind organization modelling is the resource, an entity
that can perform work for the enterprise. The general concept of resource
subsumes humans and other resources, such as trucks, warehouses, and other
equipment a company requires to fulfil its goals.
Persons are part of an organization, typically a business organization. The
persons in these organizations work to fulfil the business goals of the enterprise.
Each person typically occupies some position, and the duties and
privileges of that person come with the position, not with the person. This allows filling positions according to an overall organizational plan. In addition,
the company can cope better with changes in personnel. Organizational units
are permanent groupings of persons based on their positions. Organizational
teams or project teams are specific organizational units without a permanent
nature.
In order for us to not overload that figure, it contains positions only at the top
levels, the chief executive level and the department level. Departments are
organizational units with a set of member positions.
The link between the organizational structure of an enterprise and the
business processes is accomplished by work items. Work items represent activity
instances to be performed, and work items are associated with knowledge
workers to facilitate their selection by knowledge workers. In particular, when the business process management system determines that a certain activity
instance enters the ready state, a work item is offered to a set of knowledge
workers.
Each work item is associated with exactly one activity instance. The selection
of the process participants is subject to resource allocation mechanisms,
which will be discussed below. When a knowledge worker completes the activity
instance, the business process management system is informed, so that
the process instance can be continued accordingly.
In order to discuss the resource allocation principles, a state transition
diagram of work items is considered, and a relationship of activity instances
to the respective state transitions is provided.
The assignment of process participants to activities in a business process
can be classified by resource patterns. A rich set of resource patterns have
recently been introduced; in this book, the most relevant resource patterns
are discussed.

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

2009-08-02T22:01:00.001+05:30

Workflow Data Patterns

To organize data-related issues in business process management, workflow
data patterns have been introduced. Workflow data patterns formulate characteristics
on how to handle data in business processes. They are organized
according to the dimensions data visibility, data interaction, data transfer,
and data-based routing.
Data visibility is very similar to the concept of scope in programming
languages because it characterizes the area in which a certain data object is
available for access. The most important workflow data patterns regarding
data visibility are as follows.
• Task data: The data object is local to a particular activity; it is not visible
to other activities of the same process or other processes.
• Block data: The data object is visible to all activities of a given subprocess.
• Workflow data: The data object is visible to all activities of a given business
process, but access is restricted by the business process management
system, as defined in the business process model.
• Environment data: The data object is part of the business process execution
environment; it can be accessed by process activities during process
enactment.
Data interaction patterns describe how data objects can be passed between
activities and processes. Data objects can be communicated between activities
of the same business process, between activities and subprocesses of the same
business process, and also between activities of different business processes.
Data can also be communicated between the business process and the business
process management system.
Data transfer is the next dimension to consider. Data transfer can be
performed by passing values of data objects and by passing references to data
objects. These data transfer patterns are very similar to call-by-value and callby-
reference, concepts used in programming languages to invoke procedures
and functions.
In data-based routing, data can have different implications on process
enactment. In the simplest case, the presence of a data object can enable
a process activity. Data objects can also be used to evaluate conditions in
business process models, for instance, to decide on the particular branch to
take in a split node.
Workflow data patterns are an appropriate means to organize aspects of
business processes related to the handling of data.

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec H -- By Mathias Weske

2009-08-02T21:57:00.002+05:30

Modelling Process Data

Business processes operate on data. Explicitly representing data, data types, and data dependencies between activities of a business process puts a business
process management system in a position to control the transfer of relevant

data as generated and processed during processes enactment.

Modelling Data

Data modelling is at the core of database design. The Entity Relationship
approach is used to classify and organize data in a given application domain.
The Entity Relationship modelling approach belongs to the metamodel level. it provides the required concepts to express
data models. Data modelling will be illustrated by a sample application
domain, namely by order management.
In a modelling effort, the most important entities are identified and classified.
Entities are identifiable things or concepts in the real world that are
important to the modelling goal. In the sample scenario, orders, customers,
and products are among the entities of the real world that need to be represented
in the data model.
Entities are classified as entity types if they have the same or similar
properties. Therefore, orders are classified by an entity type called Orders.
Since each order has an order number, a date, a quantity, and an amount, all
order entities can be represented by this entity type. Properties of entities are
represented by attributes of the respective entity types.
The entities classified in an entity type need to have similar, but not identical
structure, because attributes can be optional. If the application domain
allows, for instance, for an order to have or not to have a discount, then the
amount attribute is optional. This means that two orders are classified in
entity type order even if one has a discount attribute while another does not.
Entity types in the Entity Relationship metamodel need to be represented
in a notation by a particular symbol. While there are variants of Entity Relationship
notations, entity types are often represented by rectangles, marked
with the name of the entity type. Other entity types in the sample application domain
are customers and products. The attributes are represented as ellipsoids
attached to entity types.
Entities are associated with each other by relationships. For instance, a
customer “Miller” requests an order with the order number 42. These types of
links between entities are called relationships. Just as there are many customer entities and many order entities, there are many customer-order relationships.
To represent these relationships, a relationship type requests classifies them
all. In Entity Relationship diagrams, relationship types are typically represented
by diamond symbols, connected to the respective entity types by edges.
The complex nature of data in a given application domain can be well
represented by Entity Relationship Diagrams. These diagrams can be used to
create relational database tables, using transformation rules. Once the respective
database tables have been created in a relational database, application
data can be stored persistently. The data can be retrieved efficiently using
declarative query languages, for instance Structured Query Language.
While this discussion focuses on data modelling in the context of database
applications, the same data modelling method can be used to represent data
structures in business process management. Based on these data structures,
data dependencies between activities in business processes can be captured
precisely.
Data modelling is also the basis for the integration of heterogeneous data.
In the enterprise application integration scenarios discussed above, one of the
main issues was the integration of data from heterogeneous data sources. Once
data models are available for these data sources, the data integration problem
can be addressed. There are advanced data integration techniques that also
take into account data at the instance level, but explicit data models in general
are essential to addressing data integration.
Data integration can then be realized by a mapping between the data
types. For instance, there might be applications on top of database systems A
and B, such that these systems have tables CustomerA and CustomerB, respectively,
that differ. For instance, while CName is the attribute of the CustomerA
table, referring to the name of the customer, CustN might be the respective
attribute in the CustomerB table. In order to integrate both tables, the attributes
need to be mapped. In this case, CustomerA.CName is mapped to
CustomerB.CustN.
In data integration projects, complex integration problems are likely to
emerge. There might be attributes that cannot be mapped, but there might
also be attributes that need to be mapped to different tables, often by our
using transformation rules. The hardest set of problems, however, stem from
semantic heterogeneity. There are assumptions on the data that are not explicit
in the data model or in the actual data stored in the database. These
semantic differences can only be taken into account when investigating the
meaning of the attributes in detail, often during interviews with the persons
involved in the data modelling and database design of the systems to integrate.
Semantic specification of data can be used to solve these data integration
problems. However, complete semantic specification of data requires considerable
resources, and the completeness of the semantic specification cannot be
proven automatically. Therefore, further research is required to evaluate the
possibilities of semantics-based data integration.
In graph-based approaches to business process modelling, data dependencies
are represented by data flow between activities. Each process activity is
assigned a set of input and a set of output parameters. Upon its start, an
activity reads its input parameters, and upon its termination it writes data it
generated to its output parameters. These parameters can be used by followup
activities in the business process.
The transfer of data between activities is known as data flow. By providing
graphical constructs to represent data flow between activities, the data
perspective can be visualized and used to validate and optimize business processes.

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec G -- By Mathias Weske

2009-07-31T21:17:00.003+05:30

Process Interactions

Business processes reside in single organizations. Since enterprises cooperate
with each other, it is essential to consider the interaction between enterprises.
Since all activities that an enterprise conducts are part of some business process, the interaction between enterprises can be described by the interaction
of business processes of these enterprises. These interactions typically
occur in a peer-to-peer style, following an agreed-upon process choreography.
These enterprises are reflected by the
respective value chains. Within these value chains are the business functions
realized by the business processes.
The buyer value chain contains an order product business function, and
the reseller value chain contains an order management business function. The
business process models that realize this interaction are shown in Figure 3.21.
The order product business function of the buyer starts by his placing
an order. This placing of an order is realized by a message to the reseller;
the task place order is responsible for sending this message. On the reseller
side, this message is received by a receive order activity. The processes continue
as specified. Since the message flow occurs between multiple activities
in both directions, the value chain level representation of the interacting business
processes—from buyer to reseller—is not complete in the sense that it
does not hold all possible orders of interaction.
Interacting process instances can be visualized adequately by event diagrams.
The distributed nature of interacting processes is represented by introducing
a horizontal line for each participant, on which the events of that
participant appear in an ordered fashion. Participants communicate by send ing and receiving messages. In event diagrams, a one-way message interaction
is represented by a send event, a corresponding receive event, and an arc connecting
the two events. Participants can communicate only by sending and
receiving messages.
It abstracts
from events regarding the initiating, enabling, starting, and terminating of
activities. Instead, it concentrates on message events. Each message send event
is marked by the activity instance during which the send occurs, and each
receive event is marked by the activity instance during which the receive
occurs. It is valid to assume that messages are sent on termination of the
respective activity instance and an arrival of a message triggers the enable
event for the receiving activity instance.

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec F -- By Mathias Weske

2009-07-31T21:14:00.001+05:30

Process Instances

Process models define restrictions on process instances that belong to the
process model. Therefore, it is essential to properly define not only process
models but also process instances. Modelling process instances is not an easy
task, because of their intangible nature. A process instance is started, and it
lives for a limited time period before it ceases to exist, similarly to activity
instances.
A process instance consists of a number of activity instances as well as
event and gateway instances. The ordering relationships of activity instances
in a process instance is defined by the relationships of the activity models in
the process model.
For instance, if a process model defines an execution ordering constraint
between activity models A and B, then for each particular process instance,
the activity instance that belongs to activity model A must have terminated
before the activity instance for B can be started.
An extension of the process metamodel discussed above is presented in Figure
3.17. There are additional classes for process instances and node instances
that are a generalization of activity instances, events, and gateway instances.
There are one-to-many relationships between the respective concepts at the
model level and at the instance level, as shown in the metamodel.
Each process instance is associated with exactly one process model, and
each process model is associated with an arbitrary number of process instances.
Each process instance is composed of an arbitrary number of activity
instances. Each activity instance is associated with exactly one activity model.
The same holds for events and gateways.
Note that each activity model is associated with an arbitrary number of
activity instances. In the case of loops, an activity model is associated with
multiple activity instances. An activity model that lies on a branch that is
not taken during a particular process instance is not associated with any
activity instance, explaining the cardinality of the association * that allows
zero occurrences of the association, i.e., there might be activity models in a
process model for which no activity instances are required for a particular
process instance.
After introducing events and event orderings to represent activity instances,
this section looks at events and event orderings that occur during
the enactment of process instances. Process models restrict for a process instance
the events and event orderings of its activity instances by imposing
execution constraints, such as sequential execution of activity instances. Execution
constraints need to be satisfied by all process instances based on a
particular process model.
The execution constraints can be precisely specified by events and their
ordering. For example, the execution constraint A ! B dictates that the start
event of the activity instance corresponding to B can only happen after the
termination event of the activity instance corresponding to A. This is the
basic idea of characterizing the execution semantics of process instances.
To illustrate these concepts, a process instance based on the process model
shown in Figure 3.15 on page 91 is investigated. Each process instance based
on this process model starts with an analyze order activity. Depending on
a decision, either the simple check activity or the advanced check activity
is enacted. This process model makes room for different process instances.
Depending on the decision made at the gateway node, either the simple check
activity instance or the advanced check activity is executed.
Event diagrams are also useful for capturing process instances. The event
diagram of a particular process instance is shown in Figure 3.18, where a
process instance is shown during which the simple check activity instance is
selected.
When the process starts, activity instances for all three activity models
are generated. In event diagrams, the subscripts of the init, enable, terminate, and skip events can be omitted, if the activity instance to which the event
belongs is clear.
The start event is represented by the event node N1 in the process model.
The occurrence of this event is represented in the event diagram by event n1.
Once this event has occurred, the AnalyzeOrder activity instance can start,
i.e., it can enter the ready state, represented by an enable event.
When the AnalyzeOrder activity instance terminates, (1) the AdvCheck
activity instance is no longer required, so that a skip event occurs for this
activity instance, and (2) the SimpleCheck activity instance is enabled, so
that it can start. When this activity completes, the final event n7 of the
process instance occurs.

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec E -- By Mathias Weske

2009-07-27T17:54:00.002+05:30

Process Models and Process Instances

Business processes consist of a set of related activities whose coordinated execution contributes to the realization of a business function in a technical and organizational environment. Business processes are represented by business process models. Since this section concentrates on the execution ordering of activities, disregarding the technical and organizational environment of business processes, the term process model is used.

Object Facility for the process subdomain. In the M0 layer there are process instances that reflect the actual occurrences of a business process. Each process instance is an instance of a process model in the model layer M1. Process models are described by process metamodels, building the M2 layer. In order to express process models, there needs to be a notation in place that provides notational elements for the conceptual elements of process metamodels. For instance, if the process metamodel has a concept called activity model, then there needs to be a notational element for expressing activity models.

A process notation is associated with the process metamodel level and with the process model level; each process model is expressed in a process notation associated with the process metamodel that describes the process model.

Process Models

In this section, a simple process metamodel is introduced. Rather than being on completeness of modelling constructs, the focus of this section is on providing a well-described process metamodel that can be used to illustrate the core components of any process metamodel. Chapter 4 will look at process metamodels of higher complexity. Any modelling effort starts with identifying the main concepts that need to be represented. In metamodelling, the concepts to be represented are models. The following models are identified as concepts in the metamodel. • Process Model : A process model represents a blue print for a set of process instances with a similar structure. Process models have a two-level hierarchy, so that each process model consists of a set of activity models. Nesting of process models within process models is not represented, because it would introduce complexity that is not required. Each process model consists of nodes and directed edges. • Edge: Directed edges are used to express the relationships between nodes in a process model. • Node: A node in a process model can represent an activity model, an event model, or a gateway model. – Activity Models: Activity models describe units of work conducted in a business process. Each activity model can appear at most once in a process model. No activity model can appear in multiple process models. This stipulation can be relaxed by qualifying activity model identifiers with process model identifiers; to keep the process metamodel simple, this extension is not covered. Activity model nodes do not act as split or join nodes, i.e., each activity model has exactly one incoming edge and exactly one outgoing edge. – Event models: Event models capture the occurrence of states relevant for a business process. Process instances start and end with events, so process models start and end with event models. – Gateway Models: Gateways are used to express control flow constructs, including sequences, as well as split and join nodes.

Each process model contains elements at the model level, for instance, activity models. Process instances consist of activity instances. The model level and the instance level do not hold only for activities, but also for events and gateways. For instance, the start event model in a process model rules that each process instance begins with a start event instance. Since events are by definition singular entities, event instances are also called events.

Control flow in process models is represented by gateway models. As with activities and events, gateways are represented in process models by gateway models. This explicit representation allows our considering gateway instances for process instances. This is very useful, since each gateway model can be used multiple times in a given process instance, for instance, if it is part of a loop. The different occurrences of a given gateway can have different properties. For instance, an exclusive or gateway can in one instance select branch 1 while in the next iteration it can use branch 2. This situation can be represented properly if there are multiple gateway instances for a given gateway model in the context of a given process model. In the example discussed, the first gateway instance would select branch 1, while the second gateway instance would select branch 2.

The next step in modelling concerns the identification and formalization of the relationships between these concepts. Figure 3.14 provides a representation of the concepts and their relationships by a structure diagram, defining a process metamodel. Each process model consists of nodes and edges. The nodes represent activity models, event models and gateway models, while the edges represent control flow between nodes. Each edge is associated with exactly two nodes, relating them in a particular order. Each node is associated with at least one edge. The different types of nodes are represented by the generalization relation. Activity models reflect the work units to be performed, event models represent the occurrence of states relevant for the business process, and gateway models represent execution constraints

of activities, such as split and join nodes.

While the association between nodes and edges are defined at the node

level, the cardinality of the association between special types of nodes (activity

models, event models, and gateway models) differs. Each activity model has

exactly one incoming and one outgoing edge.

Each process starts with exactly one event, the initial event, and ends

with exactly one event, the final event. Therefore, certain events can have

no incoming edges (initial event) or no outgoing edges (final event). Gateway

models represent control flow. Therefore, they can act as either split nodes

or join nodes, but not both. Hence, each gateway model can have multiple

outgoing edges (split gateway node) or multiple incoming edges (join gateway

node).

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec D -- By Mathias Weske

2009-07-27T17:48:00.004+05:30

Activity Models and Activity Instances

Business functions provide a high-level, coarse-grained representation of the work conducted by enterprises. Activities can be found in the leaves of the functional decomposition. This section investigates how activities can be described. In addition, the actual work conducted during business processes has to be characterized, i.e., activity instances have to be characterized. Note that activity models represent the M1 layer of the Meta Object Facility, while the activity instance layer corresponds to M0.

An activity model describes a set of similar activity instances, analogously to a process model describing a set of process instances with the same structure. While process models are typically expressed in graph-like notations (to

be investigated in detail in the next chapter), activity models can be expressed

in different forms, for instance, by plain text or by some formal specification

or references to software components that implement them.

Activity instances represent the actual work conducted during business

processes, the actual units of work. To make this discussion more concrete,

assume a process instance that represents the processing of an insurance claim

by Clara Smith on the damage amount of US $2000, submitted November 11,

2006. Let EnterClaim(Clara Smith, 2000, 11-11-2006) represent the activity

instance responsible for entering the claim in the software systems of the insurance

company. When the company receives the claim, a process instance is

started. Within this process instance, the activity instance EnterClaim(Clara

Smith, 2000, 11-11-2006) is started. When the claim is entered in the system,

this activity instance terminates.

Each activity instance during its lifetime is in different states. These states

and the respective state transitions can be represented by a state transition

diagram. The states

that an activity instance adopts during its lifetime are described as follows:

when it is created it enters the init state. By the enabled state transition the

activity instance can enter the ready state.

If a particular activity instance is not required, then the activity instance

can be skipped, represented by a skip state transition from the not started

state to the skipped state. From the ready state, the activity instance can

use the begin state transition to enter the running state. When the activity

instance has completed its work, the terminate state transition transfers it to the terminated state. When an activity instance is in the terminated or the

skipped state, then it is closed.

The state transition diagram representing the complex behaviour of activity instances is a refinement of the state transition diagram representing their simple behaviour. All state transitions possible in the simple diagram are also possible in the complex state transition diagram. The activity instance is initiated, and it enters the ready state before entering the running state. Finally, the activity instance terminates. However, the substates of the termination state are not represented. The simple diagram does not provide different states for successful and unsuccessful termination. When an activity instance can be started, it enters the ready state. If during the execution of a process instance certain activity instances are currently not available for execution, they can be disabled. Activity instances that are initialized, disabled, or enabled are in the not started state. Once an activity instance is ready, it can be started, entering the running state. Running activities can be temporarily suspended, to be resumed later. An activity instance can terminate either successfully or in failure. Terminated activity instances can be undone, using compensation or transactional recovery techniques. Based on the description of the behaviour of an activity instance, the question now arises on how to capture the actual behaviour of a concrete activity instance, i.e., on how to specify the trace of states and state transitions that the activity instance went through. In this section, events and event orderings are introduced to properly represent the essence of activity instances. The basic idea of using events for representing activity instances is quite simple: each state transition of an activity instance is represented by an event.

These events have a temporal ordering. Based on the state transition diagram for activity instances, each activity instance can be represented by a totally ordered set of events.

The causal ordering of events indicated by this definition can be graphically represented by event diagrams. In event diagrams, time proceeds from left to right, and events are shown as bullets. The causal relationships of events are represented by directed arcs. Due to the nature of event diagrams, they form directed acyclic graphs, where the nodes are events and the edges reflect causal ordering between events.

In the event diagram shown in part (a) of that figure, an activity instance that is properly executed is shown, while (b) shows the events of a skipped activity instance. To illustrate the relationship between state transition diagrams and event diagrams, each state transition ito the state transition diagram is associated with an event in the respective event diagram. The activity instance starts with a state transition to the init state. This state transition is represented by an initialize event in the event diagram. An enable state transition brings the activity instance in the ready state; this state transition is represented by an enable event. An activity instance in the ready state can be started, represented by the begin state transition. Finally, the terminate state transition completes the activity instance. Events are points in time, i.e., events do not take time. The time interval in which an activity instance is in one state is delimited by two events, the event representing the state transition to enter the state and the event representing the state transition to leave the state. For example, the time interval in which

the activity instance is in the running state is delimited by the begin and

terminate events.

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec C -- By Mathias Weske

2009-07-24T20:16:00.002+05:30

Vertical Abstraction

Vertical abstraction in business process modelling is depicted in Figure 3.3, where distinct modelling subdomains are identified. As depicted, process modelling is at the centre of the modelling effort, because it also integrates the modelling efforts that are conducted in the other subdomains.

Function modelling, data modelling, organization modelling, and modelling of the operational information technology landscape are required to provide a complete picture of a business process. While these subdomains are the most important ones, additional subdomains can be defined if they are relevant. The functional model investigates the units of work that are being enacted in the context of business processes. The specification of the work can be done at different aggregation levels, from coarse-grained business functions to finegranular functions at the operational level that are realized by knowledge workers and information systems.

The specification of these functions can be informal, using English text or formal, using syntactic or semantic specifications of functions. While informal descriptions are mostly done at the coarse business level, more precise speci- fications are required in the software layer when it comes to implementation of certain functions using information systems. The investigation and proper representation of data in business processes is important, because decisions made during a business process depend on particular data values. Also data dependencies between activities need to be taken into account in process design, to avoid situations in which a function requires certain data not available at that time. The proper representation of the organizational structure of a company is an important requirement. Activities in the business process can then be associated with particular roles or departments in the organization. Many activities in a business process are performed by or with the assistance of information systems. The operational information technology landscape, i.e., the information systems, their relationships, and their programming interfaces, needs to be represented to use the functionality provided by the information systems. Process modelling defines the glue between the subdomains. A process model relates functions of a business process with execution constraints, so that, for instance, the ordering and conditional execution of functions can be specified. Data aspects are covered because particular process instances may depend on the structure and value of data involved in a particular business process. For example, in a credit approval business process, the type of approval depends on the credit amount requested. In addition, data dependencies between activities need to be taken into account in process model design.

From Business Functions to Business Processes

Value chains provide a high-level organization of the functions that an enterprise performs. To provide a more detailed view, these top-level business functions are broken down to functions of smaller granularity and, ultimately, to activities of operational business processes. Functional decomposition is the technique of choice. A partial functional decomposition of a value chain is shown in Figure 3.4, where a value system represents the highest level of aggregation.

The ordering of the value chains in the value system is not represented in this structure diagram because it does not have any formal meaning. There are complex interactions between these companies, so that, obviously, not all activities in the supplier value chain occur before all activities conducted by enterprise E.

The functional decomposition of the value chain of enterprise E is exemplified for one particular path of functions in the marketing and sales top-level business function. Among many other functions, marketing and sales includes a business function, OrderManagement, that contains functions related to the management of incoming orders. Order management is decomposed further into business functions for getting and checking orders. To check orders, they need to be analyzed, and there are functions for simple and advanced checking of orders. There are different symbols for business functions and for functions of the finest granularity: business functions are represented by rectangles, while functions of the finest granularity are represented by rectangles with rounded corners. Functions at the leaf level of the functional decomposition are also called activities. Traditionally, functional decomposition was used to describe enterprises based on the functions they perform. As discussed in Chapter 1, concentrating on the functions an enterprise performs and neglecting their interplay falls short of properly representing how enterprises work. Therefore, functional decomposition is used as first step in the representation of enterprises based on business processes.

Operational business processes relate activities to each other by introducing execution constraints between them. In principle, relating functions to business processes can be applied for different granularities of business functions. In case high-level business functions are considered, a textual specification of the process is used, since concrete execution constraints between their constituents are not relevant in coarse-grained business functions. Consider, for instance, the business functions incoming logistics and operations. At this very coarse level of functionality, no ordering of these business functions is feasible: both business functions are performed concurrently, and only at a lower level of granularity does a concrete ordering make sense. For instance, when the operations business function orders additional material, then there are concrete activities that have a concrete ordering. Within operations, an internal order is created and sent to incoming logistics. On arrival of this order, raw material is provided to operations. In case no raw material is available at the manufacturing company, an external order is created and sent to a supplier of the raw material. Therefore, business processes relate fine-grained business functions, typically the leaves of the business function decomposition tree.

The sample business process starts with analyzing the order, and then conducting either a simple check or an advanced check depending on the decision made during process execution. This process has a dedicated start event and a dedicated end event. The business process is started once the start event occurs; when it completes, an end event occurs. Events play a crucial role when interrelationships between business processes are expressed. A particular business function of higher granularity (CheckOrder) consists of fine-grained activities, which are related by execution constraints. However, the check order business function (and the business process that realizes it) is related to other business functions and their respective business processes. An example showing this situation is displayed in Figure 3.6, where a part of the value chain is shown, in particular, the business functions Receive Request, Request Analysis, and Quota Management are shown. Since there is a strict ordering between these business functions, an execution ordering relation is represented.

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec B -- By Mathias Weske

2009-07-24T20:14:00.002+05:30

Abstraction Concepts

To capture the complexity in business process management, different abstraction concepts are introduced. A traditional abstraction concept in computer science is the separation of modelling levels, from instance level to model level to metamodel level, denoted by horizontal abstraction. Horizontal abstraction concepts in business process management are discussed in Section 3.2.1. Even when using horizontal abstraction, separate subdomains need to be investigated. In order to follow the divide-and-conquer approach, these subdomains need to be represented separately. This abstraction mechanism is called vertical abstraction, and is discussed in Section 3.2.2. Aggregation can also be used to cope with complexity, motivating another type of abstraction. At a higher level of abstraction, multiple elements of a lower level of abstraction can be grouped and represented by a single artefact. For example, a set of functional activities of small granularity can contribute to a particular business function at a higher level of granularity: a coarse-grained business function “order management” might aggregate many smaller-grained activities, like receiving an incoming order, checking the inventory, and con- firming the order. This type of abstraction is called aggregation abstraction, because the coarse-grained business function aggregates activities of smaller granularity. Aggregation abstraction is different from horizontal abstraction, because all activities (the small-grained and the coarse-grained) are at one horizontal level of abstraction, e.g., the instance level. Aggregation abstraction is primarily used in the functional subdomain, where functions of smaller granularity are combined to create functions of larger granularity.

Horizontal Abstraction

Along the lines of the levels of abstraction identified by the Object Management Group, the metamodel level, the model level, and the instance level play important roles in the design and analysis of complex systems in general and software systems in particular. It is instructive to explain these levels in a bottom-up order, starting with the instance level. The instance level reflects the concrete entities that are involved in business processes. Executed activities, concrete data values, and resources and persons are represented at the instance level. To organize the complexity of business process scenarios, a set of similar entities at the instance level are identified and classified at the model level.

For instance, a set of similar business process instances are classified and represented by a business process model. In object modelling, a set of similar entities is represented by a class, and in data modelling using the Entity Relationship approach, a set of similar entities is represented by an entity type, and similar relationships between entity types are represented by a relationship type.

Models are expressed in metamodels that are associated with notations, often of a graphical nature. For instance, the Petri net metamodel defines Petri nets to consist of places and transitions that form a directed bipartite graph. The traditional Petri net notation associates graphical symbols with metamodel elements. For instance, places are represented by circles, transitions by rectangles, and the graph structure by directed edges. In data modelling, the Entity Relationship metamodel defines entity types, relationship types, and connections between them. Typical graphical notations of the Entity Relationship metamodel are rectangles for entity types and diamonds for relationship types, connected by lines. While often there is one graphical notation for one approach, a one-to-one correspondence between notation and metamodel is not mandatory. In a Petri net, the concept of a transition could also be represented by another symbol in a graphical notation. There are different notations for representing Petrinets, which differ in the graphical representation of transitions. While some

use rectangles, others use solid bars.

Therefore, it is important to distinguish between the concepts of a modelling

approach and the graphical notation used to represent these concepts.

The complete set of concepts and associations between concepts is called metamodel.

A metamodel becomes useful if there is a notation for this metamodel

that allows expressing models in a convenient way that allows communication

between stakeholders in the modelled real-world situation.

The different levels of abstraction and their relationships are shown in

Figure 3.2. A notation associated with a metamodel allows expressing the

concepts of that particular metamodel. Each model is described by a metamodel,

and is expressed in a notation associated with the metamodel.

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec A -- By Mathias Weske

2009-07-22T19:54:00.002+05:30

Conceptual Model and Terminology

While the terms mentioned have been used in the previous chapters informally, the concepts behind these terms and their relationships will now be discussed in more detail, using conceptual
models. These models are expressed in the Unified Modeling Language, an
object-oriented modelling and design language.
Business processes consist of activities whose coordinated execution realizes
some business goal. These activities can be system activities, user interaction
activities, or manual activities. Manual activities are not supported by
information systems. An example of a manual activity is sending a parcel to
a business partner.
User interaction activities go a step further: these are activities that knowledge
workers perform, using information systems. There is no physical activity
involved. An example of a human interaction activity is entering data on an
insurance claim in a call centre environment. Since humans use information
systems to perform these activities, applications with appropriate user interfaces
need to be in place to allow effective work. These applications need to
be connected to back-end application systems that store the entered data and
make it available for future use.
Some activities that are conducted during the enactment of a business
process are of manual nature, but state changes are entered in a business
process management system by means of user interaction activities. For instance,
the delivery of a parcel can be monitored by an information system.
Typically, the actual delivery of a parcel is acknowledged by the recipient
with her signature. The actual delivery is important information in logistics
business processes that needs to be represented properly by information systems.
There are several types of events during a logistics process. These events
are often available to the user as tracking information. While the activities
are of manual nature, an information system—the tracking system—receives
information on the current status of the process.

System activities do not involve a human user; they are executed by information
systems. An example of a system activity is retrieving stock information
from a stock broker application or checking the balance of a bank
account. It is assumed that the actual parameters required for the invocation
are available. If a human user provides this information, then it is a user
interaction activity. Both types of activities require access to the respective
software systems.
Certain parts of a business process can be enacted by workflow technology.
A workflow management system can make sure that the activities of a business
process are performed in the order specified, and that the information systems
are invoked to realize the business functionality. This relationship between
business processes and workflows is represented by an association between
the respective classes. We argue that workflow is not a subclass of business
process, since a workflow realizes a part of a business process, so a workflow
is not in an “is-a” relationship with a business process, but is an association.
With regard to the types of activities mentioned, system activities are associated
with workflows, since system activities can participate in any kind
of workflow, system workflow or human interaction workflow. User interaction
activities and manual activities, however, can only participate in human
interaction workflows.

Business Process Management (Part-1 Foundation[Chapter II Evolution of Enterprise Systems Architectures ] ) Sec M -- By Mathias Weske

2009-07-22T19:49:00.003+05:30

Enterprise Services and Service-Oriented Architectures

The roles in service-oriented architectures as discussed above are not completely
filled in typical enterprise scenarios. The specification of services is
typically done by the provider of the service, i.e., by the system architects
responsible for service-enabling the particular application.
The service registry is installed locally, and its access by other companies
is usually disallowed. The most striking difference to service-oriented architectures
as defined by Burbeck is the absence of dynamic matchmaking. As
enterprise services are developed, they are specified and registered in a local
registry. When a new composite application is developed, the designers consult
the registry to find suitable services that can be used to perform certain
tasks in the composite application. This search is a manual process, which in
some cases is assisted by a taxonomy and a textual description of the services.
There are a number of hard problems in this context that are unsolved
today. One of the main problems regards the scoping of services: the functionality
provided by one or more application systems that is suitable for an
enterprise service. If the granularity is small, then the level of reuse is small
too, because many enterprise services need to be composed to achieve the
desired functionality.
If on the other hand the granularity is large, then there might be only
few scenarios where the enterprise service fits well and where using it makes
sense. Tailoring of services of large granularity is also not a valid option, since
extensive tailoring hampers reuse. As in many related cases, there is no general
answer to this question. The choice of a suitable service granularity depends on
the particular usage scenario and on the properties of the application systems
to integrate and the composite applications to develop.
In enterprise services architectures, each enterprise service is typically associated
with exactly one application system. This is a limitation, since building
an enterprise service on top of a number of related back-end application
systems involves system integration, so that reuse is simplified.
To illustrate this concept, an example is introduced. Consider a purchase
order enterprise service in which an incoming purchase order needs to be stored
in multiple back-end application systems. In this case, the enterprise service
can be used with ease, since it is invoked once by a composite application and
it automatically provides the integration of the back-end system by storing
the purchase order—with the relevant data mappings to cater to data type
heterogeneity—in the respective back-end application systems.
An integration of legacy systems can be realized within an enterprise service.
This allows using enterprise services at a higher level of granularity, so
that integration work can actually be reused in multiple composite applications.

Enterprise Services Bus

In a recent development, enterprise application integration middleware provides
standardized software interfaces to the enterprise applications that it
integrates. As the term enterprise service bus indicates, each of these enterprise applications is then attached to this bus, which acts as a centralized component to integrate these applications
An enterprise service bus hides the heterogeneity of the enterprise applications
by introducing service interfaces. To realize these service interfaces,
traditional enterprise application integration adapter technology is typically
used that is also in place in traditional enterprise application integration middleware,
as discussed in Section 2.2.2.
By introducing standardized interfaces to the outside world using services,
however, an enterprise service bus goes one step beyond traditional enterprise
application integration middleware. It must not be overlooked, however, that
the term enterprise service bus is also used by software vendors to rebrand
existing technologies for marketing reasons.

Service Composition

To realize composite applications in service-oriented enterprise computing environments,
service composition techniques are appropriate. The general principle
of service composition is depicted in Figure 2.25, where application systems
in the lower part of the figure represent services that can be used to
realize composite applications.
The composite application shown uses functionality provided by a CRM
system, an SCM system, and an ERP system. The application logic realized
in the composite application defines a process consisting of three activities.
The ordering of these activities can be specified in a process model.
Since the business process is realized by a composition of services, processes
of this kind are also called service compositions.
Enterprise application integration middleware in general and enterprise
service bus middleware in particular provide a good technical basis to realize
service compositions, because they provide standardized services interfaces
that can be used in service compositions. Typical enterprise application integration
middleware features a system workflow component that uses either a
proprietary format for system workflows or, if it is based on services, the Business
Process Execution Language for Web services.

Business Process Management (Part-1 Foundation[Chapter II Evolution of Enterprise Systems Architectures ] ) Sec L -- By Mathias Weske

2009-07-20T20:46:00.001+05:30

Enterprise Services

In enterprise computing environments, the functionality of application systems can be described and provided by services. Figure 2.22 visualizes a serviceenabled application system. The functionality of the application system is provided through services, depicted by semicircles on top of the application system. Services need to be specified in a way that the specification of services is decoupled from their implementation. Detailed specification of services facilitates

the flexible configuration of services by composing services to achieve

complex functionality.

In an existing application built with several services provided by different

business partners, the partners can modify the realization of their services, as

long as the service specification does not change. Based on the service specification,

an improved service implementation can be integrated seamlessly in

a service-based application. New potential business partners can use publicly

available service specifications to offer their own implementations of the services.

As a result, individual parts of a complex service-based application can

be exchanged without redesigning the application.

Service orientation is also one of the main influencing factors for enterprise

application integration. Enterprise services architecture characterizes the development

of added-value applications that take advantage of existing functionality

provided through standardized interfaces.

Enterprise services architecture is based on the understanding that complex

applications will be increasingly built on top of existing functionality.

This functionality is provided by legacy systems, which are an important asset

of companies. Making this functionality reusable is a challenging task. The

idea is to encapsulate the functionality of existing software systems in a service,

realizing enterprise services. Enterprise services can be used to realize

enterprise application integration scenarios.

As pointed out by Woods, there are a number of business drivers that

foster the development of enterprise services. The main driver is change: the

ability to change the enterprise application system infrastructure is a competitive

advantage for an enterprise. There are a number of current trends that

motivate the development of enterprise services:

• Rise in the power of the customer: Value-added services are essential, because

customers can change suppliers easily, without much effort. Positive

user experience is important, as the success of online auctioning sites and

online shops with community building indicates.

• Systems transparency: The Internet has brought customers and suppliers

inside a company’s IT infrastructure. Weak or missing integration of enterprise

application systems will be immediately exposed to the customer.

• Rise in computer mediated interaction with customers and suppliers: Companies

differentiate themselves on their service to their customers. Dan

Woods indicates that “Outsiders can now peer into the glass house of the

data centre and see if it is a mess.” An example of a messy situation is

one where a customer cannot be serviced well, because the client interface

provides information only about one aspect of the customer, and the

other aspects are hidden in application systems that are not accessible.

Due to lack of integration, this valuable information is not available, so

the customer does not feel well cared for.

• Products as services: Corporations are increasingly perceived by the set

of services they provide. These services exposed to the market can be

realized by enterprise services, which provided by the back end application

systems of the enterprise. But also services provided by third parties can

be integrated, so that better applications and end user services can be

provided to the customer.

• Multi-tier applications: There is also a trend towards multi-tier applications,

where each tier is provided by a different enterprise. This means that

the tier 1 company provides value-added services directly to a customer,

using the tier 2 services from a set of business partner companies. These

companies might use tier 3 services provided by other companies. By flexible

integration based on the service paradigm, many new applications and

services can be realized.

Composite Service-Based Applications

With this background in enterprise services architectures, an intra-company scenario is sketched, where new applications should be built on top of an existing customer relationship management system, a supply chain management system, and an enterprise resource planning system. These systems expose enterprise services via standardized interfaces. The applications built on top are known as composite applications, as shown in Figure 2.23. Composite applications invoke enterprise services that provide the functionality of the underlying back-end systems. User interaction is realized by dedicated graphical user interfaces that sit on top of composite applications. Technological advance has paved the way for enterprise services. The main cornerstones of these developments are the full suites of enterprise applications that are available off-the-shelf today. There are rich middleware and enterprise application integration products that can be used for technical integration, most of which host a dedicated workflow component for process enactment. To integrate multiple application systems, data transformation is essential. With the advent of the extensible markup language (XML), there is an industry standard for data and message format specifications. While this base technology is in place, the integration logic still needs to be defined and

implemented in each integration project.

Processes are a key factor in realizing composite applications, because they provide a link from high-level business processes to the information technology layer. The structure of composite applications can in many cases be expressed as a business process. The activities of these processes are implemented by invoking enterprise services. Additional execution constraints like conditional execution can be represented by business process models; these can be realized by process orchestrations. Enterprise services can also be used to realize business interactions of multiple enterprises. In multi-tier scenarios for realizing innovative applications, interactions between the software systems of the business partners involved are required. These interactions are governed by a process choreography. Process choreographies have been defined informally above; they are subject of further investigation in Chapter 5. While the vision for enterprise services includes business-to-business processes, most enterprise services today are used in an intra-company setting, where the goal is to develop composite applications on top of well-specified business functionality represented by enterprise services.

Business Process Management (Part-1 Foundation[Chapter II Evolution of Enterprise Systems Architectures ] ) Sec K -- By Mathias Weske

2009-07-20T20:44:00.001+05:30

Enterprise Services Computing

Service-oriented computing is one of the major trends both in business engineering and software technology. The main idea of service orientation is to capture business relevant functionality as a service and provide sufficiently detailed information so that customers can use it. This definition of service orientation goes well beyond services that are realized by software systems. Consider a real-world service, for example, one to fix a car. The service the garage provides needs to be specified in a way that the customer can find and use. Once the car is fixed, the customer pays the bill and the service is completed. There are specific registries for finding real-world services, for instance, yellow page directories. This general idea of service orientation is applied to services provided by software systems. The requirements that apply to real-world services also need to be satisfied for services realized by software systems. Service-oriented computing uses well-specified service interfaces that rely on common interface definition languages to combine several services to new service-oriented applications. If service-oriented computing is used in largescale environments, an organizing principle is useful; this principle is introduced by service-oriented architectures, discussed next.

Service-Oriented Architectures

Steve Burbeck, one of the early advocates of service-oriented architectures, defines service-orientation as follows. Services are loosely-coupled computing tasks communicating over the internet that play a growing part in business-to-business interactions. [...] We reserve the term service-oriented for architectures that focus on how services are described and organized to support their dynamic, automated discovery and use. We do not address systems based on manually hardwired interactions, such as those used in EDI systems. In this definition, services communicate over the Internet. This means that services are expected to be used in business-to-business scenarios, where the participants are connected by the Internet. Although not explicitly ruled out, services that are provided and used within a company do not fully qualify in Burbeck’s definition. The second interesting aspect of this definition is the high degree of flexibility provided by late, run time finding and binding of services. Matching a service request to a set of service specifications in a service registry is a complex task, especially if automated discovery and use are sought, as implied by the definition. Burbeck’s definition mirrors the long-term vision of service-oriented architectures. But this architectural style is not only useful in Internet settings, where the services are provided by different organizations in businessto- business scenarios, but also in intracompany settings. Therefore this book adopts the following definitions. Definition 2.7 A service captures functionality with a business value that is ready to be used. Services are made available by service providers. A service requires a service description that can be accessed and understood by potential service requestors. Software services are services that are realized by software systems. Service-oriented architectures are software architectures that provide an environment for describing and finding software services, and for binding to services. Descriptions of software services provide a level of detail that facilitates service requestors to bind to and invoke them. Service-oriented architectures are especially important in environments where many services are available and where the set of available services changes over time. Burbeck investigates this aspect in more detail and states as follows. To work easily, flexibly, and well together, services must be based on shared organizing principles that constitute a service-oriented architecture.

In a service-oriented architecture, organizations may use services offered by other companies, and companies may provide services to a growing services market. The vision is for information systems to use business functionality of service providers, so that reuse of functionality is realized at a level of coarse granularity. New applications can be built with less effort and existing applications can be efficiently adapted to changing requirements, reducing maintenance and development cost.

To enable service requestors to find and use them, they are specified, and their descriptions are stored in a service registry. The interactions between the three primary roles in service-oriented architecture are publish, request/reply, and bind. The service provider publishes service specifications in a service registry, and the service requestor searches the service registry and finds suitable services. The service registry provides the service requestor with information that allows the service requestor to bind to the service and, eventually, invoke it.

Business Process Management (Part-1 Foundation[Chapter II Evolution of Enterprise Systems Architectures ] ) Sec J -- By Mathias Weske

2009-07-19T09:37:00.001+05:30

Challenges for Workflow Management

As discussed in the previous sections, workflow management has considerable benefits due to explicit process representation and process enactment control. However, workflow management has also spawned criticism that has led to a broader perspective in business process modelling, organization, and control realized by business process management.

Lack of Adequate Support for Knowledge Workers

In contrast to many developments in software architecture and technology, workflow management systems have massive effects on the daily work for their users. The method of data storage and whether the program was developed with a procedural programming language or an object oriented programming language are relevant only for system designers and developers; these implementation aspects do not matter for the users of these systems. Therefore, special care has to be taken in the rollout of workflow applications; early participation of users in the design of these systems is important to avoid user acceptance issues. Workflow management systems represent not only processes but also the organizational environment in which these processes are executed. This means that persons are represented by their skills, competences, and organizational positioning. This information is used to select persons to perform certain activities. The active selection of persons by the workflow management system has not been considered appropriate, since human workers felt that a machine burdened them with additional work. This feeling might also be due to crude interfaces of early workflow management systems. The role of knowledge workers is another area where traditional workflow management systems scored low. Workflow models prescribe the process flow, and a workflow management system makes sure that the workflow is performed just as it is described. This also means that there is little room for creativity for the knowledge worker. Any process instance that has not been envisioned by the process designer cannot be realized. This might lead to situations where certain parts of the overall business process are not handled by the workflow management system. Sometimes, even paper-based solutions were used by the knowledge workers, leading to inconsistent states in the overall process.

Technical Integration Challenges

While system workflows are well equipped to support the process aspect of enterprise application integration scenarios, the same technical integration problems need to be solved in system workflow projects as those in traditional enterprise application integration projects. Application systems that need to be integrated are typically not equipped with well-documented interfaces that can be used to get hold of the required functionality. Functionality of application systems might also be implemented in the graphical user interfaces, so that low-level implementation work is required to access the application system functionality. Another important source of trouble is relationships between different applications at the code level. Direct invocation between software systems is an example of these relationships, so that an invocation of an application system automatically spawns off an invocation of another application system. In these settings, the overall process flow is in part realized at the application code level, so that the workflow management system is capable of controlling only parts of the actual process flow, but not the complete process. The granularity of the workflow activities and the granularity of the functionality provided by the underlying application systems might be different. Fine-granular business activities might have been designed in the process model that cannot be realized, because the underlying application system only provides coarse-grained functionality. In some cases, the interface to the application can be modified so that fine-grained functionality is available. This alternative is likely to incur considerable cost, or it might be impossible for some applications. Another alternative is changing the granularity of the business activities. In this case, certain properties of the process might not be realizable—for instance, the concurrent execution of two fine-granular activities. As a result, the run time of the workflow will not be optimal. Service-oriented architectures and service-enabling of legacy applications are important concepts currently being investigated to address these technical problems.

Process Support Without Workflow Systems

Not all environments ask for a workflow management system. In cases where no changes to the process structure are envisioned, a coding of the process flow can be an attractive and adequate choice. In database administration there are predefined procedures that are enacted following a process model. Similar developments can be found in publishing environments where print workflow is a common tool to describe and perform the steps that lead to publishable results. Most enterprise resource planning systems feature a dedicated workflow component that allows us to model new processes and enact them in the system environment. Due to their close link to particular applications, these systems are also called embedded

workflow management systems.

Business processes are also realized in online shops, such as train reservation

systems or electronic book stores, where steps of an interaction process

are depicted in graphical form. This graphical representation guides the user

in his interaction with the Web site. In a train reservation online shop, for

instance, there are interaction steps for querying train connections, for getting

detailed information on the connections, for selecting connections, for

providing payment information, and for booking and printing the train ticket.

Since this type of interaction process can easily be realized using traditional

Web page design, workflow management systems are not required. However,

these examples show that the business process paradigm is helpful also in

application scenarios that do not require dedicated workflow support.

Enterprise application systems, such as enterprise resource planning systems,

realize literally thousands of business processes. These processes can be

customized to fit the particular needs of the company that runs the system. In

most cases, the business processes are realized within the system, so no integration

issues emerge. If the predefined business processes cannot be tailored

in a way that fits the needs of the company, then integrated process modelling

functionality can be used to model new processes

Business Process Management (Part-1 Foundation[Chapter II Evolution of Enterprise Systems Architectures ] ) Sec i -- By Mathias Weske

2009-07-19T09:34:00.001+05:30

Human Interaction Workflows

In order to introduce human interaction workflows, it is useful to discuss its development. An early predecessor of human interaction workflow management systems is the office automation system, developed in the early 1980s. The goal of these systems was supporting the organization and the collaboration of work involving multiple persons. Until then, supporting office work of individuals was at the centre of attention. It turned out that it is not sufficient to equip workers with adequate software for their individual workplace, but also to consider the relationship of the work activities that are performed by different workers and provide support for their collaboration. By shared, consolidated data repositories and by improving the handover of work between employees, a considerable speed-up in office procedures could be realized. However, the scope of office automation was still quite narrow: workers of a given organization process information objects, primarily using forms-based applications. Today, human interaction workflows typically realize parts of a larger business process that has automated as well as nonautomated parts. The goal of human interaction workflows is to effectively support the automated parts of business processes by actively controlling the activities performed according to process models. Definition 2.6 Workflows in which humans are actively involved and interact with information systems are called human interaction workflows. Workflow management systems also take into account the organization in which the process runs. In particular, for each step in a workflow process, the role responsible for executing is defined. Roles are groups of employees that qualify for this responsibility. The role concept introduces an additional type of flexibility, because at run time of the workflow, a person currently available can be offered to work on the respective activity, and one of the persons can select the activity to actually start working on it.

Goals attributed to human interaction workflows are reduction of idle periods, avoiding redundant work such as the entering of data multiple times by different knowledge workers, and improved integration of human work with underlying information systems. In addition to the activities and their logical ordering in a process model, the information system required to enact the workflow for each activity is represented. This information is required, since the workflow management system at run time will invoke these applications and will feed the required process data to these applications. In the workflow at hand, first an order is stored in an order management system. Then the inventory is checked to find out whether the order can be fulfilled. To keep the process simple, the process design assumes that the order can be fulfilled, i.e., there is no alternative modelled if this is not the case. Then, concurrently, the shipment is prepared, the parcel is handed to the shipper, and the invoice is prepared and sent. The fulfilled order is archived, completing the human interaction workflow. Human interaction workflows require particular graphical user interface concepts. The main concept is the work item list. Knowledge workers interact with the system using work item lists, which are also called in-baskets. Whenever a knowledge worker can perform a process activity, he or she is informed by an item in his or her work item list. When the item is selected, the respective application is started, and the input data is provided. When the activity is completed, the knowledge worker informs the workflow application. The workflow management system then computes the current state and determines the activities next due.

Business Process Management (Part-1 Foundation[Chapter II Evolution of Enterprise Systems Architectures ] ) Sec H -- By Mathias Weske

2009-07-17T20:16:00.002+05:30

Workflows and Applications

Traditionally, application systems are designed and implemented not only
by coding functions that the application carries out, but also by coding the
ordering of these functions, i.e., the process logic realized by the application.
With growing complexity of the application systems and increasing demand
for adapting application systems to new requirements, the coding of
process logic in applications has a severe drawback: any modification of the
process realized by the application requires a modification of the programming
code. The code not only needs to be modified, but also tested and maintained,
so that each modification consumes considerable resources.
Workflow management technology can be used to ease the modification of
the process logic realized by applications. The functions of an application system
are the steps in the workflow, and a workflow component uses a workflow
model to enact the functions. By modification of the process logic specified
in workflow models, the behaviour of the application system can be modified
without coding.
Today, most enterprise application systems, such as enterprise resource
planning systems, host a workflow component that facilitates the flexible customization
of business processes within these systems. Observe that instead of
the term workflow management system the term workflow component is used,
because a workflow component is not a stand-alone software system; rather,
it is embedded in the application.
Definition 2.4 A single-application workflow consists of activities and their
causal and temporal ordering that are realized by one common application
system. Multiple-application workflows contain activities that are realized by
multiple application systems, providing an integration of these systems.
There is a dedicated workflow component that is fed with workflow
models that capture the process logic as well as technical execution information.
The workflow component uses functions realized by the application and
provides processes to the higher level, the graphical user interface.
In the case of multiple-application workflows, a dedicated workflow management
system makes sure that the application systems are invoked as specified
in the process model. In addition, data transfer between application
systems is also taken care of by the workflow management system.
The relationships of the subsystems involved in a workflow application
are shown in Figure 2.18. The integration of the application systems is performed
by the workflow management system, using adapters similar to those
used in traditional enterprise application integration scenarios.

System Workflows

In system workflows, the workflow activities are performed automatically by
software systems. Therefore, knowledge workers do not interact with the application, and graphical user interfaces in general and work item lists in particular
are not required. The execution constraints are specified in a process
model, and the workflow management system makes sure that the ordering of
calls to the software systems is in line with the process model.
Figure 2.19 shows a scenario of a system workflow, with a dedicated workflow
management system that invokes for each activity a defined application
system. Each of these software systems provides an interface that the workflow
management system can use, similar to the adapter in the enterprise
application integration scenario sketched above. The workflow management
system behaves like a centralized hub in an enterprise application integration
scenario, but with explicit process representation and enactment control.
Definition 2.5 A system workflow consists of activities that are implemented
by software systems without any user involvement.
Enterprise application integration scenarios are typical candidates for system
workflows. The design and implementation of system workflows can be
regarded as a type of high-level programming, where functionality provided
by application systems characterize the building blocks that are organized
within a system workflow.
In enterprise application integration platforms without a dedicated process
component, the interaction between the application systems is represented by
rules, which are used to forward messages based on their type or content.
From these rules, the overall process structure cannot be derived easily, and realizing change is cumbersome, because rules might trigger other rules, so
that undesired side effects can occur.
Process modelling techniques can be used to provide an explicit representation
of the relationships between enterprise applications. Process models
provide the conceptual basis for defining when and under which conditions
enterprise applications are actually invoked in the context of an integration
scenario.
Therefore, a dedicated process component responsible for modelling and
enacting processes in enterprise application integration scenarios is adequate.
Workflow management systems are well equipped to act as this component.
Today, most enterprise application integration middleware systems host a dedicated
workflow component.

Business Process Management (Part-1 Foundation[Chapter II Evolution of Enterprise Systems Architectures ] ) Sec G -- By Mathias Weske

2009-07-17T20:14:00.002+05:30

Business-to-Business Processes

The business motivation behind interacting business processes stems from
value systems, which represent collaborations between the value chains of
multiple companies. These high-level collaborations are realized by interacting
business processes, each of which is run by one company in a business to
business process scenario. This section studies interactions between business
processes performed by different companies.
For the sake of concreteness, this section uses an example from the area of
order processing, described as follows. A buyer orders goods from a reseller,
who acts as an intermediary. The reseller sends a respective product request to
a manufacturer, who delivers to product to the buyer. In addition, the reseller
asks a payment organization to take care of the billing.
There are many interesting issues to study: how do we make sure that the
business-to-business process created by putting together a set of existing business
processes really fulfils its requirements? Structural criteria, for instance,
absence from deadlock, need to be valid for these processes.
The problem is aggravated by the fact that internal business processes are
an important asset of enterprises. Therefore, few enterprises like to expose
their internal processes to the outside world. This means that the properties of the overall business-to-business collaboration cannot be based on the actual
detailed local processes run by the enterprises, but rather on the externally
visible behaviour and the associated models to represent it.

Workflow Management

The developments in enterprise software architectures and in organizationlevel
business process management laid out in the previous sections led to
workflow management. The important achievement of workflow management
is the explicit representation of process structures in process models and the
controlled enactment of business processes according to these models.
The model-driven approach facilitates a high degree of flexibility, because
process models can be adapted to fulfil new requirements, and the modified
process models can immediately be used to enact business processes.
In the 1990s, the Workflow Management Coalition (WfMC) was founded
to bundle workflow related activities by vendors, users, and academia. The Workflow Management Coalition defines workflows and workflow management
systems as follows.
Definition 2.2 Workflow is the automation of a business process, in whole
or in part, during which documents, information, or tasks are passed from one
participant to another for action, according to a set of procedural rules.
Definition 2.3 A workflow management system is a software system that
defines, creates, and manages the execution of workflows through the use of
software, running on one or more workflow engines, which is able to interpret
the process definition, interact with workflow participants, and, where
required, invoke the use of IT tools and applications.
Workflow technology is capable of supporting business processes within a
given application system or between a set of application systems, effectively
integrating these systems. But workflow technology can also be used to enact
business processes in which humans are actively involved, thus improving the
collaboration between knowledge workers.