Workflow Modelling

um-srv01.wiwinf.uni-due.de

Foundations - Workflow Modelling WfMC and Workflow Specification Languages | XML Process Definition Language (XPDL) | Basic Workflow Concepts | Extended Workflow Concepts This section provides a short introduction into workflow management by giving an overview on common terminology and the description of the standards of the Workflow Management Coalition. WfMC and Workflow Specification Languages The Workflow Management Coalition (WfMC) was founded in 1993 as an alliance of companies and organisations dealing with workflow management. The mission of the WfMC is to establish a common terminology and standardised interfaces for workflow management. These interfaces comprise the definition, execution and management of workflows as well as references to external documents and applications [Jung01, pp. 126]. The conceptualisation of the interfaces is given by the WfMC's reference model depicted in the figure below. The workflow enactment services - using one or more workflow engines for the execution of workflows - represent the core of the reference model [Holl95]. A workflow engine is a software managing workflows with respect to given workflow definitions.

WfMC Reference Model [Holl95, p. 20]

The five different interface definitions correspond to the integration of external aspects:

• Interface 1 specifies the exchange of workflow models between external modelling tools and a workflow management system. External tools might be graphical or textual editors for workflow definitions. Some general purpose process modelling tools supporting the WfMC standard can be used for the specification of workflows, too [Holl95, p. 20].
• Interface 2 describes the communication between a WfMS and workflow client applications. Workflow client applications are applications directly correlated with the workflow engine. They usually implement basic functionality of workflow applications like notification and data transfer [Holl95, pp. 31].
• Interface 3 addresses the need to integrate external applications. Usually, the needed functionality is not provided by the WfMS itself. Hence, there has to be an interface to other applications already running in the enterprise [Holl95, pp. 35]. Examples for such kind of applications are business related software and special software tools.
• Goal of interface 4 is to integrate other workflow management systems. The specification comprises the invocation of remote activities, data transfer as well as synchronisation aspects between different workflow enactment services [Jung01, p. 126] [Holl95, pp. 41].
• Interface 5 describes the communication between the workflow enactment services and external monitoring and administration tools [Jung01, p. 126].

Interface 1 is the most relevant specification for the purpose of mapping business process models to workflows. It concentrates on the specification of different types of workflows (processes) as well as associated organisational units and applications. The system-specific integration of applications is done using interface 2/3 [Holl95, p. 20].
The Workflow Process Definition Language (WPDL) is the first attempt of the WfMC to specify of a standard for the interchange of workflow definitions. Being a standard for exchanging models, it does not comprise a graphical notation. Meanwhile, WPDL has been replaced by the XML Process Definition Language (XPDL), an XML-based document definition for workflows (see [Nori02]). Top XML Process Definition Language (XPDL) Concepts supported by XPDL are represented by the meta-model shown in the figure below. This meta-model generally comprises static entities (e.g. data or applications) as well as dynamic concepts (processes). Static entities are represented by the meta-types

• Workflow Relevant Data,


• Workflow Participant Specification and


• Workflow Application Declaration.

Workflow-relevant data is initialised, created, read from external applications, and used during the execution of workflows [Nori02, p. 10]. It might be produced by an activity within a workflow or extracted from an external data source (e.g. an enterprise information system). For example, corporate databases are typical external data sources. These data sources are represented by the meta-type System and Environmental Data.
The workflow participant specification describes the resources which perform the given workflow processes [Nori02, p. 9]. This specification does not necessarily correspond to a human or a single person. It actually represents an abstract resource or a role which can be filled by one or more humans as well as an automated machine. Hence, the specification of a workflow participant corresponds to a resource available in an organisation or an entity in an organisational chart (Resource Repository or Organisational Model). The workflow application declaration provides the description of software applications needed for the execution of a workflow process [Nori02, p. 9]. Those applications are usually invoked by the workflow engine and workflow-relevant data has to be passed as a parameter (e.g. internal or external applications like corporate information systems or common office applications). Internal applications are usually provided as part of a workflow management system or can be developed using a proprietary development environment or language.

XPDL Meta-Model [Nori02, p. 12]

A workflow process definition is an aggregation of static entities (data, applications, participants) as well as the description of the system's dynamic behaviour. Dynamic aspects of the meta-model are represented by the entity-types Transition Information as well as Workflow Process Activity and its concrete subtypes

• Block Activity,
• Atomic Activity and
• Sub-Process Definition.

An activity is a given unit of work which will be executed by a participant using computer applications and relevant data (see [Nori02, p. 8]). Additionally, every activity is characterised by a start- and end-time as well as the fact whether it can be executed automatically by the WfMS or by a workflow participant. The transition information specifies the control flow between activities [Nori02, p. 9]. It consists of a starting activity, an end-activity and a condition under which the transition is made. An atomic activity is an indivisible unit of work which has to be done at one go. A sub-process definition allows the embedding of another workflow process definition. A block activity consists of a set of other activities (type Activity Set). The semantics of an activity set is similar to the one of a macro. If an activity set is called during the execution of a workflow process, the activities contained in the set are copied into the calling process definition [Mato03, p. 13]. Basic Workflow Concepts Main concepts for the description of the dynamic aspects of a workflow system are activities and transitions. Activities correspond to defined units of work which can be atomic or consist of a set of activities. The control flow between activities is specified by transitions. Hence, a transition relation between two activities defines the ordering of these activities. An activity can be started if its preceding activities (connected by transitions) have terminated. Transitions, activities, and static entities (i.e. IT-related resources) are grouped by a so called workflow process definition. Workflow Process Definition A workflow process definition groups all elements necessary for the execution of a workflow. As shown in the meta-model depicted in the figure above, these elements comprise dynamic (activities and transitions) and static aspects (data, applications and participants). Additional attributes are a unique identifier, a name and two headers:

• The process header comprises the creation date, a textual description and different time-related properties (e.g. estimated duration of a process' execution) of a workflow process.
• The redefinable header consists of information about the author of the process definition, a country key, its publication status, responsible participants and a version number.

An activity set is a set of activities and transitions. All transitions contained in this set can only start from activities within this set and end in activities within this set. In other words, there are no transitions leaving an activity set or coming from outside. Properties of an activity set are a list of activities, a list of transitions and a unique identifier. Workflow Process Activities As shown in the figure below there are different types of activities within a workflow process definition. An atomic activity is an indivisible unit of work executed under the control of a WfMS. Such an activity can be executed automatically or by a human participant and usually works on workflow-relevant data. In contrast to this, block and route activities do not refer to workflow-relevant data. A block activity executes an activity set and has no own behaviour. Invoking an activity set means the start of the first activity in the set. The execution terminates with the last activity in the activity set (see the figure below [Nori02, p.30]). A route activity is an activity with no behaviour. It only serves as a dummy activity for cascading transition conditions (see subsequent section on transitions).

Different kinds of activities in XPDL [Nori02, p. 30]

According to XPDL there is only one general XML-element for activities called Activity. Specific elements for route, block or sub-flow activities are missing. The differentiation between different types of activities is done by the annotation of alternative attributes. Those attributes are named Route, Implementation and BlockActivity. Activities can additionally be specified in terms of their level of automation (automatic or manual) as well as their implementation alternatives (no implementation, tool or subflow):

• An automatic activity can be fully controlled by the workflow engine using internal and external applications.
• Manual activities require the involvement of a human being.
• Activities corresponding to the no-implementation alternative cannot be supported by an WfMS (e.g. manual tasks).
• A tool supported implementation implies the usage of a software application.
• If the implementation type is set to subflow, the execution has to be delegated to another workflow process definition. Parameters can be passed to such a sub-flow activity and the synchronisation can be specified with respect to a synchronous or asynchronous execution. Synchronous execution requires the calling process to wait for the termination of the called process. After its termination the called process might pass output values to the calling process. During an asynchronous execution the calling process does not have to wait for the termination of the called process and no output values can be returned.

Additional information for activities are deadlines and simulation information:

• A deadline is the expiration of a given period of time. A deadline might for example be a milestone (given a project management context) or a specific appointment. The occurrence of a deadline can be handled synchronously (the current activity is interrupted by the deadline) or asynchronously (the handling of the deadline has to be done parallel to the currently running activity).
• Simulation information extends the model by giving specific data for the simulation of models. Examples for specific data are average costs, expected duration and average waiting time.

As shown in the figure above, every activity is a join-point for several incoming transitions (join element) and specifies the type of splitting for outgoing transitions (split element). Both - join and split - can refer to parallel or alternative executions of workflows. An alternative split (XOR) represents a fork specifying that exactly one of the given alternatives can be executed. An alternative join corresponds to the synchronisation of an alternative split . The parallel execution of activities is started by an AND-split and ended by an AND-join. Rules for the construction of workflow descriptions regarding parallel and alternative connectors (splits and joins) are classified by so called conformance classes:

• A NON-BLOCKED conformance class implies no formal properties of a diagram regarding the relationships between splits and joins.
• If the conformance class is set to LOOP-BLOCKED, the graph build by the activities and transitions is a directed acyclic graph (DAG).
• A FULL-BLOCKED graph implies that every AND-split has exactly one AND-join, every XOR-split exactly one XOR-join and vice versa. Additionally every path starting from the split will reach the corresponding join.

Transitions A transition is partly specifies the control flow between activities. As shown above the information whether incoming transitions of an activity are disjoint (alternative) or conjoint (parallel) is assigned to the activity. Additional information about a transition is assigned to the so called transition information [Nori02, p. 40]. Basic elements of such a transition are

• its name (i.e. a character string),
• a textual description and
• a condition.

A condition should be a (semi-)formal specification - represented by a Boolean expression - of the circumstances enabling or disabling a transition. Additionally, a starting and an ending node are assigned to transition information. Consequently, every transition is characterised by exactly one source activity (from), exactly one destination activity (to), and a Boolean expression representing a firing condition. There are four different kinds of conditions in XPDL:

• CONDITION: A transition can fire if its condition is evaluated to true.
• OTHERWISE: Indicates a default transition which will fire if no other transition's condition evaluates to true.
• EXCEPTION: An exception is a special transition indicating an abnormal behaviour. An exception-condition can trigger the rising of a special condition.
• DEFAULTEXCEPTION: A default exception is triggered if all other exception conditions are evaluated to false.

Top Extended Workflow Concepts

Workflows are managed by a workflow management system by assigning tasks (as parts of workflow instances) to given resources. Such a resource might be either a human participant or a workflow application. A human resource usually corresponds to a role filled by a specific person in an organisation. A workflow application might be categorised into internal and external applications. An internal application is usually implemented by the WfMC itself and is closely coupled to the workflow system. An external application is an application independent from the WfMS.

Regarding the specification of resources for the execution of workflows there is one major problem. On the one hand, XPDL aims to be a language for a system-independent workflow definition interchange. Hence, a workflow model described using XPDL should be independent from any specific workflow engine. On the other hand, the description given by an XPDL-document should be sufficiently precise for the execution of workflows. This aspect might require the annotation of specific users or applications which are subject to a proprietary definition by a WfMS. Consequently, the XPDL-definition only provides an abstract mechanism for the specification of human resources and software-applications. Workflow Participants The XPDL-specification describes workflow participants as "an abstraction level between the real performer and the activity, which has to be performed" [Nori02, p. 43]. The engine has to map every abstract participant to a user given in the workflow management system's environment. The characterisation of every abstract participant includes its unique name and type. Possible types of workflow participants are:

• RESOURCE: A specific resource given in a workflow management system's environment.
• RESOURCE_SET: A set of resources.
• ROLE: A role description that directly corresponds to a role given in an organisational chart. Such a role might be a function or some kind of qualification filled by a human.
• ORGANIZATIONAL_UNIT: An arbitrary element of an organisational chart.
• HUMAN: A human being interacting with the WfMS by worklists and/or applications (i.e. a concrete human being, like 'John Miller')
• SYSTEM: A software application representing the participant of a fully automated workflow.

Those participants are assigned to activities of a workflow model using the Performer-attribute of an activity [Nori02, p. 31]. Hence, an activity keeps a reference to an abstract participant using the performer-attribute (which is rather a character string than a reference to a workflow participant). Workflow Application Declaration According to Junginger, workflow applications can be divided into internal and external applications [Jung01].

• An internal workflow application is implemented as part of the WfMS. They are usually implemented using a programming language given by the WfMS. In the context of XPDL, those applications are called procedures.
• An external application is an individual software package which can be used by a WfMS.

Using XPDL, a workflow application is specified by a unique identifier, its type and a list of parameters. The name of an application represents a unique id and does not necessarily correspond to its physical location or a specific implementation. Like the description of workflow participants, the identification of a workflow application is only a symbolic link. The interpretation of such a symbolic link representing a workflow application depends on the WfMS at hand. There are workflow engines supporting internal applications, external applications, or both [Jung01]