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.
Thursday, October 22, 2009
Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec A -- By Mathias Weske
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.
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.
Thursday, October 15, 2009
Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec Z -- By Mathias Weske
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.
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
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.”
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.”
Sunday, October 4, 2009
Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec X -- By Mathias Weske
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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.
Subscribe to:
Posts (Atom)
