Support for Workﬂow Administration and Monitoring in the ... › documents › Master_Thesis... · Support for Workﬂow Administration and Monitoring in the YAWL Environment Saphira

Support for Workflow Administration andMonitoring in the YAWL Environment

Master Thesis Information Science

Saphira Heijens

August 5, 2005

vrije Universiteit amsterdam

Support for Workflow Administration and Monitoring in the YAWLEnvironment

Saphira Heijens

Supervisors QUT:Dr. Helen Paik

A/Prof. dr. Arthur ter Hofstede

Supervisor VU:Dr. Jaap Gordijn

Second reader:Prof. dr. Hans Akkermans

Brisbane, AustraliaAugust 5, 2005

Acknowledgements

This thesis is the outcome of a six month project at the Business Process Management Groupof Queensland University of Technology in Brisbane, Australia.

First of all I would like to thank my three supervisors, I think you all did a great job. Sorry Igave you guys so much to read ;). Thank you Arthur for giving me the opportunity to do mygraduation project here. I really enjoyed my time at QUT and I thank you for not only being mysupervisor but also a friend. The same holds for Helen of course. Thank you for arranging all thepaper work for my stay as well, all the best in Sydney. Thank you Jaap Gordijn for supervisingme back in the Netherlands. Thank you Hans Akkermans for being the second reader.

Thanks Cherri & Guy for being good friends from the start and making me feel at home. I hopeI will meet you again in Europe but I’m sure I will ;). Jan, Islay & Felix, thank you guys forplaying beach volleyball with me. I always looked forward to another Tuesday night, althoughwe ended last, we had fun, at least I did...

All the people at the BPM group were always willing to provide me with input, thank you allfor that. I think it’s a great team over here and I’m glad to have been part of it for a littlewhile. Specifically I would like to thank Guy, Tore, Lachlan, Lindsay and Felix for helping meout when I got stuck with the programming. Thank you Nick for your help with the workflowlab and with the resource-related modeling. Thank you Marlon for your help with the initialproject proposal and the abstract. Thank you Stephan & Brendan for explaining how the Vistotool visualizes data. My thanks also go to Michael zur Muehlen and Wil van der Aalst for theirinput during their visits here.

Last but not least I would like to thank my parents and my sister. Clau, thanks for being closeby and always providing a listening ear and advice ;). Thank you to my parents who made itpossible for me to complete this study and to take this opportunity.

Queensland University of Technology, Business Process Management GroupBrisbane, Australia, August 5, 2005

Abstract

Workflow Management Systems (WfMS) help to streamline the operations of an organisationby automatically routing work and information across people and applications on the basisof explicit business process models. During the execution of these process models the WfMSgenerates large amounts of data. An open research question is how to best collect and analysethese data in order to manage and monitor the operation of a WfMS. This project aims toidentify the functionality a workflow administration and monitoring tool should have and toidentify which data needs to be collected in order to support that functionality. The designof this tool was derived based on a survey of recent literature and six commercial WfMS. Animplementation of a workflow administration and monitoring tool in the YAWL (Yet AnotherWorkflow Language) environment is discussed.

Contents

List of Figures vii

1 Introduction 11.1 Problem area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Expected Outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.7 Research Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.8 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Literature Study 72.1 WfMC Interface 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Foundations of Workflow Administration and Monitoring . . . . . . . . . . . . . 102.3 Research Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Existing Workflow Management Systems 233.1 Assumptions and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2 Staffware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3 MQ Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4 iPlanet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.5 Fujitsu I-Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.6 FLOWer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.7 COSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.8 Summary Existing WfMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4 Functional Requirements 694.1 Management of Organisational Data . . . . . . . . . . . . . . . . . . . . . . . . . 694.2 Audit Trail Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.3 Process Definition Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.4 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.5 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.6 Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.7 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.8 Third Party Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5 Design 775.1 Conceptual Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.2 Relational Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.3 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

v

vi Contents

6 Implementation 1016.1 Introduction to YAWL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016.2 YAWL Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016.3 YAWL Administration and Monitoring Tool . . . . . . . . . . . . . . . . . . . . . 102

7 Epilogue 1097.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Bibliography 111

List of Figures

2.1 WfMC Interface 5 Data Model, as found in [Mue04] . . . . . . . . . . . . . . . . 92.2 OR-Model of the Interface 5 Data Model . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 Business Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2 Staffware OR-Model part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3 Staffware OR-Model part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.4 Staffware Authorisation OR-Model . . . . . . . . . . . . . . . . . . . . . . . . . . 313.5 The OR-model for MQ Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.6 The OR-model for authorisation in MQ Workflow . . . . . . . . . . . . . . . . . . 373.7 iPlanet OR-Model part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.8 iPlanet OR-Model part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.9 I-Flow OR-Model part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.10 I-Flow OR-Model part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.11 FLOWer OR-Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.12 Authorisation in FLOWer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.13 COSA OR-Model part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.14 COSA OR-Model part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.15 COSA OR-Model part 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.1 YAWL OR-Model part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.2 YAWL OR-Model part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.3 YAWL OR-Model part 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.4 YAWL OR-Model part 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.5 Relational Model of YAWL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.6 Design for the overview screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.7 Design for the add resource screen . . . . . . . . . . . . . . . . . . . . . . . . . . 935.8 Design for the edit resource screen . . . . . . . . . . . . . . . . . . . . . . . . . . 945.9 Design for the add/edit substitution screen . . . . . . . . . . . . . . . . . . . . . 945.10 Design for the process definition management screen . . . . . . . . . . . . . . . . 955.11 Design for the case management screen . . . . . . . . . . . . . . . . . . . . . . . . 955.12 Design for the work item management screen . . . . . . . . . . . . . . . . . . . . 965.13 Design for the change allocation strategy screen . . . . . . . . . . . . . . . . . . . 965.14 Design for the enter business calendar screen . . . . . . . . . . . . . . . . . . . . 975.15 Design for the worklist configuration screen . . . . . . . . . . . . . . . . . . . . . 975.16 Design for the audit trail screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985.17 Design for the reports screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985.18 Design for the third party software screen . . . . . . . . . . . . . . . . . . . . . . 99

6.1 The YAWL architecture as modeled by Lachlan Aldred (revised) . . . . . . . . . 1026.2 The YAWL AdMo Tool login screen . . . . . . . . . . . . . . . . . . . . . . . . . 1046.3 The YAWL AdMo Tool overview screen . . . . . . . . . . . . . . . . . . . . . . . 1046.4 The YAWL AdMo Tool organisational data screen . . . . . . . . . . . . . . . . . 105

vii

6.5 Entering Organizational Data: adding a substitute resource or position . . . . . . 1056.6 The YAWL AdMo Tool specification management screen . . . . . . . . . . . . . . 1066.7 The YAWL AdMo Tool specification management screen . . . . . . . . . . . . . . 1066.8 The YAWL AdMo Tool third party software screen . . . . . . . . . . . . . . . . . 107

Chapter 1

Introduction

In this chapter we will describe the problem area, the research question for this thesis and theresearch approach we will take.

1.1 Problem area

Workflow Management Systems (WfMS) are primarily intended to support the automation ofbusiness operations by routing tasks and information across people and software applicationson the basis of explicit process models [AH02]. WfMS generate large amounts of data reflectingthe operations of an organisation. If analysed, this data can be used to improve the businessprocesses. The monitoring of processes is important to solve bottlenecks and other problemsthat may occur when executing cases. By specifying a common model for workflow executiondata it becomes easier to gather and analyse this data and monitor the business processes. Onemethod to analyse the data is through workflow mining [AWM04].

The Workflow Management Coalition (WfMC) is an organisation whose role includes definingstandards for the exchange of data between workflow management system and applications. TheWfMC describes a global architecture for a WfMS in the workflow reference model [Coa95]. Thismodel describes the components and the interfaces to access these components. In total thereare 5 interfaces described in the model. Interface 5 deals with the administration and monitoringfunctions. The WfMC would like interface 5 to give a complete view of the status of work flowingthrough the organisation, regardless of which WfMS it is in. The administration functionalityshould also include security, control and authorisation functions. The original definition washowever not accurate enough, there was no common agreement and there exist a number ofinterpretations on what interface 5 should really do [Hol04].

1.2 Problem statement

The goal of this thesis is to provide a more comprehensive definition of what functions anadministration and monitoring tool should support, what kind of data is needed to supportthese functions and how this data can best be collected and analysed. A conceptual model forall the data needed for an administration and monitoring tool will be defined. To validate the

2 1 Introduction

proposal, the model will be integrated into the architecture of a state-of-the-art workflow engine:YAWL (Yet Another Workflow Language) [AADH04, AH05].The problem definition for this thesis is:

What functionality should a WfMS administration and monitoring tool have and how canthis functionality be supported?

To answer this research question the following questions need to be addressed:

• What data should be collected?

• How should the data be collected?

• What forms of analysis on the data should be supported and how can the results bereported?

• What forms of remedial actions should be supported?

• How do you support these actions?

Assumptions

We assume that readers of this thesis have previous knowledge about workflow therefore we willnot explain all the workflow terminology used. For an introduction into workflow see [JB96,AH02]. We will use the terminology as defined by the Workflow Management Coalition [Coa99].

1.3 Expected Outcomes

The expected outcomes of the project are:

• A critical analysis of the data collection capabilities incorporated in existing workflowmanagement systems and standards, in particular, interface 5 of the workflow managementcoalition.

• A critical analysis of existing workflow data analysis methods.

• A model for representing, storing, and managing workflow execution data that fulfils theinformation needs of the above methods and is compatible with existing WfMS architec-tures.

• An extension of the YAWL system and implementation that incorporates the above model.

1.4 Scope

Since workflow administration and monitoring is a very wide topic we have to define a scope forthis project.

The scope of workflow administration data will be limited to:

• Users and their associated roles and competencies. We will treat all organisational datanecessary to be able to talk about authorisation.

• Access rights/authorization e.g. which group/users/roles have what kind of access to whichinformation?

1.5 Criteria 3

• History data stored in the log files.

• Version control data e.g. creation dates of process definitions.

• Escalation situations e.g. deadlines reached.

• Calendar information e.g. which days are working days.

• Monitoring e.g. reports that are being created for management.

• Concepts relevant for a workflow administrator e.g. process instance, activity, work item,worklist, status change etc.

Workflow Administrator versus System Administrator

We consider a workflow administrator to be a person that has knowledge about the processdefinitions and the organisational structure. The workflow administrator uses the administrationand monitoring tool to continuously evaluate the business process and manage the workflowadministration data. To monitor the business processes the workflow administrator needs a toolfor support. This tool should provide overviews of the status of cases and work items and offerfunctionality to manage the workflow administration data such as organisational data.

The system administrator is the person who takes care of maintenance of the workflowmanagement system. For example, installing the system and setting the system parametersin such a way that the workflow system will run efficiently. The system administrator willmanage the performance of the engine by checking factors like memory allocation. The systemadministrator should not be the same person as the workflow administrator since they are twodifferent roles. A system administrator needs more technical knowledge of workflow managementsystems while the workflow administrator needs to have knowledge about the business processes.We will only look at the data relevant for a workflow administrator.

1.5 Criteria

We have the following initial criteria for an administration and monitoring tool:

• The tool should give a good overview of the situation in the company (workloads, through-put time, bottlenecks) so that management can act on the current situation if needed.

• The tool should provide some standard reports to give this overview quickly. Graphicalreports are preferred because they can quickly show the situation and they are easilyinterpreted.

• The tool should support some analysis techniques to construct the reports. The executiondata stored in the database needs to be ’mined’ to extract useful information.

• The tool should provide possibilities to update the system with new users, change accessrights, redistribute work etc.

1.6 Related work

In [Mue04] the author develops a reference architecture for a process information system thatalso uses the operational information generated by workflow systems. It addresses the question

4 1 Introduction

of how the data from the workflow system can be integrated in such a way with the other dataavailable in the company to support decision making for the different managers in the company.We will look at the functional requirements instead of the design requirements.

Performance analysis techniques such as simulation can analyse a process definition before-hand [AH02]. By applying these techniques, bottlenecks in the process can be found beforeworkflow execution and the overall performance of processes can be improved. Performanceanalysis are a good addition to workflow administration and monitoring to optimise the busi-ness processes.

The area of workflow mining [ADH+03] is closely related to workflow administration andmonitoring. There exist a number of workflow mining tools [AWM04] to analyse the audittrail data afterwards. The actual process definition, which is the way the business process wasactually executed, can be constructed by process mining tools to aid improvements.

Business process intelligence tools [GCC+04] can help in explaining and predicting the be-haviour of the workflow system. These explanations and predictions can aid the workflow ad-ministrator in taking the necessary measures to ensure the business processes will be executedcorrectly.

Sometimes a particular case is slightly different from the defined process definition for thattype of case. The case has an unexpected element that was not foreseen during the creationof the process definition. These exception cases have to be gracefully handled by the workflowsystem [AHEA04]. Exceptions could be handled though the workflow administration and mon-itoring tool. We will not treat exception handling since this is a separate research project onitself at QUT. Researching dynamic workflow, creating personal decompositions of tasks for thedifferent users of the workflow system, is also part of that project.

1.7 Research Approach

The research plan aims at achieving the following objectives:

• Understanding of goals and issues of the WfMC’s interface 5 [Coa95]. This willbe done by a literature study.

• Survey of existing solutions (both academic and commercial). The survey will belimited to 6 WfMS that are present at the research facility (FLOWer, COSA, Staffware,MQ Workflow, iPlanet and I-Flow). The survey will be done by reading the manuals ofthe WfMS and actual experimentation with them where possible.

• Literature review of workflow data collecting and analysis methods.

• Identification of requirements/criteria for a workflow administration and mon-

itoring tool. Will be formulated by using the outcomes of the previous objects andadditional literature study.

• Make a conceptual model of all the data a workflow administrator might need.

This model will be created using Object-Role Modeling [Hal01] and Microsoft VisioMod-eler.

• Design a prototype in the form of a YAWL module to validate the proposal.

The database that underlies this prototype will be created using the conceptual model.

1.8 Outline 5

• Implement the prototype. The module will be implemented using Java Server Pagesand will be open source.

• Documentation of the outcome.

1.8 Outline

The rest of this thesis is organised as follows:

In Chapter 2 we will provide the results of the literature study performed to identify require-ments for an administration and monitoring tool. This chapter also describes methods to collectand analyse data as found in the literature.

Chapter 3 will describe how six existing WfMS handle the administration and monitoring ofworkflow execution data. We will concentrate on the functionality the systems offer for workflowadministrators.

In Chapter 4 we will describe what the functional requirements for an administration andmonitoring tool are, based on the literature study and the survey of existing WfMS.

Chapter 5 describes the design for the workflow administration and monitoring tool for theYAWL environment.

Chapter 6 gives a description of how the model that has been developed is implemented intothe YAWL workflow engine. We will briefly introduce YAWL and its architecture to positionthe administration and monitoring tool.

Chapter 7 concludes this thesis by summarising the results, indicating the contributions andidentifying future work.

6 1 Introduction

Chapter 2

Literature Study

Based on the criteria mentioned in Chapter 1, we review literature that discusses the basics ofworkflow administration or proposes a research prototype and thus suggests functionality thetool should support. We also review literature that discusses analysis and reporting techniquesfor workflow execution data.

First the standard for interface 5 proposed by the Workflow Management Coalition willbe discussed. Following that the foundations of workflow administration and monitoring andresearch prototypes proposed in the state-of-the-art literature will be reviewed.

2.1 WfMC Interface 5

This section describes the vision of the Workflow Management Coalition on an administrationand monitoring tool.

2.1.1 Interface 5

The purpose of interface 5 is to specify a common model for audit data so that monitoringand administration of workflow cases across different workflow management systems is possible.As previously mentioned, interface 5 supports administration and monitoring functions. Theinterface is concerned with the link between the workflow enactment service (server) and theadministration and monitoring tools (clients). The WfMC envisages the interface should includethe following types of operations [Coa95]:

• User Management operations

– establishment/deletion/suspension/amendment of privileges of users or workgroups

• Role Management operations

– define/delete/amend role:participant relationships

– set or unset role attributes

• Audit management operations

– query/print/start new/delete audit trail or event log, etc.

8 2 Literature Study

• Resource Control Operations

– set/unset/modify process or activity concurrency levels

– interrogate resource control data (counts, thresholds, usage parameters, etc)

• Process Supervisory Functions

– change the operational status of a workflow process definition and/or its extantprocess instances

– enable or disable particular versions of a process definition

– change the status of all process or activity instances of a specified type

– assign attribute(s) to all process or activity instances of a specified type

– terminate all process instances

• Process Status Functions

– open/close a process or activity instances query, set optional filter criteria

– fetch details of process instances or activity instances, filter as specified

– fetch details of a specific (individual) process or activity instance

In the description of the workflow reference model (1995) there was no other information oninterface 5 available. In the evaluation of the reference model 10 years later [Hol04] it is men-tioned that there is now an audit data specification [Coa98] that describes the data format oflog entries as well as the state entries responsible for those log entries. A refinement is made tothe original model by separating query and audit data functionality from analysis and reportingtools. It also mentions that currently work is being done on expressing the audit data structureas a set of XML structures. In [AWM04] a proposal for expressing the audit data using XMLcan also be found.

Author of [Mue04] suggests interface 5 could be of special interest as the standardisation ofaudit data will make it possible to integrate data from different workflow systems in a processcontrolling database.

The data structure as proposed in interface 5 of the WfMC is shown in Figure 2.1.

The Common Workflow Audit Data (CWAD) structure consists of a prefix, a body anda suffix. The body part of the data is variable depending on the event type that caused theaudit trail to be written. An event can be caused by a change to the process instance, activityinstance or a change to a work item. The audit data consists of three kinds of information: Basic,Discretionary and Private. The informationID in the prefix stores which kind of information isrecorded. The suffix is optional except for process and activity instances.

The model in Figure 2.2 is our interpretation of the interface 5 data model. A processinstance can have a parent process instance called initial process instance in the data model.An activity has an application associated with it. A user has a corresponding domain and acorresponding node (network location). A process instance and an activity instance can haveattributes. The attributes are of a certain data type and have a value and a length. A processinstance, an activity instance and a work item have a state at a certain point in time.

2.1 WfMC Interface 5 9

Figure 2.1: WfMC Interface 5 Data Model, as found in [Mue04]

The WfMC assumes that every interface will be achieved using a Workflow ApplicationProgramming Interface (WAPI). A WAPI is a group of services that are offered to a clientvia a server. The workflow enactment service acts as the server and the tools are the clients.According to [AH02] the WfMC is still working on standardising the WAPIs.

Little progress has been made thus far in agreeing on standards for interface 5. In-


terface 5 becomes significant when one wishes to compile management informationfrom the events recorded by the enactment service.

Our research will try to fill this gap by defining which functionality an administration andmonitoring tool should have and which data should therefore be collected.

2.2 Foundations of Workflow Administration and Monitoring

This section discusses the fundamental aspects of workflow administration and monitoring.

2.2.1 Functionality

An administration and monitoring tool should track the performance of the business processesso that problems can be discovered at an early stage [AH02]. The tool should also allow theworkflow administrator to intervene when needed.

To decide whether a workflow needs improvement, performance indicators need to be mea-sured. According to [AH02], there are three possible symptoms that indicate a bottlenecknamely:

• the number of cases in progress is too large.

• the completion time is too long compared with the actual processing time; the total timea case is active is very long compared to the time there is actually being worked on thecase.

• the level of service is too low; the organisation is not able to complete cases within acertain time limit.

There are three analysis techniques to analyse the performance of a workflow beforehand [AH02]:Markovian analysis (this analysis can determine the chances of a case taking a particular routethrough a process), Queueing theory and Simulation. These techniques can help predict someof the performance indicators.

Two kinds of performance indicators can be identified: internal (resource-oriented) and ex-ternal performance indicators (case-oriented) [AH02]. External performance indicators (e.g.average completion time) are important for the environment of the workflow. If the averagecompletion time for a certain case is high this can cost clients. The internal performance in-dicators (e.g. the number of cases in progress) can help identify what efforts are required toachieve a good result for the external performance indicator. Thus, there are different users ofthe monitoring data. If the administration and monitoring tool also creates reports for clientsor other external users (e.g. suppliers), different performance indicators should be captured andthe reports should be adjusted [WMC03]. [WMC03] suggests that there should be role-basedaccess to the monitoring and controlling data. This means that different data is shown for thedifferent users of the system such as supervisors/management, trading partners and customers.

In [AH02] the authors distinguish between workflow system management functions and work-flow tracking functions for a workflow administrator. They make a distinction between an op-erational management tool and a tool for recording and reporting (Most WfMS integrate thesetools into a single tool). The book suggests that operational management should take care of:

2.2 Foundations of Workflow Administration and Monitoring 11

• Resource-related information

– addition or removal of staff.

– input/revision of an employee’s details (name, address, telephone, number, role, or-ganisational unit, authorisation, and availability).

• Case-related information:

– inspection of the logistical state of a case.

– manipulation of the logistical state of a case due to problems and exceptional circum-stances.

• Additional operational management tool functions such as:

– implementation of new workflow definitions.

– reconfiguration of the workflow system (setting of technical system parameters).

For the recording and reporting tool the authors of [AH02] considered the following interestingperformance indicators that could be extracted from the audit data:

• average completion time for a case.

• average waiting time and processing time (possibly subdivided per task).

• percentage of cases completed within a fixed standard period.

• average level of resource capacity utilisation.

In [JB96] administration is divided into two parts. Administration during buildtime concernsversion control of process definitions. Administration during runtime is divided into two tasks:administration of workflow processing and configuration management. Runtime administrationneeds to be supported by a monitoring tool. An analysis tool is needed to determine theefficiency and effectiveness of workflow execution and administration by detecting bottlenecksand semantic errors. Configuration tools are needed to manage the infrastructure itself. Anaudit trail has to be recorded for two purposes that have different contexts. From a systemcontext, an audit trail supports a computation and recovery purpose, from an application areacontext an audit trail deals with workflow analysis and revision.

In [Mue00] various statistical techniques are identified that can be used for monitoring pur-poses. The article discusses cluster analysis, statistical process control (SPC) and the hedonicwage model. The SPC techniques seems particular helpful for the workflow administrator. No-tifications will be sent to the workflow administrator when values of metrics go over or underdefined boundaries.

The Admon-time client proposed in [KK02] has a graphical user interface that includes thefollowing menus: Log, Business Process, User/Role, Resource, Process Instance, Activity In-stance, Monitoring, Administration and Help. The administrator can create new instances ofbusiness processes and check the version or other properties. Process instances can be startedor terminated, properties can be viewed or the status can be changed. The status of activity in-stances can be changed as well or attributes can be assigned (priority, duration and participant).The administrator can also view the properties of an activity instance. The monitoring menu


allows the administrator to check the flow diagram and system performance and analyse theprocess or activity. The flow diagram makes use of colours and icons to display the status of theactivity instances. The tool can also display tables with information on the activity instancesor show a bar chart or line graph. The administration menu allows for terminating or abortingall or a single process and the administration properties can be accessed through this menu. Athreshold can be assigned to resources and the properties of a resource can be viewed throughthe resource menu. An organiser can be accessed to manage the users/roles.

The Workflow Management System ULTRAflow allows workflow administrators to updateprocess definitions that take effect immediately [FRF02]. Already running processes will usethe new process definition when this is not in conflict with the already executed activities ofthe workflow. This is realised by storing the specifications for all individual activities separatelyand checking whether these specifications are updated. According to the authors of [FRF02] theother approaches used in commercial WfMS usually only let new started processes use the newprocess definition.

2.2.2 Workflow Execution Data Collection

During workflow execution valuable data can be collected for management [AH02]. By analysingthis data, bottlenecks and overcapacity can be detected on time and processes can be revised.According to [KAD98] storing workflow execution data serves four purposes: monitoring, busi-ness process reengineering, recovery and authorisation. History data can also be used to calculateaverage completion times for activities so that they can be better planned and the workload willbe improved. Personal schedules described in [EPGN03] deal with planning upcoming activities.The workflow execution data is supplied by the workflow enactment service and stored in a data-base. Reports for the workflow administrator or management can be generated from this data.This can be done using a generic third party report generator or the reporting tools providedby the workflow management systems.

The author of [Mue04] finds that only analysing the information contained in the audit trailwill limit itself to quantitative data analysis. The author proposes to enhance this analysis withother data present in the company to provide the management with better decision support.This can be achieved by combining the audit data with other data in a data warehouse whichis discussed in more detail in chapter 2.2.4.

An audit trail will also be important for security. It permits tracing the user that performedcertain actions [MA01]. According to [MA01] the following information should be recorded inthe audit trail for security purposes: date and time of the event, type of the event, identity ofthe subject responsible for the event, whether the event was a success or a failure.

In [MR00] it is pointed out that the time zone a company is in should be recorded in theaudit trail to avoid problems in large companies with branches in different countries.

In [HLKP00] it is argued that if a monitoring tool is developed for a transactional system,status data does not have to be collected. Since almost all activities in transactional systems arecompleted by the system in a very short time, statistical data rather than status informationshould be provided.

The data that is stored in the audit trail can be evaluated using three different perspectives:


process, resource and object perspective [Mue00]. The process is the main perspective showingall the key performance indicators related to the workflow objects. The resource perspectiveshows all the measurements related to resources. The object perspective looks at the objects(e.g. customer order forms) that are being processed in business processes. Not many of theWfMSs store which objects were being processed in the log file. By looking at the objects, thedifficult objects that cause problems can be identified and this can also help in improving thebusiness processes.

2.2.3 Business Process Intelligence

The approaches to workflow monitoring and analysis can be divided into three groups of tech-niques and tools [CCDS04]. The first approach is to provide simple reports showing basicstatistics generated from the database that stores the execution data. Almost all WfMS offerthis functionality. The second approach is to transfer the data from the database to a data ware-house so that multidimensional analysis becomes possible. The last approach is to use businessprocess intelligence that can provide users with explanations and predictions on the businessprocesses. With this approach the administrator no longer has to ask for information, insteadthe system provides the administrator with information.

The commercial WfMS currently do not provide this functionality. The people in the researchgroup of Hewlett Packard are the first to attempt to address these challenges and develop atool that incorporates business intelligence techniques and thus provide advanced support for aworkflow administrator and the other users. Their developments are reported in a number ofpapers that we will discuss in chapter 2.3. We will not discuss all the analysis techniques indetail since it is outside our scope.

Another definition of Business Process Intelligence (BPI) is: ”the research area that looks athow analysis, interpretation and optimisation of business processes can be done by applying datawarehousing, data analysis and data mining techniques to the workflow execution data” [DHL01].Since the amount of data collected can become very large, data mining techniques can helpeffectively analyse the data. By applying the different analysis techniques the performance ofresources can be determined, the cause of bottlenecks can be understood, predictions can bemade and the business process can be optimised. In [AH02] the close relation of workflowmonitoring with data mining and data warehousing is also mentioned.

The research aimed at learning the structure of a business process by looking at the workflowexecution data is called business process discovery [ADH+03]. It is also known as workflow orprocess mining and will be discussed in more detail in the next section.

Workflow/Process Mining

Numerous papers have been written on how to construct process definitions from workflowexecution data. A detailed survey of the research on process mining using different analysistechniques is given in [ADH+03].

The motivation for process mining is that the construction of a process definition is not asimple task. Constructing a process definition requires deep knowledge of the business processesand all its constraints [ADH+03]. Therefore it can be easier to collect data about the business


processes as they take place and then extract the exact process definition for a certain businessprocess later from the gathered data. The challenge of workflow mining is to be able to derivegood process definitions with little information available. A tool independent XML-format wasdefined to exchange workflow logs between different applications.

2.2.4 (Process) Data Warehousing

The data stored by workflow management systems in the audit log can be transferred to a datawarehouse. By aggregating workflow execution data in a data warehouse together with otherdata captured in the company, more advanced analysis techniques over a period of time arepossible. The design of a data warehouse for workflow logs is discussed in [Mue01] and [EOG02].Challenges and opportunities for warehousing workflow data are identified in [BCDS01].

In [Mue01] different analysis purposes are defined. The author differentiates between work-flow monitoring and workflow controlling. Workflow monitoring is the analysis of ongoing cases,workflow controlling is the analysis of completed cases afterwards. According to [Mue01] thereare two purposes of analysis; technological or business oriented. The system administrator andworkflow designer will use the audit trail for technical oriented analysis. The workflow users andprocess manager are interested in business-oriented analysis. The author reasons that in orderto enhance the business value of audit data it needs to be enriched with application data. Thisdata is usually stored in a data warehouse and therefore by integrating audit data with this datathe existing infrastructure can be used to enhance the information available for analysis.

The data that is typically stored in the data warehouse is: the case instantiation time,starting time and completion time. For an activity the creation time, the activation time andthe completion time are stored. With this data the cycle time of the case, the net processingtime, the idle time and the frequency of case occurrences can be derived. The data stored inthe audit trail also allows for analysis of resources.

In [BCDS01] the following dimensions are defined in the data warehouse: behaviours, processdefinitions, process groups, service definitions, service groups, activity definitions, activity groups,time, resources and resource groups. The behaviour dimension is the most important dimensionfor analysis since this dimension will help identify strange cases, process definitions or workitems. The users of the data warehouse can define behaviours of interest, for example, show meall cases that took more than a specified duration.

It is remarkable that [EOG02] see the normal workflow users as users of the data warehouseas well, not only the workflow administrator or the managers. Thus, the use of the data ware-house has to be very straightforward. In [EOG02] the following dimensions are used in the datawarehouse: workflows, participants, organisation, servers, time and measures. The measuredimension can show the following measures: start time, runtime elapsed, runtime rest till dead-line, finish time, estimated finish time, estimated overtime, actual overtime and average runtime.The data warehouse contains both information on buildtime as well as runtime properties. Theauthors of [EOG02] mentions a number of advantages of using a data warehouse:

• OLAP tools offer higher functionality than typical monitoring interfaces to workflow sys-tems.


• the use of warehouse technology allows integration of the execution data with other datacaptured in the company and thus allows better analysis.

• the data warehouse can integrate data from different WfMS.

• a data warehouse can hold data for longer periods of time and is more suited for trendanalysis, it also separates the operational process support from the analytical decisionsupport.

The author of [Mue04] argues that the increasing maturity of workflow and data warehousetechniques is a good reason to combine these two techniques into a workflow-based processcontrolling system that allows companies to accurately measure the operational performance ofbusiness processes. Such a system will place the business process at the center of attention andallow complex evaluations.

2.2.5 Security

The difference between authorisation and access control in workflow is discussed in [YYW04].

Authorisation is mainly concerned about granting access privileges on data and re-sources to users, while access control makes decisions based on the specified autho-risations.

There are three different models of access control: discretionary, mandatory and role-basedaccess control (RBAC). RBAC is the most suitable to incorporate into WfMS because of itsability to represent an organisation [LLN04]. Applying a simplified RBAC to an already existingWeb-based workflow system is done in [ASKP00].

Traditional RBAC does not allow for the least privilege principle or the Separation of Du-ties [LLN04]. In traditional RBAC permissions are inherited upwards in the role hierarchy; a rolehigher in the hierarchy is permitted to play the roles inferior to it. But according to the authorsof [BFA99] this should not always be the case. For example, a manager should only be able toapprove or reject a transaction prepared by an employee, not change it. This is an example ofthe least privilege principle; do not give someone more functionality than is needed. Separationof duties is the access control requirement that makes sure an employee who applies for leavecan not approve the application himself. Separation of duties is seen as an important aspect ofsecurity to prevent fraud in the organisation [BFA99]. To improve traditional RBAC anotherRBAC called Restricted Permission Inheritance RBAC is proposed in [LLN04]. In [LKNL04] itis shown that RPI-RBAC does satisfy the least privilege principle and separation of duty accesscontrol requirements.

The granting of access privileges necessary to carry out a task is coupled with time sothat users cannot abuse these privileges to perform other tasks. This Workflow AuthorisationModel (WAM) was proposed in [AH96] and was later updated to support the separation ofduties [AH00]. The importance of synchronising the authorisation flow with the workflow toprevent unauthorised access at other times is also addressed in [Atl01]. WAM uses roles toauthorise users to execute tasks during a certain time period.

Another way to determine authorisation is using temporal data. Temporal data is dataassociated with time information such as when has the data been captured and during which


time interval the data was valid. Audit data can be seen as temporal data. Authorisation modelscan be extended with the Temporal Data Authorisation Model (TDAM) [GAX02]. With TDAMaccess to data can be specified using the time information available for this data, e.g. a managercan read financial information 15 minutes after it has been captured or a book can be read 3weeks after it has been downloaded.

In [BFA99] a language is presented to express authorisation constraints and algorithms areproposed to assign users and roles to tasks in such a way that no constraints are violated.The advantages of role-based access control and the disadvantages are discussed. The articleidentifies three different types of constraints: static, dynamic and hybrid, based on the time theycan be evaluated. Static constraints (e.g. a maximum of 4 different roles should take part in onecase) can be evaluated without executing the workflow; at buildtime. Dynamic constraints (e.g.the employee who has performed task a cannot perform task b) are evaluated during runtimeand hybrid constraints (e.g. each instance of task a must be executed by a different employee)can be partially evaluated during buildtime. The article proposes a methodology to assign rolesand users to the tasks in accordance with the constraints specified. First the static constraintsare verified. The results of the verification of static constraints are used to improve the workflowspecifications after which the planning phase is started. The planning phase is followed by theruntime phase in which the tasks are actually allocated to users and roles, according to theplanning, unless the load balancing requests otherwise (this because the allocation of tasks doesnot only depend on authorisation constraints but also on other factors like load balancing). Bybuilding in a planning phase only a few constraints have to be checked during the execution ofthe workflow which minimises complexity. The proposed constraints analysis and enforcementmodule can also generate lists of users that are authorised for a certain task. This can be helpfulfor an administrator if a task has to be reassigned. In [WBK03] a security model similar to themodel proposed in [BFA99] is discussed but it has an extra possibility to override constraintswhen a business process has a bottleneck and overriding is necessary.

In [YYW04] the authorisation model discussed in [BFA99] is disputed. The authors of [YYW04]think that the authorisation model based on logic will not be able to cope if the number of users,roles and cases grows larger. The authors discuss how Coloured Petri Nets can be used to modelworkflow authorisation management and security constraints. Before the workflow is executedchecks are required to determine whether a legitimate user can be assigned to a task. If thisis not the case the process definition has to be adjusted or the organisational model has to bechanged. The proposed authorisation management model has yet to be validated [YYW04]:

Fitting the model into an existing workflow system to validate its feasibility andsufficiency is a challenging research goal.

There are four different areas of requirements for information security [Lam91]:

• secrecy - defining who receives access to which information

• integrity - controlling how information is changed

• availability - making sure access to information is possible

• accountability - being able to look up who had access to information

2.3 Research Prototypes 17

There are two different security policies a company can choose [MA01]. A few administratorscan specify who has access to which information and most of the rules are fixed in a manda-tory policy. If the owner of a resource can determine the rules for that resource it is called adiscretionary policy. To enforce an authentication, authorisation and auditing are used. Auditdata should be protected as well because information systems are also threatened by insiders.The paper also proposes an audit system for protection against internal attackers. The systemproposed is an extension to the SecureFlow system discussed in [HA99]. The SecureFlow systemis based on the Workflow Authorisation Model (WAM) [AH96]. The SecureFlow system doesnot store data about failed authorisations. In the new proposed system an assurance table iskept to check whether the audit data was changed. A change to audit data could mean someoneis trying to cover up a malicious action. Some other users besides the workflow administratormight have privileges that allow them to change audit data. The proposed tool assists the work-flow administrator in selecting which mandatory and optional events should be recorded. Thisapproach differs from the WfMC [Coa98] which requires all mandatory events to be recorded.Event types include login and access failures. To ensure availability of the audit trail the audittrail will be backed up regularly. The archiving of an audit trail will also be an event recordedin the audit trail. The proposed tool is compatible with the security requirements as defined inthe Common Criteria; an international specification for security requirements [Pro99].

2.3 Research Prototypes

This section discusses the research prototypes developed as an administration and monitoringtool for WfMS. They can be subdivided into tools that make use of data warehouse technologyand tools that use other analysis methods.

2.3.1 Tools Using A Data Warehouse

The tools discussed in the following section all make use of a data warehouse to store theworkflow execution data.

Process Information Factory

The Process Information Factory is a tool developed by IBM to manage the performance data ofbusiness processes [SJKC04]. The goal of the tool is to provide a data foundation for a process-driven decision support system that will monitor and improve business-processes continuously.The tool uses a process warehouse to combine the workflow execution data with data from otherbusiness information systems to allow analysis. The process warehouse also stores the target KeyPerformance Indicators (KPI). The different users will have access to personalised dashboardsdisplaying information about the KPIs important for them.

Corporate Performance Measurement System

In [LM04] the shortcomings of current performance systems are identified. They are focused toostrongly on financial performance indicators, processes are not measured systematically, data


becomes available with a considerable delay and access to the data is complicated. The authorspropose a new performance measurement system with secure access that can track financialand non-financial performance indicators, gather data from various sources using a friendly userinterface. The authors of [LM04] developed a performance measurement system for an insurancecompany using IBM D2 for the data warehouse and Cognos PowerPlay as OLAP tool. Thesetools allow the creation of web-based interfaces, making them easier to use. The system candisplay different kind of graphs that can be drilled down into.

Business Process Cockpit

The [CCDS04] paper tries to lay a foundation for incorporating business process intelligenceinto a workflow administration tool.

In the current situation a company can make predictions using data mining techniques butthe application of this technology in this situation is a very complex and expensive process.The company would have to go through a number of steps, acquire a lot of software and skilledpersonnel to be able to make predictions. If this could be done much easier and faster using amonitoring tool the economic benefits would be substantial.

The authors want to provide a tool that can give explanations and predictions in an auto-mated way. This tool does not exist yet and several challenges need to be addressed. The initialresults of the research effort have been implemented in the Business Process Cockpit [GCC+02].This tool allows the definition and monitoring of business metrics and does not include BusinessProcess Intelligence yet. It provides three main functionalities. The first is displaying a varietyof reports to business and IT users. The second functionality is monitoring cases, services, re-sources and other entities related to the business process and informing users of exceptions. Thelast functionality lets users manage running cases by adjusting parameters such as case priority.The BPC visualises metrics on workflow execution data according to different focus point. Thefocus can be on processes, resources or services (invoked applications). For each focus pointbasic statistical data is available. Within a focus point different perspectives can be displayed.The perspectives provided are: time, resources, services, processes and taxonomies.

The audit log used by the BPC includes information on cases, service instances, work itemsand data modifications. The information recorded is start time, completion time, state and theIDs of the different components. Who executed the service instance and the initiator of a caseis also recorded. The name, type and new value is stored when data is modified. The workflowexecution data is collected into a data warehouse, user-defined metrics are computed on top ofthis workflow execution data and reports on these metrics are generated by the Business ProcessCockpit. The underlying data warehouse is described in [Cas02].

In [CCDS04] the foundation for building intelligence into the Cockpit is laid. The Cockpitis part of the Business Process Intelligence tool suite. This suite also contains the process datawarehouse loader and the process mining engine, which is described in [GCC+04]. The BPI toolsuite allows users to monitor and analyse completed cases from an IT or business perspective;depending on the kind of user. The tool can make predictions for ongoing or future cases, caninteract with the workflow system to prevent escalations and can identify areas of improvementin business process definitions.

2.3 Research Prototypes 19

The underlying technique for building in intelligence is data mining, but the authors considerthat out-of-the box data mining capabilities are needed to be able to mine the workflow executiondata with minimal or no user effort and without previous experience with data mining. The toolwill provide explanation and prediction buttons next to the chart that allow the administratorto react accordingly.

In [GCC+04] a classification is made of the problems that can be addressed using businessprocess intelligence. BPI can discover process definitions or improvements, analyse the businessprocess and make predictions. The discovery of process definitions is often called process miningand is discussed in chapter 2.2.3. Business process analysis detects interesting behaviour ofprocess instances and provides an explanation for situations in which this behaviour typicallyoccurs. Process prediction provides information about the outcome of a running process instanceor even information about the instances yet to be started.

The paper identifies which data mining techniques can best be used to achieve the goal anddiscusses the architecture of the extension to the business process cockpit. The tool is thentested in a supply chain environment. The tool proved to be valuable by identifying suppliersthat caused cases to escalate and predicting beforehand when extra stock needed to be ordered.

The BPI is further developed into an Enterprise Cockpit (EC) [CCS04]. The EnterpriseCockpit also includes an optimisation component and the possibility to define abstract processesthat allow users to reason about the processes more easily. The optimisation component allowsthe workflow administrator to define optimisation criteria and constraints. With these valuesa simulation can be run that can help decide whether a certain configuration is good enoughto reach the business goals. The research on BPC, BPI and EC led to the development of aplatform for intelligent business operation management (iBOM) described in detail in [CCDS05].iBOM also supports what if-analysis to see how changes made to the business process will turnout.

2.3.2 Non-Data Warehouse Tools

Most tools use a data warehouse to implement an administration and monitoring tool. In[MWGW99] the authors argue that a data warehouse is not preferred and that the tracing ofworkflow executions can in itself be seen as a workflow. They propose that only aggregateddata, to save space and allow for fast data access, should be stored. The prototype Mentor-liteimplements history management as a workflow itself. The solution is envisaged to be suitableespecially for small companies who can not afford administrator staff to maintain a complexsystem such as a data warehouse.

In [HLKP00] a web-based monitoring tool is discussed. This tool makes use of a monitorserver and a monitor client. The monitor server takes care of gathering, processing and storingdata in the database. The monitor client displays the data graphically. Since the tool is proposedfor a transactional system it does not store status information. The architecture for the tooland its implementation into the Hanuri/TFlow workflow system is further discussed in [KK02].The client is called Admon-time and makes use of two servers; the administration server andthe monitor server. The monitor server collects information from three sources: the engine, thebuild-time database and the monitoring database. The monitoring database stores statistics on


the workflow execution.Some other interesting research prototypes are discussed in [SPF04, GT97, BM00]. In [SPF04]

a monitoring tool using agent technology is proposed. The agents can be set up in such a waythat they will inform the workflow administrator if certain criteria have been violated. In [GT97]it is explained how logging and analysis is done in EvE; an event-driven workflow system. Inthis system the history of events is logged using an Active DBMS after which this data can bequeried and the results can be displayed graphically. In [BM00] the authors adapt the Observerpattern to make process monitoring available. The tool has a web-based user interface and userscan define which information they want to extract from the database.

2.4 Summary

The literature study has shown us that there is no common agreement on what functionalityan administration and monitoring tool should have and which data should be collected, but itidentified some core functionality an administration and monitoring tool should have. It showsthat security is an important issue in workflow management systems. This was not very clearfrom the interface 5 specification of the WfMC.

The literature review has shown us that there is a variety of basic and more advancedadministration and monitoring tools on the market and has shown how other techniques likedata warehousing can be used to improve the analysis of workflow execution data. The researchprototypes have provided us with an idea on which functionality is possible and what the latestdevelopments in workflow administration are.

2.4 Summary 21

Figure 2.2: OR-Model of the Interface 5 Data Model


Chapter 3

Existing Workflow Management

Systems

This chapter surveys the workflow administration and monitoring components of existing WfMS.For each system, we analyse its workflow administration functionality and data collecting,analysing, and reporting mechanisms. The result of the analysis is shown as an OR-Model [Hal01].For clarity, we group the functionalities that are common across the systems together. Somefeatures that are unique to individual systems are reported separately. This chapter concludeswith a summary of findings. It is noted that, due to time and technical constraints, the surveyhas been mostly carried out through reading the manuals and related technical documents.

3.1 Assumptions and Scope

To minimise any confusion caused by different terminologies used in different systems, we sub-stitute proprietary terminologies with the common ones defined by the Workflow ManagementCoalition [Coa99]1 whenever possible. To construct the models we will look at all the datastored by the WfMS, decide which data is within our scope and make a higher level abstractionof that data. Therefore the models will not be an exact representation of all the columns storedin the database tables. In the OR-Models, we make note of any constraints that cannot be rep-resented, or relations that are important but out of the scope for the purpose of the survey. Ananalysis of the WfMS on organisational data and a conceptual model for this data is constructedin [RHEA04]. We will use this model and therefore we will not include organisational data in theOR-models that we make, our models will only contain the organisational information neededto reason about authorisation.

Data that is relevant for the workflow administrator but that is already captured in the modelthrough other relationships will not be modeled again since it can be derived from the data thatis already modeled. Actions available for ’normal’ users that have no link to administration ormonitoring will not be described.

We will briefly introduce the concept of the business calendar since we will be looking intohow the existing workflow management systems handles this. Some of the workflow management

1Such substitutions will be clearly indicated.

24 3 Existing Workflow Management Systems

systems make use of the concept of a working day. The working day is often used for deadlinesand timers that elapse. Figure 3.1 displays a complete business calendar that captures theconcept of a working day.

Figure 3.1: Business Calendar

A day is identified by a year, a week number and a specific day in that week. For each dayit can be indicated whether it is a holiday or normally a working day. For the working days theworking hours can be specified. This model thus defines for every day of the year whether it isa working day and, for the working days, what the working hours are.

3.2 Staffware

The version of Staffware we used for the analysis is Staffware Process Engine v9 and StaffwareiProcess Engine vi9. The manuals reviewed are Understanding the Staffware iPE Architec-ture [Sta02g], Managing Staffware [Sta02f], Using the SWIP Monitor [Sta02i], Using the StaffwareProcess Client [Sta02h], Defining Staffware Procedures [Sta02e], Administering the StaffwarePE SQL Database [Sta02c], Administering the Staffware iPE SQL Server Database [Sta02a]Administering the Staffware Process Engine [Sta02d] and Administering the Staffware iProcessEngine [Sta02b].

Staffware is one of the most used commercial Workflow Management System in practice.The estimated market share of Staffware is 25% [AH02].

3.2.1 User Types

When creating a user in Staffware one of the following user attributes can be assigned: user,manager, process definer or admin. This attribute can be used to define access privileges. Usertypes that have additional privileges are discussed below.

3.2 Staffware 25

Administrator: Staffware does not make a clear separation between a system administratorand a workflow administrator. We will only discuss the functionality important for a workflowadministrator.

Process Definer: The Process Definer is the user of the system who creates the processdefinition and specifies who has access to and can create instances of this process definition.

Process Definition Owner: By default the process definer is also the process definitionowner. A different owner can be specified when creating the process definition. The processdefinition owner can edit and change process definitions.

3.2.2 Common Workflow Administrator Functionality

This section describes the functionality that Staffware offers for a workflow administrator.

Access Control

The workflow administrator can set the access type for users, user types, groups or roles to allthe objects in Staffware (process definition, activity and case). The monitoring, managing andspecifying restrictions on who can start a case is done in the case administration tool. Whencreating a process definition the process definer can specify the access types for the differentusers to that process definition, the cases and the work items with the procedure manager tool.

Process Definition Management

The Procedure Manager Tool of Staffware is used to define the process definitions and providesan overview for the workflow administrator of all the different procedure definitions and theirstatus. The procedure manager has functions to edit the process definition, create a new processdefinition or delete an old process definition. The user executing these functions must have theproper access rights to be able to do this.

Version Control Process Definitions

The process definition owner can edit and change the process definition. The version numberindicates which process definition is the latest and which process definition is obsolete. Thecases already running will finish according to the obsolete process definition. New cases willfollow the latest process definition.

Case Management

Staffware has a Case Administration Tool to monitor and manage cases. This tool can run intwo modes: view-only or full administration. Full administration will allow purging and closingof cases, the view-only mode only allows users to view the cases. The workflow administratorcan specify which mode is accessible for every user. When the case administration tool is startedit immediately displays a window showing the process definitions (name, description and the


number of live and dead cases for each process definition). By double-clicking on the processdefinition the separate cases are shown. The cases can then be closed, purged or the audit trailcan be viewed (if the user has access to the full administration mode). The information beingdisplayed for the cases can be customised by the workflow administrator and a filter for thecases can be applied. Searching for a specific case is also possible. The workflow administratorand process definer can define per process definition which users are allowed to start cases. Bydefault any user can start a case.

Monitoring the WfMS

Staffware offers a graphical tool called the SWIP Monitor [Sta02i] to show users how many workitems there are in the different queues. The work items are divided into 3 categories: totalnumber of items, number of items with a deadline and the number of new items in the queue.Users can only see their personal queues and the queues for the groups they belong to. Theusers can select for themselves which queues they want to have displayed (within the queuesaccessible to them), how often the graph should update and they can choose whether they wantto see the information in 2- or 3-dimensional form. When a user double-clicks on one of thecolumns in the chart the activities for that work queue are shown. When the user double-clicksagain on an activity the ageing information for this activity is shown. A user can also entera date range for which he wants to see all the work items. This tool can also be used by theworkflow administrator to check the workload for the different users.

User/Group/Role Management

There is a User Manager tool to add, modify and delete data about users, groups, roles andattributes. When a new user is added it initially has default attribute values and is not a memberof any group. Copying an already defined user is possible, this can be useful if you have a groupof users with the same attributes. The tool also lets you change already defined attributes fora user. Changing the group that a user belongs to, the roles the user plays or changing a user’ssupervisor(s) is also possible. The tool provides the same functionality to manage groups. Anew group also has default attribute values and no members. Members and supervisors of thegroup can be added later.

Viewing the Audit Trail

An audit trail is a predefined Staffware report that provides a detailed log of all transactions foran individual case or a process definition. The audit trail for a case or a process definition canbe viewed using any of the following methods:

• audit a single case using the case number;

• use the audit trail quick view option;

• use the audit trail window.

The log displays main process definitions and sub-processes and the associated resources. Audittrails can be copied or printed.

3.2 Staffware 27

Reassigning Work Items / Substitute User

The Staffware Process Client is the component displaying the worklists. The function to redirectall the work items in a user’s queue to another user can be found here.

Set Business Calendar

When adding a timer to an object in Staffware it can be specified whether the timer shouldmake use of working days or normal days. The administrator can define beforehand what theworking days are in the company. By default, Staffware uses a five day work week from Mondayto Friday. The concept of a working day is also used to increase the priority of work items overtime. This can prevent that low priority work items are never selected because there are othermore urgent work items.

Staffware also uses the concept of working hours when redirecting work items from an absentuser to another user. The days and times that the items should be redirected can be specified.Holidays can not be defined in Staffware.

3.2.3 Special Features Staffware

This section describes functionality offered for the workflow administrator that can only befound in Staffware.

Defining Reports

Staffware offers the possibility to the workflow administrator to define which data he wants toinclude in a report. After defining the data the administrator can run a Staffware ExecutiveInformation Service (EIS) report. There must be a third party viewer installed on the computerto view this report.

Command Line Interface

Staffware provides a command line interface called the swutil Utility for the more commonadministration tasks like extracting a table or case data, exporting procedures, tables or lists,starting a case or deleting a table. User and role information can be read and updated. Addi-tional audit trail entries can also be defined using this utility.

Moving Changes from Buildtime to Runtime

The Move Sysinfo Tool is used to move changes to user, role, table, list or procedure definitiondata from Staffware’s temporary data area to the runtime environment so that the changes cantake effect.

Creating Backups

With the Backup Manager the workflow administrator can make backups to prevent data lossin case the WfMS crashes. There are two different backup procedures. A backup of the entire


system (all process definitions, case data and all system files) can be made or the workflowadministrator can backup a single process definition and all related case data.

3.2.4 Data Collection

In this section, we look at the data collected by Staffware in relation to administration andmonitoring of workflow execution.

Staffware uses a concept called nodes. A unique directory name is created for a new nodewhere the node stores all the relevant data. Every process definition has a designated host node(A node can be thought of as a server). The process definition and its associated tables arecreated and edited on this node. All the process definition enabled activities are routed to thisnode for processing. If there are any other nodes that take part in the process definition theywill be slave nodes to the main procedure. In the system all nodes are of equal status and theywill communicate through a mailing system. One node can have multiple process definitionsassigned to it.

Figure 3.2 shows the first part of the Staffware OR-Model. In this model you can see that anode has a process definition assigned to it and that this process definition has a certain state,name and version number. A change to the status of a process definition is always caused byan action a user takes.

The other part of the model can be found in Figure 3.3. The linking concepts between thetwo models are ”user” and ”process definition”. A case is an instance of a process definition. Itis created at a certain point in time and also ends at a certain point in time. The creator of acase is also stored. A case can have a deadline and the status can change at a certain point intime. This change can be the result of an action a user took or an action of the system. Forexample, a case can be suspended because a timer expired. A work item is an instance of anactivity that is assigned to the worklist of a user. A work item has a priority so that the userknows which work item is more important and should be done first. This priority can increaseevery working day so that older items get a higher priority over time and are completed first.The priority can also be changed manually by the workflow administrator or the supervisor ofa queue.

A work item can also have a deadline and a status. The process definer can define whataction should take place when the deadline expires. An activity is part of a process definitionand has a description. In this model the assumption is made that a work item is only completedby one user. The audit trail in Staffware stores some information that can be derived, thereforewe only included the non-derivable data of the audit trail into the OR-Model.

Figure 3.4 shows the authorisation model for Staffware. A node has users assigned to it.These users can be of a certain type and have a user name. When a user wants to startworking a login to the system is required after which the work queue is displayed. The workflowadministrator can set the access type for users, user types, groups or roles to all the objectsin Staffware (process definition, activity, case and work item). The access types are use, view,edit or none. If no access control is defined for the process definition then only the workflowadministrator and the owner of the process definition can edit it. The administrator always hasfull access rights to all objects in Staffware.

3.2 Staffware 29

Figure 3.2: Staffware OR-Model part 1

3.2.5 Analysis and Reporting Methods

It is possible to create a report on case data and then view the report using a third party dataviewer application. Staffware provides the components to create the report after which you can


Figure 3.3: Staffware OR-Model part 2

create it and view it in the third party viewer.

The Executive Information System Data Viewer (editor) allows the workflow administrator

3.3 MQ Workflow 31

Figure 3.4: Staffware Authorisation OR-Model

to specify which items he wants in a report. The workflow administrator can define his ownfields or use any of the special fields that are predefined (case description, case number etc.).After the EIS Case Data Extraction Utility has run and put all the information into a csv file,the report can be viewed using a third party data viewer or any other program that can readthe file format.

3.3 MQ Workflow

The version we used for the analysis is IBM Websphere MQ Workflow version 3, release 4(This product was previously named IBM MQSeries Workflow). The manuals reviewed are theAdministrator’s Guide [IBM03a], the Getting Started with Runtime [IBM99], Concepts andArchitecture [IBM03b], parts of the Programming Guide [IBM03c] and the MQSeries Workflowfor Windows NT for beginners guide [IBM01].

MQ Workflow has a hierarchical structure. The highest level is the workflow domain, thiscan be the company that uses the WfMS. A workflow domain uses the same administrativemodel and the lower levels inherit the properties defined in higher levels. If a lower level wantsto use different properties the properties must be redefined. The domain consists of systemgroups that consist of systems. A system group can, for example, be a division of the companyand a system can be a specific branch within that division. A system contains a database, anadministration server and an optional administration utility.

MQ workflow consists of two major components: the Buildtime and Runtime components,which have their own database to store information. The Buildtime component is used to createand maintain process definitions and administer resources. The Runtime component is theexecution environment. The Buildtime database and the Runtime database are optimised for


different access patterns. The Buildtime database is optimised to store the process definitionsand the Runtime database is optimised for handling all the work requests.

3.3.1 User Types

Besides the normal user a few other user types are defined in MQ Workflow which will we discussbriefly in this section.

System Administrator: MQ workflow differentiates between a system and a process admin-istrator. Only one person can be the system administrator in an MQ Workflow system. Thesystem administrator has all access rights except for the work items. Only the owner of a workitem can issue actions on it, but the system administrator does have the possibility to transfera work item to himself. The system administrator is also the person taking care of the initialdefinition of other staff. He is also responsible for maintaining workflow models and monitoringrunning processes.

Case Owner / Process Administrator: Every time a case is started the case owner(Process administrator) is determined. The case owner gets administration rights for that case.The case owner is defined in the process definition or determined at runtime, depending on thecase parameters.

Predefined Roles: In MQ the role of manager and the role of coordinator are predefined andcan be assigned to users. The coordinator is the person coordinating a role. The manager isthe person defined as the head of an organisation. Roles can be defined to dynamically assignactivities to people.

3.3.2 Common Administrator Functionality

This section will describe the functionality that Websphere MQ Workflow offers for a workflowadministrator.

Access Control

MQ Workflow has a number of authorisation functions that can be assigned to users. Autho-risation can be explicitly or implicity assigned to a user. If authorisation is assigned implicitlyit means that the user gets access rights as the result of a certain action. For example if acase is started, the process administrator is determined and he receives process administrationauthorisation for that case.

The following authorisation functions are all explicit: The user with Authorisation

Definition authorisation can create, update and delete authorisation information, retrieveand update passwords and close active sessions to the computer. Operation Administration

authorisation lets a user perform all operation administration functions. The Staff Definition

authorisation allows a user to create, retrieve, update and delete staff information and it thusincludes the Authorisation Definition authorisation. It also lets a user create, retrieve,update and delete public and private process definition lists, case lists and worklists. The

3.3 MQ Workflow 33

topology definition authorisation allows a user to create, retrieve, update and delete topologyinformation. A user with Process Modeling authorisation can create, retrieve, update anddelete process definitions. Process authorisation allows a user to execute all the actions possiblefor a case, to query or refresh a process definition and to query, refresh and monitor work items.A user with Process authorisation is only able to do this if the case, process definition and workitems do not belong to any category. If they do belong to a category the user needs Process

Administration authorisation to be able to perform the action. The process administratorimplicity has Process Administration authorisation for cases assigned. The Case creator canset the case name, delete the case if it has not started yet, query, refresh or start the case. Thisauthorisation is also done implicitly. The explicit Work Item Authority allows a user to query,refresh and transfer a work item. The Work Item Owner authorisation is applied implicitly andallows a user to force-finish and force-restart a work item. The Administration Server will checkthe user identification and password and establish a session.

Viewing Escalated Work Items

MQ Workflow uses two allocation methods. Static and dynamic work allocation. With staticallocation the specific users that should perform a work item are defined. With dynamic workallocation the criteria for users that may receive the work item are specified. If no one satisfiesthe criteria or the users who can perform the work item are absent the process administratorwill receive the work item. If the process administrator is authorised to access the work itemsof other people he can transfer the activity to another user. Work items that have a status ofready or suspended can be transferred.

Process Definition Management

Process definitions can be grouped together in categories. A user with Process Modeling autho-risation can create, retrieve, update and delete process definitions.

Case Management

Runtime is the MQ Workflow component that takes care of the execution of processes: the cases.With Runtime cases can be started, executed, stopped or resumed and the history of a case canbe viewed. The user needs to have Process Authorisation to be allowed to do this.

Monitoring the WfMS

After logging into the MQ Workflow Client, the user can start work items, create and deleteworklists, organise his worklists, change the status of a work item, delete finished work itemsand monitor cases. Three types of clients can be used: a standard client, a web client or acustom client. If a user is authorised to do so, cases can also be interrupted using the workflowclient and work items can be reassigned.

MQ Workflow has a tool called the Process Instance Monitor to observe the execution of acase, determine the state of a case and view the history of case execution. The monitor can only


be retrieved by users with process authorisation or process administration authorisation, or byusers who are either the process administrator, creator or system administrator.

Worklist management

The user can create worklists and choose what is displayed on them and how they are ordered.The process modeler can also create predefined worklists for users.


The Buildtime component is used to authorise users and enter the organisational information.MQ Workflow also supports the use of a centralised staff administration tool such as LightweightDirectory Access Protocol (LDAP) to manage staff. If LDAP is used MQ Workflow offers a toolto make staff management easier. This tool is called the LDAP Bridge and helps migrating staffupdates from an LDAP server to the MQ Workflow database or the other way around.


When a process instance is executed MQ Workflow writes information about each significantevent into an audit trial. The audit trail is managed in the MQ Workflow relational database.The workflow administrator can specify whether an audit trail is written, where it is written andwhich events should get recorded in the audit trail. Audit trails can be written to a database,send to a worklist or published using the MQ Integrator publication server.

Configuring the Audit Trail

There are four options for configuring the audit trail:

• no audit trail

• condensed audit trail - a setting in which only important event information is recorded

• full audit trail

• filter audit trail - the workflow administrator can specify which audit event information iswritten.

These options can be set using the MQ Workflow Buildtime or a Flow Definition Language(FDL). Audit trail specifications are inherited from the higher levels of MQ Workflow, fromdomain to system group to system. The events are written into the audit trail on the MQWorkflow system. Cases are identified by the case name or the case identifier. Both are writteninto the audit trail.

Deleting the Audit Trail/Database management

Audit trail records can be deleted using a command line interface. Records before a specificdate can be deleted or records belonging to cases that finished prior to a specified date can alsobe deleted.

3.3 MQ Workflow 35

Business Calendar

MQ Workflow does not make use of the concept of a working day.

3.3.3 Special Features MQ

This section describes functionality offered for the workflow administrator that can only befound in MQ.

Substitute Person Tool

In MQ Workflow a person cannot be deleted if:

• the person is logged on or a program execution agent exists for this person

• the person is the process administrator of a process

• the person has work items in the states: CheckedOut, Executed, InError, Ready, Running,Suspended, Suspending, Terminated, Terminating

• the person has notifications

• the person is the manager of an organisation

• the person is the coordinator of a role

• the person is the MQ Workflow System Administrator

The Substitute Person Tool checks the first four items in the list. When the tool is started theuser to delete is specified and also which user will take over the work. The tool then reassignsprocess instances, work items in any of the listed states and notifications to the substitute user.Work items in the states terminated and inError are transferred to the process administrator.

Another tool to manage staff is the substitute person tool that can transfer run-time objectsfrom one user to another user so that the user can be deleted.

Notifications

When deadlines have expired Runtime can send notifications to users. If they do not act on thefirst notification within a specified time the process administrator will get a second notification.


The database stores all the data that is relevant for process execution. If the state of a work itemor case changes this is stored in the database. In Figure 3.5 the OR-model for MQ Workflowis shown. A process definition can be part of a category. A category is a group of processdefinitions and can help in assigning access rights. A user can only have access rights for certainprocess categories. Once a process definition is completed it can be imported into Runtime. Ifthere are already cases running from the same process definition they are not affected by theupdate to the process definition. New cases will follow the new version.

A process definition consists of activities. An activity instance in a case is called a work item.A work item has a name and has a status that can change as users or the system modify thework items. A case also has a status that is related to the status of a work item. For example


Figure 3.5: The OR-model for MQ Workflow

if the last work item in a case is completed the case is also completed. This relation betweenthe status of a work item and a case is not modeled. A case is started by a user and the time

3.3 MQ Workflow 37

it was started is also recorded. When a case is started the process administrator for the caseis determined. The ending time for a case is also recorded. Every user that is authorised canchange running cases. Work items can be reassigned or cases can be interrupted.

When a case is suspended this does not stop its subprocesses. To achieve this a deep suspendmust be performed. Cases with the status running or suspended can be terminated. All thework items within the case are automatically force-finished. When a terminated case is restartedit starts again from the beginning.

Each audit trail record is associated with a timestamp. This timestamp reflects the date andtime the audit trail record was written. The timestamp is stored as coordinated universal timevalue (UTC). Since it is not guaranteed that all timestamps are unique, the sequence in whichaudit trail records with the same timestamp are retrieved is random.

Figure 3.6: The OR-model for authorisation in MQ Workflow

Figure 3.6 displays the authorisation model of MQ Workflow. A user logs on to the adminis-tration server through the workflow client. This establishes a session for the user. Through thissession the user has access to the cases and his work items. We assume a user can have multiplesessions but this is not described in the manuals.

A user is part of only one organisation. An organisation describes the structure of a company.An organisation can only have one parent organisation but can have multiple child organisations.The authorisation rights can be set for a user specifically and can be assigned to roles andorganisations. These rights determine which actions a user can perform on process definitions,cases and work items and whether the user can define and authorise staff. A description of theauthorisation rights was already given in chapter 3.3.2.


To analyse the audit data stored in the Runtime database there are several views provided inMQ Workflow. There are also a set of database queries that can be used to analyse the auditinformation, and to monitor the process instance executions. When a database connection is


established any SQL query can be run on the database including queries on the audit trail orthe log files.

The concepts and architecture manual [IBM03b] mentions that you can use mining andanalysis tools to analyse the audit information and also check the performance of the processes.However it does not mention specific techniques or tools and these tools are not provided withMQ Workflow.

MQ Workflow provides the following three pre-defined views to monitor the business process:a view for successfully finished activities, a view for failed activities and a view for processinstances, including process instances in progress.

Successfully finished activities view

The successfully finished activities view gives an insight into how long it took for a work itemto complete. It gives the case ID and name that the work item belongs to as well as the ID andname of the work item. It shows what time the work item was ready to be executed, when itwas finished, who executed the work item and how long it took to complete it. It also providesthe time it took for the work item to be actually started.

Successfully/partially executed process instances view

The successfully/partially executed process instances view provides an overview of the casestatus. It shows the name and ID of the case, whether it was executed as part of another caseand if it was the name and ID of that case, the time the case was started and finished (if italready finished), the amount of time that passed between ending and starting of the case, thename of the user who started the first work item, the sum of the time it took to complete thedifferent work items in the case and the sum of all the time spent on work items that failed.

Failed activities view

The failed activities view provides an overview of the case name, ID, work item name and ID,time when the work item was ready, time when the work item was finished, the elapsed time ofthe activity in seconds and the user who executed the activity.

In addition to the database views, MQ Workflow provides some example queries that can beadjusted to get information about the processes and activities.

Process Instance Monitor

The Process Instance Monitor provides an overview of the status of a case and the history of acase can be viewed.

3.4 iPlanet

The version we used for the analysis is iPlanet Integration Server 3.1 also called iIS (ThisWfMS was formerly known as Forte Fusion). The manuals reviewed are the Process System

3.4 iPlanet 39

Guide [Sun01c], the Conceptual Overview [Sun01a], the Master Index [Sun03] and the ProcessDevelopment Guide [Sun01b].

iIS is installed and run from within an environment called iPlanet UDS and consists of twosystems; a backbone system and a process system. The backbone system provides componentsthat make it possible to communicate between enterprise applications and the process engineusing XML. The process system contains the process development tools, the process managementtools and the process engine that coordinates the work of different resources and applicationsthat participate in the business processes. The process engine stores data in the engine databaseand uses an organisation database for the user information. The organisational database is notsupplied with the product. The process engine can use any relational database system supportedby the iPlanet UDS environment and all required database tables for the engine database willbe created by the engine at startup time.

The Process Management Tools, consisting of iIS Console and its command line counterpart(Conductor Script), support registration and execution of process definitions, monitoring andmanaging cases, maintaining application sessions with the workflow engine, handling failoverand recovery and maintaining history logs of workflow execution.

3.4.1 User Types

In this section we will briefly describe the user types that iIS makes use of besides the normaluser.

System Manager: The system manager takes care of registering new or updated process def-initions (or assignment rule dictionaries or a user profile) with an engine, and possibly unregisterthem when they become obsolete. The system manager can also abort process instances. Thesystem manager also takes care of setting up the process management system and this role isthus wider than the workflow administrator we defined.

Process Developer: The process developer creates the process definitions using the ProcessDevelopment Tools.

A user can be given additional administrative privileges.


This section will describe the workflow administration functionality that iIS offers for the systemmanager.

Access Control

The authentication of users is done through a user profile in iIS. Normally each engine has onlyone registered user profile. An exception is when migration from an old to a new user profile isongoing. The standard user profile can store the user name and the roles of a certain user.

If a company wants to include more sophisticated allocation rules, the user profile can beextended with, for example, signing authority and manager name. iIS provides a tool called the


User Profile Workshop to extend the user profile. This tool is part of the process developmenttools and allows a user profile to be created, edited, compiled and registered. Because the userprofile is used for both assignments of activities and validations the assignment rules and thevalidateUser method also need to be updated if changes to the user profile are made. Before thenew validation and assignment rules are registered with the process engine the new user profileneeds to be registered. The user profile has to be consistent with the organisation database sincethe database is used for validation of the users.

The validation workshop lets you write, save, compile and register a validateUser method.The assignment rule workshop helps in creating and editing assignment rules. The allocation ofwork items is based on the user profile using these assignment rules.

If no assignment rules are specified for a work item anyone can see and start the work itemsin their worklist. If no assignment rules are specified for a process definition anyone can starta case. So the assignment rules determine who can perform a work item and who can createa new case. The rules are also used to determine whether a user has access to informationlike for example the case attributes. All the assignment rules are stored in an assignment ruledictionary.

Process Definition Management/Version Control

The registration manager, a part of the process engine, keeps track of the names and versionsof registered process definitions, user profiles and assignment rules.

Case Management

In the iIS console the execution of the process instances can be monitored and therefore can beinterrupted by the system manager when needed.

The process execution tasks that are supported are:

• checking the execution status of a case and possibly aborting it.

• checking the status of a work item and possibly changing its state.

• checking the status of a worklist and possibly re-prioritising a work item within the work-list.

• checking the status of a deadline and resetting or changing it.

• checking the value of a process attribute and possibly changing it.

• checking for bottlenecks.

Monitoring the WfMS

With iIS console the system manager can view the status of an engine and monitor the executionof individual processes and high priority events. Viewing performance charts for the engine canalso be done in the iIS console. The engine performance charts allow the system administratorto keep an eye on the number of active process instances running on the engine, the numberof work items in the ready or active state, the response times from the process engine and thememory allocation. iIS console can display lists and properties of a session, a work item, a case,process attributes and a timer (deadline or elapsed time).

3.4 iPlanet 41


IPlanet uses User Profiles as described in the access control section to create and define theproperties for the different users.


The history manager, part of the process engine writes current state and history log informationto the engine database.

Business Calendar

In iPlanet business days can be defined by using elapsing timers by setting the ElapsedOn andElapsedOff properties of the timer. Working hours or holidays can not be defined. In the UDSControl the time zone in which the company is in can be set and whether it currently hasDaylight Saving Time.

3.4.3 Special Features iPlanet

This section describes functionality offered for the workflow administrator that can only befound in iPlanet.

Configuring the audit trail

When the system manager sets up a process engine, the information to store in the databasecan be selected.

Registration & Version control

The user profiles, the validation method, the assignment rule dictionary, the process definitionsand the aliases need to be registered with the process engine. Registering these objects canbe done in the process development tools or in the process management tools by the processdeveloper or the process manager. When a new process definition is registered with the processengine the process instances that were already running complete according to the old processdefinition. Newly created instances of the process definition will follow the newer version. Whenall the instances of the old process definition have completed the engine automatically unregistersthe old process definition. An alias is a short name for a process definition registered with theengine. When a new assignment rule dictionary is registered this also affects all existing workitems. The work items will be offered again to the users based on the new rules. Aliases canbe unregistered one at a time from the process engine. Aliases are used to refer to subprocessesfrom within other processes. All the registrations can be viewed through the monitor in the iISConsole.

History logs

The iPlanet system stores 14 history log tables. The ActivityLog is a log of activity instances(work items) both current and past in the system. The ActStateLog is a log of state changes in


activity instances in the engine. The AlarmLog is a log of all alarms generated on this engine,recorded whenever history logging is timed on. The AliasLog is a log of aliases (references toprocess definitions) registered with the engine. The AttribLockLog is the log of access obtainedon all instances of process. The ColdStartLog always contains one row showing the last time theengine was cold started (thus dropping and re-creating all registration, state and log tables). ThePerformanceLog stores performance statistics for the engine such as number of ready work items,number of running timers and number of active processes. Because almost all of the elementsstored can be derived we will not model the contents of this log file. The ProcAttribLog stores thevalue changes to process attributes. The ProcessLog logs the process instances (cases) createdin the engine.

The ProcessStateLog is a log of the state changes to cases in this engine. The RegistrationLogis a log of registrations with the engine and the SessionLog is a log of current and past clientsessions. The TimerLog is a log of timer instances that have been instantiated in the engine.The TimerStateLog is a log of the state of timer instances for the engine.

To restrict the size of the history log files the system manager can decide which state changesare to be recorded. The state changes to work items, case attributes, lockStatus of case at-tributes, cases, sessions and timers can be logged. The administrator can also decide whether todelete the old rows in the history log from the engine database and transfer them to an archivedatabase. iIS provides a Dump/Restore facility to transfer the data. The system manager canalso specify the level of recovery if the process engine crashes and needs to restart.


The engine database of iPlanet consists of three categories of tables:

• current state - These tables will help recover the status of the cases when an engine failureoccurs.

• registration - These tables maintain the version information about the registered items(user profile, assignment rules dictionary, process definitions, aliases).

• history logs - The historical data about the most important objects created during processexecution (sessions, cases, activities, timers, attributes and attribute locks) is stored inthese tables.

The first part of the OR-Model of iPlanet is shown in Figure 3.7. The term ’activity instance’is replaced by ’work item’ and we use the term ’case’ instead of ’process instance’.

When a user wants to access the work list and start completing specific work items of casesa session with the engine must be opened. The user supplies login information after which theengine creates a user profile object and executes the validateUser method. The validateUsermethod checks the information supplied by the user with the information in the organisationaldatabase and, if the user is authenticated, puts the rest of the details such as roles in the userprofile object. The assignment rules can then use the user profile to determine which work itemsthe user can perform and create his worklist. A user can open multiple sessions but most of thetime there will be a restriction placed on the number of sessions by the system administrator.

3.4 iPlanet 43

Figure 3.7: iPlanet OR-Model part 1

A work item has a certain status, all the changes to the status of a work item can be related toa user or system action. A work item is an instance of an activity allocated to a user.


The other part of the OR-Model of iPlanet is shown in Figure 3.8. The connecting objectsbetween the two models are ’case’ and ’point in time’.

Figure 3.8: iPlanet OR-Model part 2

3.5 Fujitsu I-Flow 45

An process definition consists of activities. An activity is part of a process definition and isof a certain type. A case is an instance of a process definition and has a status. If the state of awork item changes this can also affect the state a case is in. If, for example, the last work itemfor a case is completed the case will also be completed. A case state can also change because thesystem manager decides to abort the case. All the events that change a case status are loggedin a logfile and can be related to an action of a user or the system.

iPlanet has two kinds of timers: a deadline timer (e.g. the case must be completed before acertain point in time) and a timer that elapses (if three days have passed without a change to thecase something should happen, this can be a message to the system manager or another action).The difference between the timers is not represented graphically since they both represent apoint in time.


iIS does not provide tools for analysing information in the database’s history log tables. Theinformation about the structure of the log tables is provided. The user has to write his owntools for querying the database to analyse the workflow execution data.

The Process Development Guide mentions that a status report tool that accesses the databasewill be developed by most companies. It is the responsibility of the system manager to constructa reporting tool.

3.5 Fujitsu I-Flow

The version we used for the analysis is I-Flow version 6.1 developed by Fujitsu. The manualsreviewed are the Administration and Installation Guide for the Advanced Edition [Fuj03a], theDeveloper’s Guide [Fuj03b] and the User’s Guide [Fuj03c].

I-Flow is a distributed client-server system that is accessible from Web-browsers. The systemhas a 4-tier architecture and the user interface can be implemented as a Java based thick client,Java applet or as web pages in a browser. A system-specific aspect of I-Flow is that it can sendSMS-messages so that for example approval of tasks can be achieved without the need for acomputer.

3.5.1 User Types

In this section we will briefly describe the user types that I-Flow has besides the normal user.

Process Designer: The user that is responsible for designing and implementing the processdefinitions.

Administrator: The administrator can use the Administration Client to manage the I-Flowsystem.


This section will describe the functionality that I-Flow offers for a workflow administrator.


Access Control

I-Flow has two security levels the system can be set to: Open Security mode and Security mode.In Open Security mode any I-Flow user can view a work item. In Security mode the access toprocess definitions, cases and work items is restricted to the specific users who will be workingwith them. Only process definers can create new process definitions. To modify a work item auser has to accept the work item first. By default I-Flow is installed in Open Security Mode.

Procedure Definition Management/Version Control

The Development Manager in I-Flow is used to design the process definitions. After an admin-istrator is logged in to the administration client it is possible to import, export, delete, archiveand change the state, owners and versions of process definitions.

Case Management

Though the Task Manager the ongoing cases can be monitored and their status can be changed.

Monitoring the WfMS

The I-Flow Server Dashboard is a system management tool for monitoring activity levels andkey performance indicators.


The Server Administration Tool is the interface that supports managing the process definitionsand user profiles. I-Flow can make optional use of LDAP for staff management.


The case history can be viewed in the Development Manager or through the Server Administra-tion Interface. A user can apply filters to display information about process definitions or casesby initiator, owner, priority, state or identifier. The filter works in a similar fashion as an SQLSELECT statement.

Display Reports

The I-Flow Reports tool, part of the task manager, is the interface used to display a varietyof reports about cases, process definitions and tasks. Case reports display information aboutparameters like case state, duration and who initiated the case. Process definition reports displayinformation about the states of process definitions and who the owner of the process definitionis. Work Item reports display a summary of work items grouped according to the state they arein and information about the users allocated to the work items. Customised reports can also becreated by the workflow administrator.


Generate Reports

The I-Flow Reports section in I-Flow Task manager helps to generate reports or generate queries.There are a number of template reports the workflow administrator can choose from. The reportsare displayed as a PDF file.

Reassigning Work Items

I-Flow has three different reassignment modes:

• regular mode

• process-owner-only mode

• no-reassignment mode

In regular mode all the users that the work item is allocated to can reassign the work item toother users after accepting it. In Process-Owner-Only Mode only a process owner can reassigna work item to other users. The process owner does not have to have the work item allocatedto him to be able to reassign the work item. In No-Reassignment mode reassigning work itemsis not possible. By default I-Flow is installed in regular reassignment mode.


I-Flow makes use of all the concepts in the business calendar. Working days, hours and holidayscan be defined. For companies that have international divisions you can also specify in whichtimezone (GMT) the company is. It can also be indicated if Daylight Savings Time applies.Multiple business calendars can be used and they can be assigned to process definitions or cases.This can be helpful when there is only worked on certain cases on a specific day of the week.

3.5.3 Special Features I-Flow

This section describes the functionality offered to the workflow administrator that can only befound in I-Flow.

Archiving cases/process definitions

The workflow administrator can delete or archive cases and modify or delete user profiles. Archiv-ing multiple cases or process definitions at once is possible.

Server Dashboard

The use of the dashboard is optional but it can give the system administrator a quick view ofthe status of the server using graphical charts. The dashboard uses the server and adapter logfiles to create the graphical overview. Besides the graphical information the information storedin the log files is also shown at the bottom of the screen. Six graphs display activity statusinformation. In the first graph the number of logged-in users is displayed as well as the numbersof users with active workflow processes. The other five graphs display information about systemperformance parameters like memory allocation.


I-Flow email and SMS notifications

I-Flow offers the possibility to send users an email notification or an SMS message with infor-mation about a certain task. The user can reply immediately through a link in the email or bysending back an SMS message with instructions which action to take.

Exception Handling

I-Flow has a function called process editing that will create a private template of a processdefinition in case the process is slightly different from the published process definition.


The first part of the OR-Model for I-Flow is shown in Figure 3.9. The I-Flow specific term’template’ is replaced by ’process definition’. The term ’process’ is replaced by ’case’. A processdefinition has an ID, version number, name, owner, title and description. A case and a workitem have a name, ID, title and description.

A process definition can be in one of the five states: Draft, Published, Private, Obsolete orDeleted and has an ID, version number, name, owner, title and description. When a processdefinition is in the draft state it is still in the design phase. Only the owner of a process definitionis allowed to create a case from the process definition for testing purposes. When the processdefinition is completed the administrator can publish the process definition. The administratoralso takes care of changing the status to obsolete and deleting a process definition. When thestate of a process definition is changed to obsolete the users can still work on the cases alreadyrunning but new cases cannot be created from this version of the process definition anymore.The state Private is used for a running case that is changed by a user. When draft and privateprocess definitions are deleted they are dropped from the system. Published and obsolete processdefinitions are not dropped from the system but their state cannot be changed anymore andnew cases cannot be created from deleted process definitions.

The owner of a process definition is the user who created it. When a process instance iscreated from the process definition the owner of the process definition is also the owner of thecase by default. The ownership of a case can also be determined by using roles.

Users can accept or decline a work item. If all of the assigned users decline a work item,active work items are created for each of the case owners. If all the case owners also decline thework item the work item becomes active for all of the case owners again.

A user session object is created for every user that logs into the system. Before the user canstart working he must be authenticated with the server. Multiple users can be logged in at thesame time. A session can be active or terminated.

In the second part of the OR-Model shown in Figure 3.10 the data captured about workitems and cases is displayed. A case and a work item have a name, ID, title and description. Awork item is part of a case and has a certain status that can change over time. The changes tothe status of a case are also stored. The administrator can suspend or resume cases using theAdmin Client. When a case is suspended all the work items within the case are also suspendedand disappear from the work list as if they were completed. All changes can be traced back to


Figure 3.9: I-Flow OR-Model part 1

a user or actions taken by the system.

The use of I-Flow Analytics is optional so I-Flow also provides a history table to store


Figure 3.10: I-Flow OR-Model part 2

workflow execution data. The table captures events occurring in I-Flow. Since all actionsperformed with I-Flow are events, this table captures the exact state of the I-Flow system at all


times. Each row in the table represents an I-Flow event. The elements recorded for each eventare type, source, target, timestamp and the user responsible for the event.


I-Flow has a number of tools that can be used for analysis and reporting purposes that aredescribed in this section.

I-Flow Analytics

I-Flow Analytics is a service that can be installed optionally and runs on a separate server fromthe engine so that the event data from multiple servers can be collected. Event information issent to this server and stored in the data warehouse as a permanent record of past events. Thisinformation is then placed in OLAP cubes so that full ’slice and dice’ manipulation is possible.Reporting tools can then be used to provide charts and make reports on the OLAP data. A setof standard charts and reports are provided in Microsoft Excel.

Information that can be viewed, for example, is how long cases take to complete on average,which cases take the longest, etc. This information can help the workflow administrator toidentify bottlenecks and areas for improvement.

I-Flow Analytics automatically captures certain I-Flow process-related data. All the datacreated by events is stored. The workflow administrator can also define which additional datato capture. The captured data is processed into cubes and displayed in Microsoft Excel PivotCharts. I-Flow events are actions taken by I-Flow users during case execution. The eventsrecorded in the I-Flow Analytics database are:

• The creation of a case.

• The start of an activity; The first activity starts just after a user starts a process. Subse-quent activities start just after a user completes the previous work item.

• The starting of a work item, this happens when a user actually starts the work item afteraccepting it.

• The suspending of an activity.

• The completion of a work item.

• The completion of a case.

For each event the following information is recorded: ProcessInstanceID, ParentInstanceID,WorkflowInstanceID, ActivityInstanceID, ProcessID, BlockID, ActivityID, Timestamp, Sequen-ceID, System, EventType and ServerSeqID.

As mentioned previously I-Flow Analytics stores the raw data that can be processed intoOLAP Cubes afterwards. The cubes need to be processed for analysis after which reports canbe generated. The administrator can add attributes to be recorded into the data warehouse. Toprocess the cubes, I-Flow makes use of the tools provided by the SQL Server.


I-Flow Reports

The I-Flow Reports Tool can help the workflow administrator to construct queries and thusanalyse the database for the necessary information.

I-Flow Server Dashboard

I-Flow has a Server Dashboard with graphic representations of mostly system performanceindicators. The tool is less useful for a workflow administrator.

Pivot Table and Pivot Chart Reports in Microsoft Excel

After the cubes are processed, standard reports can be generated on the data using Excel VisualBasic Macros. There are six standard charts/reports that are provided with I-Flow Analyticscorresponding with the six cubes:

• Work In Progress

• Cycle Time

• Productivity

• Workload

• Activity Load

• Activity Performance

Custom reports can also be created however, these reports are not directly supported by afunction. The administrator has to do a number of steps to generate the reports.

Each report contains two worksheets; one providing a graphical notation and the other oneproviding a table. We will now look at the contents of the reports in more detail.

Work In Progress provides information about the volume of work items in each activityacross all the cases. It can show the status of the work items per activity and the age of thework items per activity. The corresponding cube is continuously updated and calculations aremade in real-time. The Cycle Time report gives information about the average cycle timeper case or the average cycle time per region. The Productivity report has four overviews.One report displays the number of work items of a certain activity completed during a timeperiod. There is a report showing the average time it takes each user to complete a certainwork item. The next report lets you compare the number of work items completed per user overtime. The last report show the work items completed over time for one user.2 The Workload

shows the number of work items remaining unfinished at the end of the day grouped per regionand it provides a report showing the incoming and outgoing work requests per region. TheActivity Load provides 3 reports. The first one shows the number of work items remainingin each activity at the end of the day. The second report shows the same information for aspecific activity at the end of each day for the last week. The last report shows the number ofwork items that entered and exited a specific activity during each day. The last standard report

2In the last three reports the names of the actual employees are displayed. In some countries it is not permittedto monitor the productivity of your employees like this because of privacy laws [AH02].

3.6 FLOWer 53

Activity Performance provides two overviews. The first one shows the average waiting timesper activity. The second one shows the average process times per activity.

The reports show the highest dimension when you open them for the first time. For examplethe time dimension starts at the level of year. You can drill down to a smaller dimension in thecase of time to days, hours or even 15-minute periods. You can also combine multiple measuresin one view to be able to compare data. For example, workload in progress and workloadcompleted can be combined in one view.

3.6 FLOWer

The version we used for the analysis is FLOWer 3.0 . The manuals reviewed are the FLOWer 3.0User’s Manual (Gebruikershandboek) [Wav04c], the FLOWer Administrator Guide (Beheerder-shandboek) [Wav04a] and the FLOWer Designer’s Guide [Wav04b].

FLOWer is a case-driven system, it allocates cases to users. It is pull-driven; users can selectwhich cases they want to work in, from the cases that are allocated to them. FLOWer uses avery different paradigm then the other workflow management systems.

3.6.1 User Types

Flower has the following user types:

Case user: A case user can view and work on the cases assigned to that user.

Admin user: The admin user has access to the FLOWer administration tool and created theorganizational structure. The admin user is also a studio user by default.

Studio user: The studio user has access to the FLOWer Studio. The studio is used forcreating and releasing case types.

3.6.2 Common Workflow Administrator Functionality

This section will describe the functionality that FLOWer offers for a workflow administrator.

Access Control

Access control in FLOWer is done through working profiles. Specifying the access rights is doneby specifying access rights for roles and associating roles with the process definitions. Roles aredefined hierarchically, so a user with a certain role automatically inherits the lower roles.

Process Definition Management/Version Control

A case type is defined in the FLOWer studio. After the case type (process definition) is com-pleted, all the tasks, forms and roles are defined. The case type can be released through theFLOWer studio. When releasing a new case type the new version can overwrite the old versionor it can be added. When there are still running cases of the old version of the case type the new


version should always be added. Otherwise the cases running according to the old definition willnot be able to complete anymore.

Case Management

Since FLOWer is a case-driven system a lot of functionality is provided to manage cases. TheFLOWer Coolbar provides a shortcut to the case monitor and the case query tools. The searchfunction for specific cases can be started through the CoolBar. For each different case type thereis a different search tool. The properties of the search tool can be adjusted by the workflowadministrator. Each case search tool can therefore look slightly different and have differentfunctionality. From a case search tool a new case of the same process definition can be startedor existing cases can be opened and edited. When starting a case, the activity to start withcan be defined. The tool thus also functions as a kind of worklist. Cases can be searched usingdifferent parameters. The cases that have been found can be deleted from the worklist withoutasking for confirmation. The administrator will need to specify who has the rights to do thissince this can have major impact. The administrator can also specify whether the cases foundshould be read-only. This can be used to differentiate between users with only read access andpersons with read and write access.

With the All Cases Tool a user can search a case in all the cases. The search is not limitedto cases of the same process definition. There is also an overview provided showing how manycases there are for the different process definitions. The rest of the tool works the same as theSearching Cases Tool.

With the Case Guide the user is guided through the process definition for the case and itsassociated activities. The Case Guide supports the activities that should be done to completethe case. What is remarkable in FLOWer is that the user can deviate from the ’normal’ processas long as the boundaries set by the process modeler are not violated. But activities can beskipped or done again if the user wishes to do so. FLOWer checks whether the role of the userallows for these exceptions.

The Case Guide also provides an overview of all the data known for the specific case. Whetherthe data is readable for a user depends on their role. The Case Guide not only shows the wholeprocess, and the activities that are complete but also the activities that still have to be done.The history of a case can also be retrieved from the Case Guide.

Monitoring the WfMS

FLOWer provides a graphical overview for the number of cases that are assigned to a userthrough the case monitor. The administrator can choose the form of the representation table,2-or 3-dimensional bar chart or pie chart. The Case monitor makes use of specific worklists.FLOWer has a specific escalation-worklist for managers. This list contains all the cases wheresomething went wrong and needs attention from a manager or administrator. There is also aspecific worklist for cases that have reached a deadline and where a reminder needs to be sent.

3.6 FLOWer 55


The FLOWer Coolbar also has a shortcut to the FLOWer administration tool. With this tool newusers can be created as well as new contexts, context administrators, case queries, sorting groups,work-, function-, and distributionprofiles. These profiles allow for specifying who (role/user) isallowed to do which cases. A user can only see the case queries that it has been assigned. Theroles must have been defined in the FLOWer studio.

The administration tool helps the administrator to specify how cases should be allocatedand to deal with the authorisation of users. Cases can be allocated on the basis of work itemstatus, roles or data elements. FLOWer has an internal login service to authenticate users, butexternal login services like LDAP can also be used with FLOWer.

An organisation can be divided into different groups based on location or users with similarroles. These groups can be used when allocating work. The Administration Tool mostly dealswith allocation issues, adding of new users and specifying their access rights.

If the administrator deletes a user another user has to be defined as a replacement. Thecases from the deleted user will then be taken over by the replacement.

Audit Trail

The history of a case can be viewed through the case guide.


FLOWer does not make use of the concept of a working day.

3.6.3 Special Features FLOWer

This section describes functionality offered for the workflow administrator that can only befound in FLOWer.

Connection Monitor

The Connection monitor gives an overview of all the connections to the FLOWer server andallows the connections to be terminated.

skip, redo & pre-do

FLOWer allows users to skip, redo or pre-do work items. If a work item is repeated this mighthave an effect on the case and FLOWer can recalculate the system decisions. System decisionsare based on data provided during the case and they influence the path that is followed throughthe process definition. If a work item is changed that is in front of a system decision FLOWerwill automatically recalculate the decision. Decisions made by a user can also be changed later.

Escalation of cases

A case can be escalated by a user. The case will then be assigned to the manager of the user.



In Figure 3.11 the OR-model for FLOWer is shown.The FLOWer specific term ’Case Type Processes’ is replaced by ’process definition’ and the

term ’Case Instance’ is replaced by ’Case’ in the model. The term ’process element’ is replacedby ’work item’. The concepts used in FLOWer are very similar to the models of the previoussystems so we will not repeat the common relations between process definition, activities, casesand work items. The unique factor of FLOWer is that it is case-driven but this cannot berepresented in the OR-Model.

FLOWer has a unique way to authorise users. The way the authorisation works is shown inFigure 3.12. The administrator can specify function profiles and distribution profiles. Roles andusers are connected through function profiles. By adding users and roles to the function profilesthey are automatically connected to each other and a user performs the roles added to the samefunction profile. A distribution profile is a collection of case queries and users that determinewhich users can do which cases. Function profiles and distribution profiles can be connected towork profiles. Work profiles thus form an authorisation and task framework by combining theuser-role connections and the user-case connections.


FLOWer does not provide any analysis methods. The Case Guide can be used to check thestatus of a case. The Case monitor can be used to get an overview of all the ongoing cases. Theonly reporting functionality is the possibility to print the history of a case through the CaseGuide.

3.7 COSA

The version we used for the analysis is COSA Workflow Version 4.2. The manuals reviewedare the COSA 4 Administrator’s Guide [Tra03a], the COSA 4 Business-Process Designer’sGuide [Tra03b] and the COSA 4 User’s Guide [Tra03c].

COSA is based on Petri-net theory and has extensive possibilities for managing businessprocesses [AH02]. The COSA Workflow Management System consists of separate componentsthat are structured in a modular way so that the system is easily upgradeable and the modulescan be easily combined. COSA Workflow is part of the COSA family that also includes COSAArchiv, an archiving system and COSA FlowModeler. FlowModeler has three main modelingtools: Network Editor, User Editor and the Simulator.

The COSA Workflow Server is the central component inside a COSA system that holdsthe workflow engine and the workflow database. The database stores the process definitionattributes as well as the folder, process instance and activity instance attributes.

3.7.1 User Types

COSA has two different user types:

User: The user that has access to the worklist.

3.7 COSA 57

Figure 3.11: FLOWer OR-Model


Figure 3.12: Authorisation in FLOWer

Workflow Administrator: COSA has one privileged user; the workflow administrator. Theworkflow administrator is responsible for user administration, group definition and grantingaccess rights.


This section will describe the functionality that COSA offers for a workflow administrator.

Access Control

There are two types of access rights in COSA: access rights assigned to users and access rightsassigned to objects.

A user can be a member of one or multiple groups in several organisational models. Accessrights and authorisation for users and groups is specified in the process definition. The accessrights are passed on from top to bottom in an organisational model. So if a group gets certainaccess rights and another group is a member of that group all the users in that group alsoreceive the access rights. For special management tasks like distributing and rerouting workitems, delegating work items to other users, redistributing, skipping or resubmitting work itemsa user needs to have the proper access rights.

When a process definition is created you can assign a group or user to each activity, specifywhich management actions (delegation, skipping etc.) can be carried out on the activity andwhich users are allowed to do these management actions. The following access rights to activitiesare defined:

• changing priority allowed

• skipping allowed

• rerouting allowed

• undoing allowed, the results of the activity are discarded and the activity has to be doneagain

• delegation allowed

• reservation allowed, the activity is not started yet by a user but he commits himself to dothe activity at some point

• redistribution allowed

3.7 COSA 59

The users themselves can have authorisation or distribution rights or both. If a user only hasauthorisation rights it means he can carry out work items but cannot see them in the worklist.If a user has distribution rights it means he can see the work items on the worklist but he cannotcomplete them. To be able to carry out a work item a user thus needs both access rights. To beable to perform a certain action on a work item a user has to have the right access rights andthe properties of the work item have to allow it.

When the actions rerouting, reservation, delegation, redistribution or rejection are executedthere are special rules for transferring the access rights. When a user reroutes a work item toanother user he gives his distribution right for that work item to the other user. When a userreserves a work item because he wants to do it the authorisation right is withdrawn for all theother users that had access to the same work item. They can still see the work item but theycannot carry it out anymore. In the case of delegation both access rights are transferred to theuser that the work item is delegated to. When a case gets into an unstable state a user candecide to redistribute the case. This is only allowed if all the activities in the case have theredistribution access right allowed and the user has the right to redistribute. This additionalright can be assigned by the workflow administrator. Other additional rights are the right tochange priorities and the right to create activity journal tables.

If a user cannot carry out a work item because there is information missing or there is anotherreason then the user can reject the work item. A screen will appear on which the user can enterwhy the work item has been rejected and the work item will then be sent to the process managerworklist. A process manager has to be appointed.

The user-related access rights and the activities-related access rights can be supplementedby defining user competencies.

COSA allows higher-level groups or supervisors to see which work items have to be carriedout by the users in the lower hierarchical levels.

Procedure Definition Management/Version Control

The Network editor is the tool that allows modeling of the business process based on Petri-nettheory to store the process definition in the database.


The User Editor helps to define the organisation model by modeling users, groups, departmentsand supervisors in a hierarchical way. There are two different ways to look at an organisation,the disciplinary-oriented view and the role-oriented view. Looking at the organisation in termsof departments, groups, users and supervisors according to the different levels in the organisationis the disciplinary-oriented view. Looking at the competencies, abilities, capabilities, responsi-bilities, authorities and skills of a user is the role-oriented view. Both views can be combinedin COSA to create the organisational model. When the organisational model is defined it isused to grant and administer access rights, distribute the work items among the users and togenerate statistics. With the User Editor the administrator can also directly change the mostimportant user attributes.


Case & Work item Management

The COSA Workflow Processing Client consists of the Worklist Handler and the Network Dis-player. The Network Displayer is a graphical tool that displays the current status of cases.

The Network Displayer shows the status of a case graphically. This is done by displayingthe Petri net and its tokens. This tool can thus also be used by the workflow administrator tomonitor a case and identify problems.

In the network displayer it depends on the access rights of the user which cases the usercan view. The access rights can be set depending on whether the user is/was the creator ofthe case, is/was the owner of the case or whether he has/had a work item in his worklist. Theadministrator can also authorise a user to view the status of all cases.

The worklist handler displays the work items, the folders and the cases that are allocatedand accessible to the user. User can start, skip, postpone, resubmit, reroute, redistribute,delegate, reserve and reject the work items through the worklist handler. Cases can be launched,postponed, resubmitted, rerouted, redistributed, delegated and reserved and folders can beresubmitted, postponed, rerouted and renamed. Statistical data can also be retrieved andjournals can be created. The status of a case can be checked using the network status functioninside the worklist handler. The work item description can be displayed in different languagesso that users with different nationalities can read the descriptions in their own language.

Monitoring the WfMS

The worklist handler can be viewed in two modes, worklist mode or resubmission mode. Theworklist mode displays all the folders, cases and work items that are still to be carried out. Theresubmission mode displays all the postponed folders, cases and work items.

Database Management

The Workflow System Administration (WSA) Tool is the interface to the workflow databasefor the workflow administrator. The WSA allows the administrator to access and modify thedatabase to control the business processes and intervene if necessary. It also supports theadministration of all organisational data. Adding users and their authorisation rights is donethrough the WSA as well as the planning for substitutions in case a user goes on leave. Theadministrator can also generate statistics on average processing time of cases, average timeneeded for single work items, etc. Special queries can be defined in the WSA to display only aselection of work items in the worklist handler of an user. The WSA has a delete wizard to helpthe administrator in deleting an entry from all relevant tables so that data consistency remains.


An activity journal displays all the work items that have been performed. The workflow admin-istrator can set the access rights to create and view an activity journal. Whether a user cancreate an activity journal report or not depends on whether the user is/was the creator of thecase, is/was the owner of the case, whether he has/had a work item in his worklist, whetherthe user is the owner of the work item or whether the user is the one executing the work item.

3.7 COSA 61

COSA registers all executed actions and errors conducted by the system or the users. The logfiles therefore can help in improving the business process.

Changing Priorities

A priority can be assigned for folders, cases and work items. Priorities are mainly used to definea hierarchy in a work list. If folder and case priorities are defined, these values are automaticallyadded to the work item priority. The priority of a work item can also be changed during runtimeif the activity that the work item is an instance of has the action of changing priority enabled.The user who wants to change the priority must also have the access rights to do this. Theserights can be assigned by the workflow administrator.

Defining substitute user

Through the worklist handler the personal calendar can also be accessed. In this calendar a usercan specify periods of absence and whether someone should act as a substitute.

COSA provides two methods for substituting absent users: an auto-reroute mechanism andsubstitution of absent users. The auto-reroute mechanism makes sure that the work items forthe absent user are automatically rerouted to the substitute user. This user cannot start newcases on behalf of the user that is absent. The user who will be absent has to have the right toreroute work and rerouting must be allowed for the work items. A substitute can be grantedvarious rights: administrative rights and rights to read work items, to see and carry out workitems, to change the priority of work items and to reroute work items. The user that is goingto be absent also has to specify the period that he is going to be absent into the worklistpersonal calendar. The substitute user has to have the authorisation right for the rerouted workitems. The workflow server must be configured to check absence. The auto-reroute method ofsubstitution requires thinking in advance about substitutions and access rights when the processdefinitions are created.

The other method for substitution requires less thinking in advance but requires more actionsfrom the substituting user. The substituting user can log on to the worklist of the absent user.The work items are then displayed and can be carried out as usual. With this method thesubstitute user can also start new cases on behalf of the absent user. The only thing that hasto be done beforehand is defining the substitute user as a substituent for the absent user. If awork item is rejected it gets rerouted to the case manager.


COSA uses the full business calendar and also provides the easiest way to define working andnon-working days. It provides a screen with an overview of all the days in the year and theadministrator can simply define the type of each day by entering a code in the field for each day.

3.7.3 Special Features COSA

This section describes functionality offered for the workflow administrator that can only befound in COSA.


Simulator Tool

The Simulator helps to optimise and improve the processes by running a simulation on theprocess definition to analyse locks, bottlenecks and resource problems. The simulator can visu-alise the resource consumption of one activity or of all activities and visualise bottlenecks by thequantity of tokens on a specific state. This tool can be helpful to simulate holidays and missingresources beforehand and prevent bottlenecks during those times.


The database of COSA stores and administers data about the process definitions and the organi-sation models, the administrative information on cases and the journals for generating statistics.In total there are 58 tables stored in the database subdivided over nine categories.

The data collected relevant for a workflow administrator is captured in an OR-model. Thefirst part of the model for COSA is shown in Figure 3.13. A user creates a process definition anda user is also assigned to be the process manager of a process definition. If something goes wrongwith a work item during the execution of a case this work item will be placed in the worklist ofthe process manager. A process definition can go through a number of states before it is expiredand a newer version will replace it. A process definition consists of activities that can be of acertain type. An user can access and change process definition attributes, case attributes andfolder attributes. Whether read or write access is allowed depends on the access rights grantedfor these attributes.

The second part of the COSA OR-Model is shown in Figure 3.14. A user can start and enda case. When a case is started the user can create a folder or specify the folder that the casebelongs to. A folder is a logical group of cases. The cases do not have to be from the sameprocess definitions but can be cases for one customer, for example. A folder has a name and adescription. A case can only belong to one folder at the same time. A folder and a case can alsobe given a priority. The priority of the work item is determined by the priority specified for thework item itself plus the values for the folder and case priority that the work item belongs to.A case can have a deadline and a status and is also identified by a number and a name.

Figure 3.15 shows the last part of the COSA OR-Model. A work item is an instance ofan activity, is identified by a name, is part of a case and has a description. A user with theappropriate access rights can perform actions on a work item like skipping, redoing etc. Theway the authorisation works was already described in chapter 3.7.2. A work item can also havea deadline. If the deadline expires the work item will appear in the list of the supervisor.


Users have to analyse the journals themselves to produce useful management information as men-tioned in [Tra03a]: ”If you analyse the journals you can evaluate the history of a folder/processinstance/activity instance for statistics and security purposes”.

Journals store all workflow system data of folders, process instances, and activities as wellas all security-relevant information, such as login, logout and password changes. There are noreporting tools provided.

3.8 Summary Existing WfMS 63

Figure 3.13: COSA OR-Model part 1

3.8 Summary Existing WfMS

This section will compare the functionality the different WfMSs offer, the data that they storeand the reporting and analysis methods they offer.



3.8.1 Functionality

An overview of the functionality supported by the different systems is provided in 3.1.



From this table we can conclude that all the systems offer the basic functionality like processdefinition, case and user management but the other functionality offered by the systems differsa lot. This is also caused by different interpretations of what the tasks of an administrator are.


Functionality Sta

ffw

are

MQ

Web

spher

e

FLO

Wer

CO

SA

iPla

net

I-Flo

w

User/Group/Role Management x x x x x xSpecifying who can start a case x xViewing the Audit Trail x x x x x xDelete Audit Trail Entries xConfigure Audit Trail x xDefine authorisation rights x x x x x xChanging Case status x x x x x xReroute Work Items x x x xChange priority of Work Items x x xView escalated work items x x xMonitor the ongoing cases x x x x x xManage process definitions x x x x x xDefine Reports x xView Reports x x xPrint Reports x xDefine substitute users x xSet Working Days x x xSet Working Hours xSearch cases x x x xConfigure Worklist x

Table 3.1: Support for Workflow Administrator Functionality in Workflow Systems

Some of the systems do not differentiate properly between a system administrator and a workflowadministrator. Some of the systems offer more advanced functions for workflow administratorslike defining substitutes and allowing redirection of work items from one worklist to the other.There is also a lot of differences in defining access rights. MQ Websphere and COSA have avery comprehensive system to determine which user can do certain actions but most systemsuse a simpler model.


Looking at the models we can say that the basic objects are all the same in the different WfMS.They all have the concept of process definitions, activities, cases, work items and record thesame things about these objects like creation time and the times that the status changed.

Looking at the different WfMS we can say that the following categories of data are storedto support the functionality offered by the WfMS:

• Process Definition data; data stored about a business process, which activities have to beperformed in which order, who made it etc.

• Case data; data storing the status of a case, who the supervisor is etc.

• Activity data; data storing priority of the activity, who can do the activity etc.


• Organisational Model data; user and authorisation data - Who has read/write access towhich data?

• Logging data; who performed which activity at what time? etc.

• Time data; what are working days and what are the working hours?


The analysis methods that the systems offer are rather poor. Most systems do not provide ananalysis tool but the data can be analysed by third party analysis tools. The analysis methodsare usually based on SQL queries over the database. The most sophisticated analysis andreporting tool is offered by I-Flow by the use of a data warehouse. Only COSA has a simulationtool to analyse the workflow.

MQ Workflow and Staffware offer the possibility to make or view reports. I-Flow providesthe most advanced reports. Some of the systems offer overviews of performance indicators butmost of them are system indicators and not specifically tailored for a workflow administrator.


Chapter 4

Functional Requirements

This chapter describes the functional requirements for an administration and monitoring tool.The functionality will be grouped together and example queries and updates will be providedto describe the functionality.

4.1 Management of Organisational Data

To be able to assign work items to users, information about the organisational structure hasto be known in the workflow management system. Users, groups and roles and their accessrights need to be entered into an organisational database which can then be used to determinewhich users are suitable for certain tasks. Entering organisational data is done in the workflowadministration and monitoring tool.

4.1.1 Role Management

A user performs one or more roles related to the position in the company. These roles havecertain access rights and privileges associated with them. These role attributes need to beentered into the organisational database by the workflow administrator. Roles can change overtime, these changes are made in the organisational database by the workflow administrator.

Update Example

When an extra privilege is added to a role the users who perform that role now have an extraprivilege. This can mean they can perform an additional task. It has no effect on ongoing tasks.

4.1.2 User Management

Users of the workflow management system need to be entered into the organisational databaseand roles have to be assigned to them. Access rights can be assigned to specific users or can beinherited from the role the user performs. A substitute user for when a user is absent can alsobe defined. The properties of a user such as capabilities or position can change over time whena user gets promoted, the properties then need to be changed. A user needs to be deleted fromthe system upon leaving a company.

70 4 Functional Requirements

Update Scenarios

When an employee is promoted, the properties for him/her need to be updated. An issue isthat ongoing work items that were assigned to this employee should be reassigned or delegatedby the employee or the workflow administrator.

When a new user is added to the system all the properties, such as the access rights, group,roles and capabilities, need to be entered into the organisational database for him/her. Addinga new user has no effect on the process instances that are already running.

When a user is deleted from the system there has to be decided what is to be done with thework items that were already assigned to this employee. These ongoing work items should bereassigned or delegated by the employee or the workflow administrator.

When a users authorisation rights are changed the access to work items and attached documentswill have changed for him/her. All work items that are not yet allocated will be allocated usingthe new access rights of the user. Already allocated work items need to be reassigned by theworkflow administrator if necessary.

When a user is going on a holiday for two weeks a substitute user can be defined. All workitems will then be assigned to the substitute user during the specified time period. The workflowadministrator will have to keep in mind that the substitute user needs to have the appropriateaccess rights or the access rights have to be transferred or temporarily assigned as well.

4.1.3 Group Management

Often users with a similar role are grouped together in the WfMS to manage them more easilybecause they often have the same properties. Groups of users need to be defined in the systemby the workflow administrator. The access rights and privileges of the group have to be set andare inherited by all users in the group. The groups and their properties can change over timeand are managed by the workflow administrator.

Update Example

The access rights for a certain group need to be extended because they are going to performadditional tasks. The extension of access rights has no effect on ongoing work items, it wouldhave an effect if the access rights would be reduced. The workflow administrator then mighthave to reassign the work items if there is no suitable user left.

4.1.4 Business Calendar

The WfMS could make use of the concept of working days and hours when allocating work itemsto users or when handling timers.

4.2 Audit Trail Management 71

Usage Example

The working hours will be extended because it is peak time. The workflow engine will alsoallocate work items to users during the new working hours. It has no consequences for theongoing tasks.

4.2 Audit Trail Management

The audit trail logs all the changes to the process instances in a database with information onwhen it happened and who performed the action that triggered this change. The audit trailcan grow very big and therefore old logs need to be deleted occasionally. In some WfMS theworkflow administrator can configure which events should be stored to keep the size of the audittrail database under control.

Query Example

The workflow administrator wants to see all the audit trail entries from now until one week agofiltered on a resource.

Update Example

To manage the size of the audit trail the workflow administrator deletes all the audit trail entriesolder than a year.

4.3 Process Definition Management

After a process definition has been created the definition needs to be migrated from buildtimeto runtime. The workflow administrator needs to register the new process definition with theworkflow engine and take care of version control. For example, it may be possible that during acertain period of the year one particular version of a process definition is valid (peak time) andduring the rest of the year another process definition is valid. The workflow administration andmonitoring tool will provide an overview of the different process definitions, allow for register-ing/unregistering process definitions and the status of a process definition can be changed.

Update Example

A new version of a process definition is registered to improve the process. Ongoing cases willcomplete according to the old process definition and new cases follow the new process definition.After all the old cases have completed the old process definition gets the status obsolete.

4.4 Reports

Management would like to know how the business processes are going. The workflow adminis-trator should be able to create some reports for management. He can select which things should


be included in the report and generate the report automatically. Management could also createreports themselves if they are given access to that part of the administrator tool.

An example of a report can be an end-of-the-week report displaying the number of casesthat were completed for each case type and the average workload for the different resources.

4.5 Monitoring

The workflow administrator needs to have an overview of all the running cases and the underlyingactivities so that problems can be detected. This overview can best be given using a graphicalrepresentation. In this way the workflow administrator can see at once what the status ofthe different cases, activities or resources is. He can then decide whether to undertake anaction to change the situation. The workflow administrator can select which data he wantsto have displayed and can thus search for the specific information he needs. The workflowadministrator can also look at details of a specific case or activity and view the history. He willalso automatically receive work items in his worklist when the work item cannot be assigned toa user so the workflow administrator can reassign the work item to a suitable user manually.

4.5.1 Displaying Case information

An important source of information for the workflow administrator is to identify whether thereare any problems will be the graphical overview screen with information about the execution ofcases. The workflow administrator can select what case information to display.

Query Examples

- Display the number of cases completed this week and the number of cases that are still running.

- Display the average completion time for the different process definitions.

- Display the average waiting time for the different process definitions.

- Count the completed cases between X and Y (where X and Y are dates).

- Count the number of cases that were not finished on time (so finished after the deadline haspassed) between X and Y (where X and Y are dates).

- Count the number of cases that were finished on time between X and Y (where X and Y aredates).

- Display all the cases for which a deadline approaches (within 2 days).

- Display the number of cases that were processed per day for the last week.

- Display all the cases that haven’t changed for the past X hours/days/weeks (depending on thetype of case).

- Display a summary of the status of the cases (ready, suspended, running, completed, aborted,terminated).

- Count the number of cases completed grouped per case type since X (where X is a date).

- Display those cases whose cycle time exceeded the average cycle time by more than a week.

- Display the cases that took more than X days (or hours, mins, etc.)?

4.5 Monitoring 73

4.5.2 Displaying Resources Information

Information about the workload of the different resources is another important overview for theworkflow administrator.

Query Examples

- Count the work items completed today for every user.

- Display a list of processing times for a specific activity per user (can help to determine towhom you should allocate an activity).

- Display a list of the workload (number of tasks) in the worklist for the different resources.

Which resources are over utilised or under utilised?

4.5.3 Displaying Work Items for the Workflow Administrator

When something goes wrong during the allocation of work items to a resource, the work itemwill appear in the worklist of the workflow administrator so that the problem can be resolved.

Query Example

- Display a list of all the work items that have been escalated.

4.5.4 Activity Information

When a case is not running smoothly it can be because of a certain activity that is too compli-cated. The workflow administrator therefore needs to be able to interrogate activity information.

Query Examples

- How many times was an activity (instance) skipped/delegated/redo/predo etc. this week/month?

- Display a summary of the status of the activities within a certain case/type of cases (suspended,available, not working, working, aborted, completed).

- Display the current status of all the work items in case X.

- Display the average waiting time for each work item.

- Display the work items that took more than X days (or hours, mins, etc.)?

- Most of these queries can also be used in reports for management.

4.5.5 Prediction/Explanation

In the future incorporating data mining techniques into the workflow management systems willbe very common and more functionality will then be available for the workflow administratorin the form of predictions, explanations and simulations. The system will provide explanationswhy certain situations occurred that help the workflow administrator with the analysis of theproblem. The system can also make predictions based on historical data on what will happen inthe upcoming period. In the future automated remedial actions can be defined by the workflowadministrator so that the system can react to problems automatically when it recognises a


problem that occurred before. Simulation of what will happen when the WfMS is configured ina certain way and with a number of constraints will also be part of future systems.

Query Examples

- Which cases regularly lead to missed deadlines?- Display the number of cases and the case types are likely to be delayed next month.- Predict the number of cases for every process definition for next month.- Why does this situation occur at that time? e.g. Why are more cases delayed at the end ofthe month?- Which cases are likely to get stuck?- Activities that are typically checked-out, checked-in together?

4.6 Change Management

When a problem is detected the workflow administrator may undertake a remedial action. Hecan change the allocation strategy, change to another process definition, set a maximum of casesthat can be instantiated or a maximum of work items that can be allocated to one resource,suspend, terminate or resume cases or their activities or reassign work items if the workload ofa resource is too high.

4.6.1 Case Management

The workflow administrator can change the status of a case. He can set a maximum number ofcases that can be run concurrently or he can terminate all cases of a certain type.

Update Scenarios

A case needs to be aborted. The remaining tasks will disappear from the worklists and thecancelation will be logged.

All cases of a certain case type need to be suspended. Change the status of all the cases of thatcase type to suspended. All the work items belonging to those cases will be suspended as well.

4.6.2 Work Item Management

The workflow administrator can change the priority of a particular work item so that the workitem will be completed earlier. This can be useful when the deadline for a certain case ap-proaches. A work item can be reassigned, suspended or aborted by the workflow administratorto prevent bottlenecks.

Update Examples

- Abort/suspend/resume work item.- Increase the priority of the work item. The work item will then appear higher in the worklistof the user/group.

4.7 Configuration 75

- Change the allocation strategy (e.g. push/pull/round robin etc.) because the workload isnot distributed evenly. The work items will be allocated by the workflow engine using the newstrategy.- A work item needs to be reallocated. Reallocate the work item to the appropriate resource(s).The task will disappear on the worklist for the previous resource and appear in the worklist fora suitable resource.

4.7 Configuration

The workflow administrator can configure some settings in the workflow system beforehand. Hecan select that the priority of a work item should increase with a certain value every workingday. He can specify what the worklists of the different users should look like, what details needto be displayed and how it should be ordered. For example, per case type or highest priorityfirst etc. To prevent the logging database from becoming too big the workflow administratorcan also specify which events should be logged.

4.8 Third Party Software

Third party software can be used for additional administration functionality if it is compatiblewith the data format used in the workflow management system. Such software could be adatabase, web services, data mining tools, reporting tools etc.


Chapter 5

Design

In this chapter we will construct an OR-model for the data relevant for workflow administrationand monitoring in the YAWL environment. The model will be created using the OR-modelsdescribed in Chapter 3 and by using the model for organisational data in [RHEA04]. Missingparts will be modeled and OR-models that already exist for the YAWL environment will beadapted. After the OR-model is constructed we will translate this model to a relational model.The design for the different screens of the tool will be shown in the last section together withthe SQL queries that are supported by these screens. The SQL queries are written in SQL 99.

5.1 Conceptual Model

The conceptual model for the data that is needed for the workflow administration and monitoringtool in the YAWL environment is presented in Figures 5.1-5.4. Some of the terminology usedby YAWL is different from the terminology of the WfMC. The terminology of the WfMC willbe used in the model but we will mention the corresponding YAWL names in the description.Each of the OR-Models will be discussed separately.

Process Definition & Activities

Figure 5.1 the concepts related to process definitions are displayed. A process definition(called specification in YAWL) has a description and a valid from and a valid until date.It is also stored who created the process definition and at what time. The status of a processdefinition changes from active to old when a newer version is uploaded. The version number

indicates which process definition is the newest. Process instances that are already runningwill complete according to the old process definition. New started instances will follow the newprocess definition that will have the status active. When the status of a process definition isobsolete it means that all the old instances have completed and the process definition is nolonger used. A process definition consists of activities (tasks in YAWL). Activities have adescription to help identify what the task is. A process definition is created or changed by aHuman Resource. A service has a URI to identify it and has a description indicating what theservice does. A service could also change the status of a process definition.

78 5 Design

Figure 5.1: YAWL OR-Model part 1

Cases

An instance of a process definition is called a ’case’ or ’process instance’. Figure 5.2 displaysall case-related information that needs to be captured. A case consists of activity instances.Activity instances are called work items. A case can have subcases and a deadline and iscreated by a resource or a service at a point in time. When the status of a case changes thetime and who caused the change is also stored. The case data document stores all the globalvariables for a case. Whenever the variables change the whole case data document is storedagain. When a work item starts and finishes the values of the variables are also stored becausethe work item could have changed the value of the variables. A work item can also be a parent

of another work item in YAWL. Whenever the status of a work item changes the time andresource who caused the change are stored. If an external service cancels a work item theusername that the service uses to log into YAWL is logged. To identify which service caused the

5.1 Conceptual Model 79


event the username should be related to the name of the service. A case, activity and work itemcan have a priority assigned. This priority indicates how urgent it is to complete the workitem that is an instance of a corresponding activity and part of a certain case. The priority ofa work item can therefore be derived from the priority values for the case or activity the workitem is related with by adding the two values. The value can also be adjusted independently

80 5 Design

during workflow execution by the workflow administrator if necessary.

Business Calendar


In Figure 5.3 we modeled that an organisational group can work on different days andtimes as another group in the same organisation. There are also a few national holidays in theyear that are an exception to the general working days. If the WfMS has knowledge about thebusiness calendar of an organisational group the workflow engine can allocate work items ac-cordingly. An organisational group can be a team but also a branch or division and can containother organisational groups.

5.1 Conceptual Model 81

Organisational Model


A resource is of type human or non-human and can have a capability. A capability canbe a special feature of a particular resource. For example, a particular manager can approveorders until the value of $100,000. A human resource is a subtype of a resource and has agiven- and a surname. A human resource will also need a password to access the WfMS andthe workflow administrator can specify which tools (e.g. worklist, administration tool) of the

82 5 Design

WfMS the human resource can access. A human resource occupies one or more positions in theorganisation. These positions include roles the human resource must perform but additionalroles that the human resource performs can also be defined. A role can incorporate another roleand is identified by a name. A position can be part of an organisational group. It can be definedper activity if a certain action (skipping, suspending etc.) is allowed and which role, positionor human resource is allowed to do that action. This is described in the textual constraintsin Figure 5.4. Human resources or positions can delegate activities to other human resourcesor positions. Whether they can delegate can be defined in general or specifically for certainactivities when defining these activities in the YAWL editor. A resource or position can have asubstitute resource or position defined if it is known beforehand that the resource or position isnot available during a certain time period.

5.2 Relational Model

The relational model was created using the OR-model as a basis and can be found in Figure 5.5.Since the relational model is the model for the database that will be used in the YAWL environ-ment the YAWL terminology will be used here. The following tables already existed for loggingand persistence purposes:

• logdata

• workitemevent

• runner busy tasks

• runner enabled tasks

• runner states

• CaseDataDocument

• Yidentifiers

• Locations

• spec

• Work Items

• logidentifiers

HasPriority and hasDeadline have been added to the logidentifiers table. HasPriority has alsobeen added to the Work Items table. All the other tables are new and have been created tosupport the organisational model and functionality for the administration and monitoring tool.These tables were constructed using the conceptual model described in Chapter 5.1.

The logging and persistence tables are created automatically when starting the YAWL engine.All the tables are created in the same database but there will not be foreign keys between thelogging and persistence tables and the organisational tables. This allows for changing to anotherdatabase for organisational data in the future such as LDAP.

5.3 Interfaces 83

5.3 Interfaces

This section will show the design of the administration and monitoring tool for the YAWLenvironment. These screenshots give an indication of what the tool is going to look like. Theactual implementation can differ from the screenshots since a graphical tool was used to drawthe design of the screens and these screens are not actual screenshots taken from the tool to beimplemented. Some screens of the actual implementation can be found in Chapter 6.

To illustrate the functionality of the different screens the underlying SQL queries that sup-port the functionality are included in the description of the screens. The updates have not beenwritten down in SQL since they all have the same format:UPDATE <table>SET <columnname> = <new value>WHERE <condition>;The only important thing to remember when doing an update is to also update the tables thathave foreign keys to the table that is being changed.

5.3.1 Overview Screen

The overview screen will provide the administrator with graphical overviews to quickly identifywhether there is a problem and is shown in Figure 5.6. A number of queries that might beof interest for the workflow administrator will be defined beforehand so that the query can beselected from a drop down list. The workflow administrator can select which representation hewould like to view the requested data. The time period for the data to be retrieved can beadjusted.

Case-related overview queries

The following queries related to cases are supported by the overview screen:

Display the number of cases completed this week and the number of cases that are

still running:

SELECT COUNT(completed)FROM logidentifiersWHERE 7 >= EXTRACT (day FROM (current timestamp - completed))UNIONSELECT COUNT(case id)FROM logidentifiersWHERE completed IS NULL;

Display the average completion time for the different process definitions:

SELECT AVG(completed-created), specification

84 5 Design

FROM logidentifiersGROUP BY specification;

Count the completed cases within the time frame...:

SELECT COUNT(completed)FROM logidentifiersWHERE completed BETWEEN ’YYYY-MM-DD’ AND ’YYYY-MM-DD’;

Count the number of cases that were not finished on time in the time frame...:

SELECT COUNT(completed)FROM logidentifiersWHERE hasdeadline<completed AND completed BETWEEN ’YYYY-MM-DD’ AND ’YYYY-MM-DD’;

Count the number of cases that were finished on time in the time frame...:

SELECT COUNT(completed)FROM logidentifiersWHERE completed<hasdeadline AND completed BETWEEN ’YYYY-MM-DD’ AND ’YYYY-MM-DD’;

Display all the cases for which a deadline approaches (example: within 2 days):

SELECT *FROM logidentifiersWHERE 2 > EXTRACT (day FROM (hasDeadline - current timestamp)))

Display the number of cases that were processed per day for the last week:

SELECT COUNT(completed)FROM logidentifiersWHERE 7 >= EXTRACT (day FROM (current timestamp - completed))GROUP BY completed;

Display all the cases for which the status didn’t change for the past...hours/days/weeks

(example: last week):

SELECT *FROM CaseStatusChangeWHERE 7 >= EXTRACT (day FROM (current timestamp - DateTime));

5.3 Interfaces 85

Display a summary of the status of the cases (suspended, resumed, completed, can-

celed:)

SELECT COUNT(casestatus), casestatusFROM CaseStatusChangeGROUP BY casestatus;

Note: A case can be counted multiple times when it was suspended and resumed before it wascanceled or completed.

Count the number of cases completed grouped per process definitions since...:

SELECT COUNT(caseid) AS numberofcases, specificationFROM logidentifiersWHERE completed >=’YYYY-MM-DD’GROUP BY specification;

Display those cases whose cycle time exceeded the average cycle time by more than

a week:

CREATE VIEW cycletime ASSELECT EXTRACT (day FROM (completed - created)), case idFROM logidentifiers;

SELECT case idFROM cycletimeWHERE 7 < date part - (SELECT AVG(date part) FROM cycletime);

Display the cases that took more than X days (or hours, mins, etc (example: more

than 5 days):

SELECT *FROM logidentifiersWHERE 5 > EXTRACT (day FROM (completed - created));

Resource-related overview queries

The following queries related to resources are supported by the overview screen:

Count the work items completed today for every user:

SELECT COUNT(event), resource

86 5 Design

FROM workitemeventWHERE 0 = EXTRACT (day FROM (current timestamp - time)) AND event=’completed’GROUP BY resource;

Display a list of processing times for a specific activity per resource

SELECT (b.time - a.time) as processingtime, a.taskid, b.resourceFROM workitemevent a JOIN workitemevent bON a.taskid = b.taskid AND a.identifier = b.identifier AND a.time < b.timeWHERE b.event = ’completed’ and a.event = ’executing’GROUP BY b.resource, b.time, a.time, a.taskidORDER BY b.resource;

Display a list of the workload (number of tasks) in the worklist for the different

resources:

SELECT COUNT(id) AS workload, who started me AS resourceFROM Work Items WHERE who started me IS NOT NULLGROUP BY who started me;

Which resource is over utilised? (or under utilised?):

CREATE VIEW workloadresources ASSELECT COUNT(id) AS workload, who started me AS resourceFROM Work Items WHERE who started me IS NOT NULLGROUP BY who started meORDER BY workload;

SELECT MAX(workload), MIN(workload) FROM workload;

SELECT resourceFROM workloadWHERE workload = <maxvalue>;

SELECT resourceFROM workloadWHERE workload = <minvalue>;

Activity-related queries

The following queries related to activities are supported by the overview screen:

5.3 Interfaces 87

Display a summary of the status of the work items within a certain case/type of

cases:

SELECT COUNT(id), statusFROM Work ItemsWHERE id LIKE ’<casenr>.%’ORDER BY status;

To give the summary of the status of the work items within a certain specification:

SELECT COUNT(id), statusFROM Work ItemsWHERE specs = ’<specnr>’ORDER BY status;

Note: This list will only include the work items that have not completed yet.

Display the current status of all the work items in the case...:

SELECT id, statusFROM Work ItemsWHERE id LIKE ’<casenr>.%’ORDER BY status;

Display the average waiting time for each work item:

SELECT (b.time - a.time) as waitingtime, a.taskid, a.identifierFROM workitemevent a JOIN workitemevent bON a.taskid = b.taskid AND a.identifier = b.identifier AND a.time < b.timeWHERE b.event = ’executing’ and a.event = ’enabled’GROUP BY a.taskid, a.identifier;

Display the work items that took more than X days (or hours, mins, etc.)?:

SELECT (b.time - a.time) as processingtime, a.taskid, a.identifierFROM workitemevent a JOIN workitemevent bON a.taskid = b.taskid AND a.identifier = b.identifier AND a.time < b.timeWHERE b.event = ’completed’ AND a.event = ’executing’ AND <days> >= EXTRACT (dayFROM (b.time - a.time))

88 5 Design

5.3.2 Organisational Data Screens

We will describe the design for adding data to the organisational database in this section.

Adding Resources Screen

In Figure 5.7 the screen for adding Resource part of the organisational data section is shown.The organisational data section can be used to enter resources, groups roles, positions, capa-bilities and substitutions. After clicking on the menu bar on the left the requested screen willappear. Data entry is made as easy as possible by providing drop down boxes, that allow youto select the right option(s), when possible.

Editing Resources Screen

Figure 5.8 shows the screen for editing resources. After selecting the resource that needs to beedited the properties belonging to that resource appears in the matching fields. The propertiescan then be changed or the resource can be deleted.

The screens to add and edit groups, roles, positions and capabilities look similar as the addresources and edit resources screens, therefore we have not included these screens.

Updates Supported

When an employee gets promoted, the properties for this employee need to be updated. Anissue is that ongoing work items that were assigned to this employee should be reassigned ordelegated by the employee or the workflow administrator.

When a new user is added to the system all the properties for this user need to be entered intothe organisational database. Their has to be defined to which group the user belongs, whichroles he performs, which capabilities he has, which access rights he has etc. Adding a new userhas no effect on the process instances that are already running.

When a user is deleted from the system it must be decided what will happen to the work itemsthat were already assigned to this employee. These ongoing work items should be reassigned ordelegated by the employee or the workflow administrator.

When a users authorisation rights are changed the access to work items and attached documentswill have changed for him/her. All work items that are not yet allocated will be allocated usingthe new access rights of the user. Already allocated work items need to be reassigned by theworkflow administrator if necessary.

5.3 Interfaces 89

Adding Substitutes Screen

In Figure 5.9 the screen for adding and editing substitutions is shown.

A resource or a position can have a substitute for a defined time period. The substitute infor-mation can be edited using the edit substitute screen.

Update Supported

When a user is going on a holiday for two weeks a substitute user can be defined. All workitems will then be assigned to the substitute user during the specified time period. The workflowadministrator will have to keep in mind that the user needs to have the appropriate access rightsor the access rights have to be transferred or temporarily assigned as well.

5.3.3 Process Definition Management Screen

The table on top of the screen in Figure 5.10 gives an overview of all the process definitionsuploaded to the WfMS. Process Definitions with the status obsolete can be deleted. In the lowersection new process definitions can be uploaded.

Update Supported

A new version of a process definition is registered to improve the process. Ongoing cases willfollow the process definition and new cases follow the new process definition. After all the oldprocesses have completed the old process definition is given the status obsolete.

5.3.4 Change Management Screens

We will now describe the design for the screens in the change management section of the workflowadministration tool.

Case Management Screen

ioo Change management is divided into three subsections: case management, work item man-agement and change allocation strategy. In the case management subsection, displayed in Fig-ure 5.11, all the cases can be viewed and their status can be changed. Setting a maximumnumber of cases and canceling cases is also possible in this section.

Updates Supported

A case may need to be aborted. The remaining tasks that have to be done will disappear fromthe worklist and the cancelation will be logged.

All cases of a certain process definition need to be suspended. The status of all the cases of thatprocess definition must be changed to suspended. All the work items belonging to those caseswill be suspended as well.

90 5 Design

Work Item Management Screen

In the work item management section, shown in Figure 5.12, viewing all the work items andchanging their status is possible. The priority of a work item can also be changed in this sectionand the workflow administrator can reassign work items.

Updates Supported

Abort/suspend/resume work item.

Increase the priority of the work item. The work item will then appear more prominently in theworklist of the user/group.

A work item needs to be reallocated to another resource. The task disappears on the list for theprevious resource and appears in the worklist for a suitable resource.

Changing Allocation Strategy Screen

If resources get overloaded because the allocation strategy is not working out the workflowadministrator can decide to change the allocation strategy for a case or all cases of a processdefinition. He could even decide to change the allocation strategy for all the process definitions.This can be done in the change allocation strategy section of change management, shown inFigure 5.13.

Update Supported

Change the allocation strategy to push/pull/round robin etc. because the workload is not dis-tributed evenly. The work items will then be allocated by the engine using the new allocationstrategy.

5.3.5 Configuration Screens

We will describe the design for the configuration screens in this section.

Setting Business Calendar Screen

In Figure 5.14 the screen for entering the working days (business calendar) is shown.

An organisational group can work on different days or hours than another group within thesame company. By defining for each organisational group at what days and hours they work thesystem can allocate work items more effectively. Defining the business calendar for an organi-sational group can be done in the set business calendar screen of the configuration section.

5.3 Interfaces 91

Update Supported Suppose the working hours will be extended because it is peak time. Theengine will also allocate work items to users during the new working hours. It has no conse-quences for the ongoing tasks.

Worklist Display Configuration

Figure 5.15 shows the other configuration screen namely creating the worklist settings. Theworkflow administrator can create a number of worklists that display different information andare ordered in different ways. These newly created worklist settings can be assigned to humanresources so that the worklist for that user is displayed and ordered properly.

5.3.6 Audit Trail Screen

Figure 5.16 shows the screen for the audit trail section. Here the workflow administrator canview the audit trail filtered on case or time frame. He can also specify which things need to berecorded in the audit trail. By deselecting some items the size of the audit trail can be reduced.Old entries can also be deleted by the workflow administrator by specifying a time range andclicking the delete button.

5.3.7 Reports Screen

A number of predefined report types will be available to be created, viewed and printed in thereports section, shown in Figure 5.17. Report types can be deleted by selecting them from thetable and clicking the ’delete report’ button.

5.3.8 Third Party Software Screen

The audit trail of YAWL is set up in such a way that process mining tools can analyse theaudit trail to discover the process definition as it was actually performed from the audit traildata. The workflow administrator needs to specify which time frame of data for which processdefinition needs to be analysed and then click the ’analyse’ button. The design for the thirdparty software screen is shown in Figure 5.18. Custom YAWL Services can also be uploadedin this screen and an overview of all the services, their documentation (description of what theservice does) and the usernames they use for login into the YAWL engine is provided.

92 5 Design

Figure 5.5: Relational Model of YAWL

5.3 Interfaces 93

Figure 5.6: Design for the overview screen

Figure 5.7: Design for the add resource screen

94 5 Design

Figure 5.8: Design for the edit resource screen

Figure 5.9: Design for the add/edit substitution screen

5.3 Interfaces 95

Figure 5.10: Design for the process definition management screen

Figure 5.11: Design for the case management screen

96 5 Design

Figure 5.12: Design for the work item management screen

Figure 5.13: Design for the change allocation strategy screen

5.3 Interfaces 97

Figure 5.14: Design for the enter business calendar screen

Figure 5.15: Design for the worklist configuration screen

98 5 Design

Figure 5.16: Design for the audit trail screen

Figure 5.17: Design for the reports screen

5.3 Interfaces 99

Figure 5.18: Design for the third party software screen

100 5 Design

Chapter 6

Implementation

The implementation is based on the design described in Chapter 5. This chapter will brieflyintroduce the YAWL environment and the architecture, after which the implementation of theYAWL administration and monitoring component will be discussed.

6.1 Introduction to YAWL

An extensive study on existing workflow management systems and workflow languages to mea-sure the support for the workflow patterns [AHB03] has shown that there is a need for a betterworkflow language that caters for all workflow patterns in a straightforward manner. Workflowlanguages based on Petri Nets seem to perform better when it comes to the state-based workflowpatterns, but these languages still have problems with a few other patterns. This observationled to the development of Yet Another Workflow Language (YAWL) which would take Petrinets as a starting point and provide extensions to allow for better support of all the workflowpatterns [AH05]. YAWL is both a workflow language and an open source workflow system. Thedevelopment of the YAWL language started in 2002 as a joint project between the EindhovenUniversity of Technology1 and Queensland University of Technology2. The YAWL language hasa formal semantics. The YAWL system supports all the workflow patterns except the patternfor implicit termination. The first release of the YAWL system was in November 2003 and thefurther development is still in progress. More information about the YAWL system can be foundon the YAWL website3.

6.2 YAWL Architecture

This section will briefly describe the architecture of YAWL to position the administration andmonitoring tool within the YAWL environment. A complete description of the architecture canbe found in [AADH04]. A graphical representation of the overall architecture of the YAWLenvironment can be found in Figure 6.1.

YAWL uses a service-oriented architecture. The YAWL manager in Figure 6.1 corresponds

1http://www.tue.nl2http://www.qut.edu.au3http://www.yawl-system.com

102 6 Implementation

Figure 6.1: The YAWL architecture as modeled by Lachlan Aldred (revised)

to the administration and monitoring tool. The tool communicates with the engine throughinterface A. The administration and monitoring tool stores the organisational data in the samedatabase as the logging and persistence component as described in Chapter 6.3.1.

The administration and monitoring tool uses Java Server Pages and can be accessed usinga browser. Apache Tomcat 5.0.28 is used as the web application container4. For creating thecharts the JFreeChart library is used5.

6.3 YAWL Administration and Monitoring Tool

This section will describe the technologies used to build and support the administration andmonitoring tool and will provide some screenshots of the implementation of the tool

6.3.1 Database

There are a few open source databases available that are suitable for storing administrationdata. The databases that were considered are Hypersonic6, MySQL7, PostgreSQL8 and openLDAP9.

4http://jakarta.apache.org/tomcat/index.html5http://www.jfree.org/jfreechart/index.php6http://hsqldb.sourceforge.net/7http://www.mysql.com/8http://www.postgresql.org/9http://www.openldap.org/

6.3 YAWL Administration and Monitoring Tool 103

PostgreSQL was chosen because its software license is in accordance with the licenses forthe other components in the YAWL environment and there is a lot of support available. SinceLDAP is a database that is used a lot in practice to hold organisational data the organisationaldatabase is kept separate from the database used for logging and persistence and the databasefor runtime data. By keeping the data separate the database could be changed to LDAP if thatis preferred. The editor retrieves the data about the human resources, roles and positions fromthe organisational database to connect resources to tasks.

The implementation for the administration and monitoring is limited to what the YAWLengine can support. Only a subset of the design of the administration and monitoring tool isimplemented in the Beta 6 version. Certain functionality cannot be supported by the engine atthis time because many changes are required and due to time constraints of the other developers.

The binary download for the YAWL-system, including the administration and monitoringtool can be downloaded from the YAWL sourceforge website10. The Beta 6 version, includingthe administration and monitoring tool, is planned to be released at the end of August 2005.The installation and user manual for the administration and monitoring tool can also be foundon the YAWL sourceforge website.

6.3.2 Implementation Screens

This section will display actual implementation screenshots of the tool.

When starting the YAWL Administration and Monitoring Tool (YAWL AdMo) a login screenwill appear shown in Figure 6.2.

Figure 6.3 shows a screenshot of the screen that provides the graphical overviews. Theworkflow administrator can select the information he would like to see from a list of predefinedqueries. Information representations can also be specified and a time frame can be entered onthis screen.

Figure 6.4 shows the screen for entering organisational data. After clicking a menu item onthe left side, a screen to enter the data in the database will appear. An example of such a screenis shown in Figure 6.5.

At the moment when deleting a human resource from both the database and the engine, it isnot checked whether this resource still has work items allocated to him. This check needs to bedone by the engine in the future since the allocation is done at runtime and the organisationaldatabase does not hold knowledge about allocations.

Figure 6.6 shows a screenshot of the actual implementation of the specification managementscreen. After a business process specification has been created in the editor the specificationcan be uploaded into the engine using this screen.

The configuration and change management screens are not implemented yet. The functionssupported by these screens as designed in Chapter 5 have a lot of consequences for the engine andthe changes to the engine will not be realised in the next release that includes the administrationand monitoring tool. The reports section has not been implemented because of time constraints.

In Figure 6.7 the screen accessing the audit trail information is shown. Here the audit traildata can be viewed and filtered on any specific resources involved.

10http://sourceforge.net/projects/yawl/


Figure 6.2: The YAWL AdMo Tool login screen

Figure 6.3: The YAWL AdMo Tool overview screen


Figure 6.4: The YAWL AdMo Tool organisational data screen

Figure 6.5: Entering Organizational Data: adding a substitute resource or position


Figure 6.6: The YAWL AdMo Tool specification management screen

Figure 6.7: The YAWL AdMo Tool specification management screen


Figure 6.8 shows a screenshot of the third party software screen. In the future it is imaginablethat this page provides a link to more business intelligence tools that can analyse the data. Itcould also offer the functionality to select which database to use for the different databases (e.g.LDAP for the organisational data, PostgreSQL for logging etc.).

Selecting the database to use would be a function located under third party software. Loadingadditional web services is located on the third party software screen as well. A lot of processmining tools and third party reporting tools exist. A link to them can be provided in the thirdparty software screen. The process mining tool that we will be able to connect to is called ProMversion 2.011.

Figure 6.8: The YAWL AdMo Tool third party software screen

11http://www.processmining.org


Chapter 7

Epilogue

This chapter summarises the contributions of our work, evaluates the implemented administra-tion and monitoring tool and provides guidelines for future work.

7.1 Summary

The goal of this thesis was to better identify the functionality a state-of-the-art workflow admin-istration and monitoring tool should have and which data needs to be collected to support thisfunctionality. We have constructed a list of functional requirements and developed a conceptualmodel to define the data that is needed for such an administration and monitoring tool.

To validate the model we have implemented the tool in the YAWL environment. We havemade a full design for this tool and implemented the functionality that was possible within thetime and other constraints we had. Looking back at the initial criteria we had, we have succeededin implementing entering organisational data and providing graphical overviews. Support forprocess mining is included through a third party process mining tool as an analysis technique.

During the project it became clear that many elements of workflow come together in theadministration and monitoring tool and that intervening into the workflow through the admin-istration and monitoring tool has many consequences for the rest of the YAWL environment.The project also has made clear that installing and setting up existing commercial workflowmanagement systems can be very complicated and sufficient resources should be allocated tomanage the workflow systems.

The contributions of our research are:

• construction of an OR-Model of interface 5

• a literature review on research prototypes

• analysis of the administration and monitoring functionality of existing workflow manage-ment systems and creation of OR-Models of the data captured by these systems

• identification of a list of the functional requirements for a workflow administration andmonitoring tool

• an OR-Model for workflow administration data in YAWL

• a design for a workflow administration and monitoring tool in YAWL

110 7 Epilogue

• implementation of parts of the design in the YAWL environment

• identification of future projects in the workflow administration area.

7.2 Future Work

In the future more business intelligence plugins will become available for workflow systems thatcan be used for prediction and explanation. An open source business intelligence tool beingdeveloped by Pentaho that might be suitable for integration into the YAWL system will becomeavailable later this year1 2. In April 2005 Greenplum released the first beta version of an open-source data warehouse called DeepGreen 3. The project is called Bizgres 4 and it is a datawarehouse version of PostgreSQL that supports business intelligence possibilities. In the futuremore open source data warehouses may become available that can be integrated with YAWLand allow for more advanced analysis techniques like business intelligence tools.

The workflow administration and monitoring tool could also be extended to support thetechnical-oriented analysis (system-performance). The tool could have role-based access to theadministration and monitoring data. Different interfaces for the different kind of users couldbe designed. Especially when the tool will also be used to provide reports for customers. Theaccess to the other information needs to be restricted for these external users.

Currently YAWL is undergoing much development. Work is being completed on the visual-isation of the worklist as well as further support for the resource patterns. Exception handling;what to do when there is one case that deviates from all the other process definitions, and dy-namic workflow; creating personal decompositions for a task for the different users, is also beinginvestigated at Queensland University of Technology [AHEA04]. A commercial strength versionof YAWL together with an industry partner is also under development.

1http://www.pentaho.org/2http://www.linuxelectrons.com/article.php/200506170801324423http://www.greenplum.com4http://www.bizgres.org

Bibliography

[AADH04] W. M. P. van der Aalst, L. Aldred, M. Dumas, and A. H. M. ter Hofstede. De-sign and implementation of the YAWL system. In Proceedings of the 16th Inter-national Conference on Advanced Information Systems Engineering (CAiSE 04),Riga, Latvia, June 2004.

[ADH+03] W. M. P. van der Aalst, B. F. van Dongen, J. Herbst, L. Maruster, G. Schimm,and A. J. M. M. Weijters. Workflow mining: A survey of issues and approaches.Data and Knowledge Engineering, 47(2):237–267, 2003.

[AH96] V. Atluri and W. K. Huang. An authorization model for workflows. In Proceedingsof the 5th European Symposium on Research in Computer Security, September1996.

[AH00] V. Atluri and W. K. Huang. A petri net based safety analysis of workflow autho-rization models. Journal of Computer Security, 8(2/3):209–240, 2000.

[AH02] W. M. P. van der Aalst and K. M. van Hee. Workflow Management. Models,Methods, and Systems. MIT Press, Cambridge, 2002. ISBN 0-262-01189-1.

[AH05] W. M. P. van der Aalst and A. H. M. ter Hofstede. YAWL: Yet another workflowlanguage. Information Systems, 30(4):245–275, 2005.

[AHB03] W. M. P. van der Aalst, A. H. M. ter Hofstede, and A. P. Barros. Workflowpatterns. Distributed and Parallel Databases, 14(3):5–51, July 2003.

[AHEA04] M. Adams, A. H. M. ter Hofstede, D. Edmond, and W. M. P. van der Aalst. Facil-itating flexibility and dynamic exception handling in workflows through worklets.QUT Technical Report, Queensland University of Technology, Brisbane(FIT-TR-2004-03), 2004.

[ASKP00] G. J. Ahn, R. Sandhu, M. Kang, and J. Park. Injecting RBAC to secure a web-based workflow system. In Proceedings of the fifth ACM workshop on Role-basedaccess control, July 2000.

[Atl01] V. Atluri. Security for workflow systems. Technical Report 2,Information Security Technical Report, Elsevier Science, 2001.http://cimic.rutgers.edu/ atluri/workflow.pdf, last accessed on 04-05-2005.

111

112 Bibliography

[AWM04] W. M. P. van der Aalst, A. J. M. M. Weijters, and L. Maruster. Workflow mining:Discovering process models from event logs. Transactions on Knowledge and DataEngineering (TKDE/IEEE), 16(9):1128–1142, September 2004.

[BCDS01] A. Bonifati, F. Casati, U. Dayal, and M. C. Shan. Warehousing workflow data:Challenges and oppurtunities. In Proceedings of the 27th VLDB Conference, Roma,Italy, 2001.

[BFA99] E. Bertino, E. Ferrari, and V. Atluri. An approach for the specificationand enforcement of authorization constraints in workflow management sys-tems. ACM Transactions on Information Systems Security, 1(1), February 1999.http://cimic.rutgers.edu/ atluri/tissec.ps, last accessed on 04-05-2005.

[BM00] N. Belkhatir and N. Mihoubi. Adapting the observer pattern forprocess management. In Proceedings of SCI 2000 / ISAS 2000, 2000.http://dttx.vnuit.edu.vn/tvien/PapersPdf/ISPdf/IS77-11.pdf, last accessed on 09-05-2005.

[Cas02] F. Casati. Intelligent process data warehouse for HPPM 5.0, April 2002.http://www.hpl.hp.com/techreports/2002/HPL-2002-120.pdf, last accessed on 02-05-2005.

[CCDS04] M. Castellanos, F. Casati, U. Dayal, and M. C. Shan. A comprehensive and auto-mated approach to intelligent business process execution analysis. Distributed andParallel Databases, 16(3):239–273, 2004.

[CCDS05] M. Castellanos, F. Casati, U. Dayal, and M. C. Shan. iBOM: A platform forbusiness operation management. In Proceedings of ICDE 2005, Tokyo, Japan,June 2005.

[CCS04] F. Casati, M. Castellanos, and M. C. Shan. Enterprise cockpit for business opera-tion management. In Proceedings of ER 2004, Shanghai, China, November 2004.

[Coa95] Workflow Management Coalition. Workflow reference model, January 1995.http://www.wfmc.org/standards/docs/tc003v11.pdf, last accessed on 11-03-2005.

[Coa98] Workflow Management Coalition. Audit data specification, version 1.1, September1998. http://www.wfmc.org/standards/docs/TC-1015 v11 1998.pdf, last accessedon 12-03-2005.

[Coa99] Workflow Management Coalition. Terminology and glossary, February1999. http://www.wfmc.org/standards/docs/TC-1011 term glossary v3.pdf, lastaccessed on 14-03-2005.

[DHL01] U. Dayal, M. Hsu, and R. Ladin. Business process coordination: State of the art,trends, and open issues. In Proceedings of the 27th VLDB Conference, pages 3–13,Roma, Italy, 2001.

Bibliography 113

[EOG02] J. Eder, G. E. Olivotto, and W. Gruber. A data warehouse for workflow logs. InEDCIS, pages 1–15, 2002.

[EPGN03] J. Eder, H. Pichler, W. Gruber, and M. Ninaus. Personal schedules for workflowsystems. In Business Process Management, pages 216–231, 2003.

[FRF02] A. Fent, H. Reiter, and B. Freitag. Design for change: Evolving workflow specifi-cations in ultraflow. In CAiSE, pages 516–534, 2002.

[Fuj03a] Fujitsu Software Corporation, 3055 Orchard Drive, San Jose, CA 95134, USA.Interstage CollaborationRing i-Flow Administration and Installation Guide for theAdvanced Edition, 6.1 edition, October 2003.

[Fuj03b] Fujitsu Software Corporation, 3055 Orchard Drive, San Jose, CA 95134, USA. In-terstage CollaborationRing i-Flow Developer’s Guide, 6.1 edition, November 2003.

[Fuj03c] Fujitsu Software Corporation, 3055 Orchard Drive, San Jose, CA 95134, USA.Interstage CollaborationRing i-Flow User’s Guide, 6.1 edition, October 2003.

[GAX02] A. Gal, V. Atluri, and G. Xu. An authorization system for temporal data. InICDE, pages 339–340, 2002.

[GCC+02] D. Grigori, F. Casati, M. Castellanos, U. Dayal, M. Sayal, and M. C. Shan. Businessprocess cockpit. In Proceedings of the VLDB’02, Hong Kong, China, August 2002.

[GCC+04] D. Grigori, F. Casati, M. Castellanos, U. Dayal, M. Sayal, and M. C. Shan. Businessprocess intelligence. Computers in Industry, 53(3):321–343, 2004.

[GT97] A. Geppert and D. Tombros. Logging and post-mortem analysis of workflow exe-cutions based on event histories. In Proceedings of the 3rd International Workshopon Rules in Database Systems (RIDS), pages 67–82, Skoevde, Sweden, June 1997.

[HA99] W. K. Huang and V. Atluri. Secureflow: A secure web-based workflow managementsystem. In Proceedings of the 4th ACM Workshop on Role-Based Access Control,Fairfax, VA, October 1999. pp. 83-94.

[Hal01] T. Halpin. Information Modeling and Relational Databases. From conceptual analy-sis to logical design. Morgan Kaufmann, San Diego, 2001. ISBN 1-55860-672-6.

[HLKP00] H. S. Hong, B. S. Lee, K. H. Kim, and S. K. Paik. A web-based transactionalworkflow monitoring system. In Proceedings of the First International Conferenceon Web Information Systems Engineering (WISE’00), Hong Kong, China, June2000.

[Hol04] D. Hollingsworth. The workflow reference model 10 years on, 2004.http://www.wfmc.org/standards/docs/Ref Model 10 years on Hollingsworth.pdf,last accessed on 11-03-2005.

[IBM99] IBM. IBM MQSeries Workflow. Getting Started with Runtime. Version 3.2.1, 3rdedition, September 1999.

114 Bibliography

[IBM01] IBM Corporation, International Technical Support Organization, Dept. HZ8 Build-ing 662, P.O.Box 12195, Research Triangle Park, NC 27709-2195. MQSeries Work-flow for Windows NT for Beginners, 1st edition, March 2001. This edition appliesto MQSeries for Windows Version 5.1, MQSeries Workflow for Windows NT andDB2 Version 3.2.2.

[IBM03a] IBM. IBM Websphere MQ Workflow. Administration Guide. Version 3.4, 7thedition, January 2003.

[IBM03b] IBM. IBM Websphere MQ Workflow. Concepts and Architecture. Version 3.4, 6thedition, January 2003.

[IBM03c] IBM. IBM Websphere MQ Workflow. Programming Guide. Version 3.4, 9th edi-tion, January 2003.

[JB96] S. Jablonski and C. Bussler. Workflow Management. Modeling Concepts, Architec-ture and Implementation. Thomson Computer Press, 1996. ISBN 1-85032-222-8.

[KAD98] P. Koksal, S. N. Arpinar, and A. Dogac. Workflow history management. SIGMODRecord, 27(1):67–75, 1998.

[KK02] K. H. Kim and I. S. Kim. The admon-time workflow client: Why do we needthe third type of workflow client designated for administration and monitoringservices? In Proceedings of the International Conference on Web-Age InformationManagement 2002, pages 213–224, 2002.

[Lam91] B. W. Lampson. Requirements and technology for computing security. In Com-puters at Risk, pages 74–101. National Academy Press, Washington, 1991.

[LKNL04] S. Y. Lee, Y. M. Kim, B. N. Noh, and H. H. Lee. A new authorization model forworkflow management system using the RPI-RBAC model. In Proceedings of theInternational Conference on Computational Science, Krakow, Poland, June 2004.

[LLN04] H. H. Lee, S. Y. Lee, and B. N. Noh. A new role-based authorization model ina corporate workflow systems. In Proceedings of the International Conference onComputational Science and its Applications, Assisi, Italy, May 2004.

[LM04] B. List and K. Machaczek. Towards a corporate performance measurement system.In ACM Symposium on Applied Computing (SAC), pages 1344–1350, 2004.

[MA01] M. Y. Mohamed and V. Atluri. A Framework for Generation of Audit Data forWeb-Based Secure Workflow. PhD thesis, Rutgers University, Spring 2001.

[MR00] M. zur Muehlen and M. Rosemann. Workflow-based process monitoring and con-trolling - technical and organizational issues. In Proceedings of the 33rd HawaiiInternational Conference on Systems Sciences, Wailea, Hawaii, 2000.

[Mue00] M. zur Muehlen. Workflow-Based Process Controlling - Or: What You Can Mea-sure You Can Control, pages pp.61–77. Lighthouse Point, Florida, USA, 2000.

Bibliography 115

[Mue01] M. zur Muehlen. Process-driven management information systems - combiningdata warehouses and workflow technology. In Proceedings of the 4th InternationalConference on Electronic Commerce Research, Dallas, USA, 2001.

[Mue04] M. zur Muehlen. Workflow-based Process Controlling. Foundation, Design, andApplication of workflow-driven Process Information Systems. Logos Verlag, Berlin,2004. ISBN 3-8325-0388-9.

[MWGW99] P. Muth, J. Weissenfels, M. Gillmann, and G. Weikum. Workflow history manage-ment in virtual enterprises using a light-weight workflow management system. InProceedings of the 9th International Workshop on Research Issues in Data Engi-neering 1999, Sydney, Australia, 1999. pp. 148-155.

[Pro99] Common Criteria Project. Common criteria for information technology se-curity evaluation. part 2: Security functional requirements, August 1999.http://csrc.nist.gov/cc/Documents/CC%20v2.1/p2-v21.pdf, last accessed on 10-05-2005.

[RHEA04] N. Russell, A. H. M. ter Hofstede, D. Edmond, and W. M. P. van der Aalst. Work-flow resource patterns: Identification, representation and tool support. Technicalreport, BETA Working Paper Series, WP 127, Eindhoven University of Technology,Eindhoven, 2004.

[SJKC04] J. Schiefer, J. J. Jeng, S. Kapoor, and P. Chowdhary. Process information factory:A data management approach for enhancing business process intelligence. In Pro-ceedings of the International Conference on E-commerce Technology (CEC), pages162–169, 2004.

[SPF04] B. T. R. Savarimuthu, M. Purvis, and M. Fleurke. Monitoring and controlling ofa multi-agent based workflow system. In of the second workshop on Australasianinformation security, Data Mining and Web Intelligence, and Software Interna-tionalisation - Volume 32, Dunedin, New Zealand, January 2004.

[Sta02a] Staffware House, 3 The Switchback, Gardner Road, Maidenhead, Berkshire, SL67RJ. Staffware Process Suite. Administering the Staffware iPE SQL Server Data-base, issue 1 edition, May 2002.

[Sta02b] Staffware House, 3 The Switchback, Gardner Road, Maidenhead, Berkshire, SL67RJ. Staffware Process Suite. Administering the Staffware iProcess Engine, issue2 edition, May 2002.

[Sta02c] Staffware House, 3 The Switchback, Gardner Road, Maidenhead, Berkshire, SL67RJ. Staffware Process Suite. Administering the Staffware PE SQL Database, issue1 edition, May 2002.

[Sta02d] Staffware House, 3 The Switchback, Gardner Road, Maidenhead, Berkshire, SL67RJ. Staffware Process Suite. Administering the Staffware Process Engine, issue 1edition, May 2002.

116 Bibliography

[Sta02e] Staffware House, 3 The Switchback, Gardner Road, Maidenhead, Berkshire, SL67RJ. Staffware Process Suite. Defining Staffware Priocedures, issue 2 edition, May2002.

[Sta02f] Staffware House, 3 The Switchback, Gardner Road, Maidenhead, Berkshire, SL67RJ. Staffware Process Suite. Managing Staffware, issue 2 edition, May 2002.

[Sta02g] Staffware House, 3 The Switchback, Gardner Road, Maidenhead, Berkshire, SL67RJ. Staffware Process Suite. Understanding the Staffware iPE Architecture, issue2 edition, May 2002.

[Sta02h] Staffware House, 3 The Switchback, Gardner Road, Maidenhead, Berkshire, SL67RJ. Staffware Process Suite. Using the Staffware Process Client, issue 2 edition,May 2002.

[Sta02i] Staffware House, 3 The Switchback, Gardner Road, Maidenhead, Berkshire, SL67RJ. Staffware Process Suite. Using the SWIP Monitor, issue 1 edition, May 2002.

[Sun01a] Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, California 94303, USA.Conceptual Overview. iPlanet Integration Server, version 3.0 edition, August 2001.

[Sun01b] Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, California 94303, USA.Process Development Guide. iPlanet Integration Server, version 3.0 edition, August2001.

[Sun01c] Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, California 94303, USA.Process System Guide. iPlanet Integration Server, version 3.0 edition, August 2001.

[Sun03] Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, California 94303, USA.Master Index. iPlanet Integration Server EAI, version 3.1 edition, September 2003.

[Tra03a] Transflow Deutschland, Venloer Strasse 83-85, D-50259 Pulheim. COSA 4 Admin-istrator’s Guide, documentation version 4.2 edition, April 2003.

[Tra03b] Transflow Deutschland, Venloer Strasse 83-85, D-50259 Pulheim. COSA 4Business-Process Designer’s Guide, documentation version 4.2 edition, May 2003.

[Tra03c] Transflow Deutschland, Venloer Strasse 83-85, D-50259 Pulheim. COSA 4 User’sGuide, documentation version 4.2 edition, March 2003.

[Wav04a] Wave-Front BV. FLOWer 3 Beheerdershandboek (Administrator Guide), 3.0 edi-tion, January 2004.

[Wav04b] Wave-Front BV. FLOWer 3 Designer’s Guide, 3.0 edition, January 2004.

[Wav04c] Wave-Front BV. FLOWer 3 Gebruikershandboek (User Manual), 3.0 edition, Jan-uary 2004.

Bibliography 117

[WBK03] J. Wainer, P. Barthelmess, and A. Kumar. W-RDBAC - a workflow security modelinsorporating controlled overriding of constraints. International Journal of Coop-erative Information Systems, 12(4):455–485, 2003.

[WMC03] M. zur Muehlen Workflow Management Coalition. In-terface 5 - issues and directions, April 2003.http://www.wfmc.org/standards/docs/Interface 5 Issues and Directions.pdf,last accessed on 14-03-2005.

[YYW04] Z. Yi, Z. Yong, and W. Weinong. Modeling and analyzing of workflow authorizationmanagement. Journal of Network and Systems Management, 12(4), December2004.