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.