1

Business Process Management and Workflow

– Lecture –

Dr. Andreas Wickenh¨auser [email protected]

Friedrich-Schiller-Universit¨at Jena Fakult¨at f¨ ur Mathematik und Informatik Institut f¨ ur Informatik Lehrstuhl f¨ ur Datenbanken und Informationssysteme Ernst-Abbe-Platz 2 07743 Jena

July 20th 2011

Copyright by Andreas Wickenh¨ auser, 2011. All rights reserved. This text can be used for the lecture in Jena 2011. Other noncommercial usages of the whole unchanged text are allowed. Brief quotations are allowed if the author is cited correctly.

Preface Business processes and workflow is an essential part of modern organizations. This book discusses the automated execution of business processes with suitable software. Main emphasis lies on the following aspects: • How business process management software is used to achieve the business goals of the organization. • Technologies and standards used in the area of business processes are described such as BPEL (Business Process Execution Language), BPMN (Business Process Modeling Notation), business rules, transactions, message queues, date bases and monitoring.

About the author Since 1994, Andreas Wickenh¨ auser works in the area of business process management systems at IBM at various positions in development and customer support. Andreas Wickenh¨auser is a doctor of mathematics. E-mail address: [email protected]

2

Contents Preface

2

Contents

3

1 Introduction

5

1.1

A simple process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.2

System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

1.3

Process life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

1.4

Elements and components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.5

Customer scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.6

Exercises

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Main Properties of BPM systems 2.1

2.2

15

BPMN, Business Process Model and Notation . . . . . . . . . . . . . . . . . 15 2.1.1

BPMN elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1.2

BPMN navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

BPEL, Business Process Execution Language . . . . . . . . . . . . . . . . . 23 2.2.1

Web Services introduction . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.2

BPEL to integrate Web Services . . . . . . . . . . . . . . . . . . . . 26

2.2.3

BPEL elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2.4

Process navigation in a Flow activity . . . . . . . . . . . . . . . . . . 30

2.3

Staff in a BPM system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.4

Business rules management systems . . . . . . . . . . . . . . . . . . . . . . 37

2.5

Event monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.6

Exercises

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3

4

CONTENTS

3 The user perspective

45

3.1

Change management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2

Process improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.3

Capacity planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.4

Exercises

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4 Services and Techniques of BPM Systems 4.1

55

Data and transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.1.1

The usage of database systems by a BPM system . . . . . . . . . . . 55

4.1.2

Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.1.3

Message queueing

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.2

SCA and SDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.3

BPM systems at IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.4

Correlation and context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.5

Synchronous and asynchronous communication . . . . . . . . . . . . . . . . 71

4.6

Business-level error handling . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.7

Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.8

Unicode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.9

4.8.1

Unicode quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.8.2

Unicode basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.8.3

Unicode representation . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Exercises

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

List of Figures

85

Bibliography

89

Chapter 1

Introduction The different aspects of BPM (business process management) are reflected here by different views to the subject. After discussing a simple process model, on a more abstract level, key terms are discussed. The introduction is completed by the discussion of a customer scenario.

1.1

A simple process

As introduction, we consider the following scenario: At an on-line store, customers can order goods. After typing in all necessary data for an order. the process Fullfill describes the necessary steps to complete this order. The creation of the process model is shown with WID (WebSphere Integration Developer), the development tool of WPS (WebSphere Process Server), a BPM solution of IBM. The language used to describe this process is BPEL (Business Process Execution Language) with some extensions defined by IBM. The purpose of this demonstration is to sketch the design of process illustrated in 1.1 on the following page. The outcome is not an executable process. For this, definitions such as further interfaces and binding information how to access the services used is missing. The data model of this process is fairly simple, After the customer has placed the order, it is stored in the on-line store order database. This process here is started with an input variable containing the order number as reference. Later on, a boolean variable is needed which is used for conditional processing. Both variables are global to the process, that means they can be accessed from all activities of the process. The steps necessary to create the process are explained below. For a more detailed description of creating a sample process, please refer to [WPS10]. 1. In an empty WID workspace, create a new module with name Fullfill. The module is the entity which in case of an executable process will be deployed (installed) on the application server, the runtime environment. 2. Create an interface with name Fullfill. In the interface, create a one-way operation, the input contains the date OrderNbr with datatype int. This interface describes the input and output data when the business process is called. In our example, when 5

6

CHAPTER 1. INTRODUCTION

Figure 1.1: Simple process of an on-line store calling the process, no data is expected after completion of the process. Therefore, a one-way operation is defined. 3. Within the module, create a new Business Process with name Fullfill. When creating the business process, do not create a new interface, instead use the interface just created. The process can be viewed as service which is called via its interface. 4. Then, the following Invoke activities are created: Allocation, Payment, Delivery, Customer notification. For these activities, definitions such as interfaces and binding information will not be defined. An Invoke activity represents calling an other service. Therefore, we can view a process as a means to aggregate services. As we do not intent to create an executable process, we do not specify all necessary data for these activities. 5. The next activity is a Wait activity. It is named as Wait for payment. 6. Before crating the next activity, the interface checkPayment is created. It has one two-way operation with the integer value orderNbr as input and the boolean value paymentOK as output. 7. Also, a boolean variable paymentOK is created for the process.

1.1. A SIMPLE PROCESS

7

8. Next, the invoke activity payment OK is created. For this activity, in the the details page, a partner is defined by using the interface paymentOK. Both variables of the process are connected with this interface. As the outcome of this activity controls the further execution of the process, we specify it on a more detailed level. 9. Then, a Structured activity Choice is defined. 10. Inside this activity, the first case is named No payment. I contains the simple condition paymentOK==false. Below this case, a human task activity is added. 11. This could be the complete process. In case the payment was ok, there is no action in the choice activity. To make this explicit, the following could be added: The Otherwise case is added to the choice activity. Then, for this case, an empty activity with name nothing to do is added. In essence, the process definition describes which services are invoked in which order. Data which is relevant for the process execution can be defined in the process so that depending on this data, the process performs differently. As explanation, a short description of the activities is given: Receive This activity starts the new process instance. The input data is received and made available for the process. Allocation The items ordered are allocated for the customer. Payment The payment of the order is initiated. Delivery The sending of the goods is initiated. Customer notification An E-mail is sent to the customer that the goods are delivered. Wait for payment The process is halted until it can be expected that the order is paid. Choice Conditional processing. No payment If the previous activity indicates that the payment was not successful, a work item is created so that a suitable specialist of the on-line store can look for this and initiate appropriate steps. Otherwise In case the payment was correct, this branch is executed. It only explicitly states that there is nothing to do.

8

CHAPTER 1. INTRODUCTION

1.2

System architecture

Here, we look at the BPM system from the perspective.of the IT (information technology) department. When considering the previous example, it turns out that this process must interface with various other systems in the on-line store as illustrated in 1.2.

presentation layer

BPM layer

services, back-ends Figure 1.2: A BPM system as middleware between presentation layer and back-ends The idea of BPM systems is to have a separate layer to define the process structure. Ideally, the process could be adapted without changing the services and back-ends called.

web frontend Internet

web frontend intranet

accounting

BPM system order, articles db

mail system shipment

Figure 1.3: Interfaces of a BPM system So, in 1.3, the following terms have been illustrated: Business process management (BPM) The definition and execution of business processes. Essential is here that the execution of the business processes supports the

1.3. PROCESS LIFE CYCLE

9

business goals of the organization. Goals could be duration, cost, reliability, transparency. Service-oriented architecture (SOA) The business functions integrated in the process model as activity implementations are called services. The idea of SOA is to set up a consistent approach how to administer these services. Ideally, when creating a business process, an activity implementation is defined by selecting a service from a service repository. Enterprise application integration (EAI) Describes the task to integrate various IT systems in an organization so that tasks which involve multiple systems are optimally supported. It is common that a larger organization operates a lot of different IT systems which often do not fit together seamlessly. As changes or replacements of such systems would be costly and risky, integrating the systems is often the better choice. Workflow This term is similar to BPM. Usually, the emphasis of Workflow is on the involvement of people in the business process. Compared to automated processes, a Workflow is often less rigorously specified. This gives the involved people more flexibility.

1.3

Process life cycle

In addition to the definition of a business process, several other tasks are necessary to successfully execute processes. Often, these tasks are performed by different people as shown in 1.4:

business modeling

management, consultant

process modeling

BPM specialist

back end integration, user interface programming

programmer

Figure 1.4: People involved in creating a process

1. Business processes are usually defined on an abstract level by the management or a consultant of the organization. On this level, often, organizational questions must be discussed together with the business processes.

10

CHAPTER 1. INTRODUCTION 2. Then, the process model must be converted into an executable process. A BPM specialist must be familiar with the capabilities and limitations of the systems used when achieving this step. 3. Besides the process model, the necessary components must be available, including suitable user interfaces for process execution and the back-end integration necessary to perform the process activities. Often, the back-end systems are already available and must be used. In this case, by use of adapters, these systems are fit together.

Besides these people, other people are also involved: • End users are often specialists in the organization completing activities of process instances. One could also think of customers directly interacting with business processes. • The execution of processes must be monitored, sometimes problems on the business level must be solved for example if a process does not perform as expected. In a BPM system, a process administrator has various means to monitor and correct the execution of processes. • As BPM systems usually involve a multitude of systems, IT administrators are necessary to setup and maintain the systems. Usual tasks include installation of new software releases, management of resources such as machines and disk space, assuring that the expectations regarding performance and reliability are met. So, the definition of a executable process contains the following steps: • Define the interface of the process when it is called and the interfaces of services the process calls. • The process definition. • The process activities must be coded as services and integrated. • When calling a service, not only the interface must match. In addition, the service must be correctly addressed and things like protocols and transaction contexts must be taken into consideration. • If people are involved, roles must be defined so that the BPM system can address the correct set of people for a given task. In addition, a security concept must be developed specifying who is allowed to perform which operation.

1.4. ELEMENTS AND COMPONENTS

11

Taking a broader view, we no consider the life-cycle of a business process as illustrated in figure 1.5. After a business process has been developed, testing is necessary before the process can go into production, that means is in productive usage. Essential is here that the process can be monitored appropriately in order to be informed about any problems which could occur during production. In addition, monitoring information can be used as starting point for process improvements which closes this circle.

analysis and design

develop and test the solution

monitor production

production

Figure 1.5: Business process life cycle

1.4

Elements and components

Of a business process, the following terms have been introduced: Process template or process model During the design phase, a process model is created specifying how process instances are performed Activity A process contains activities which represent the actions performed during the execution of the process. Link There can be multiple dependencies between activities. If an activity can be performed only after an other activity has been completed, a link or a chain of links describes this dependency. So, the process graph is built out of activities and links. Process Instance In production, a process template is instanciated, that that means this specific instance is executed as defined in its process template. In the example at the beginning of the chapter, for each order placed by a customer, a new process instance is created. During execution of a process instance, activity instances represent the execution of the process activities. Work item For an activity instance performed by a person (a human task), a work item is created. Worklist For a specialist working with a BPM system, a worklist is created and displayed which contains the work items. By selecting a work item from this list, the specialist can start working on this activity instance. In case multiple people got a work item

12

CHAPTER 1. INTRODUCTION of the same activity instance, after one has started working with this activity, the work item is not anymore available for the other people.

The chapter completes with a short discussion of the components necessary to design and execute business processes as illustrated in 1.6. runtime design phase client client

web browser

web browser

presentation layer presentation layer

modeling tools

runtime engine

Eclipse, application server, data base

data base server

application server

deployment runtime engine application server

data base server

Figure 1.6: Key components of a BPM system During design phase, various modeling tools support the creation of the necessary artefacts of the business process. In case of WebSphere Integration Developer, these tools are implemented as Eclipse plugins. In addition, to test and debug the processes, a complete runtime environment is integrated.

1.5

Customer scenario

As illustration, a film was presented about a customer in the finance industry. It contains an example how BPM technology helps the customer reaching his business goals. Specifically, the following aspects are mentioned: 1. Key points of the solution • Customer paper correspondence is processed by information technology. Not mentioned in the film but also done is to decouple the medium of the correspondence from the processing so that independent of the medium, processing is the same. • Flexible and consistent distribution of work among the specialists. • Integrated display of correspondence, history and customer record for the specialist. • Process optimization possible through monitoring. 2. Product categories used

1.6. EXERCISES

13

• Portal server used for ”integration on the glass”. • BPM software used for: – Distribution of work – Back-end integration – Generation of monitoring data • Business rules engine to manage the work distribution • Business monitor used for ”dashboard” and multi-dimensional analysis. 3. Requirements • fast • trouble-free • reliable 4. Other aspects • Efficiency gains only because of both, introducing a BPM system and organizational changes. • Planned to increase ”processing in the dark”, that means increasing the share of automated processing. • Planned to integrate further back-end systems

1.6

Exercises

1. In a BPM system, the following data is required either for process templates or for process instances. Please decide which of this data should belong to the template data structures and which to the instance data structures. If it is unclear, make suitable assumptions and then decide. (a) The time an activity was started or completed. (b) Dependency information between the activities: Which activity must be finished before starting an other activity. (c) Type and value of process variables. (d) Process name. 2. For a given problem, a business process could be either modeled fine-grained with many activities or coarse-grained with a small number of activities. In the first case, the activities would be simple, in the latter case, the activities would be quite complex. Think about rules and reasons to decide about the granularity of activity implementations.

14

CHAPTER 1. INTRODUCTION

Chapter 2

Main Properties of BPM systems Here, a first overview of BPM systems is given. The perspective is from the outside, that means essential features of a BPM system are discussed from a user perspective. The chapter starts with an introduction of two important languages in this area, BPMN as a modeling language and BPEL as a language to integrate Web Services and to execute business processes. After this, staff assignment and the concept of Business Rules is discussed. The chapter is completed with a discussion of the event model of BPM systems. Usually, when displaying a process graphically, for example as BPMN or PPEL model, it is displayed as activity diagram. That means, the nodes of the graph are activities and the directed edges describe the execution order of these activities. This is in contrast to a state transition diagram. Here, the edges represent actions whereas the node represent states. A simple example is shown in 2.1. open the door door open

door closed close the door

Figure 2.1: State transition diagrams versus activity diagrams

2.1

BPMN, Business Process Model and Notation

BPMN was initially defined as a language to model business processes without the intent to have a system to execute them. This lead to quite detailed descriptions how the language elements are displayed in process diagrams. Only with the recent version 2 of the BPMN standard, now XML format of this language and the execution semantic is standardized. For more information see the BPMN standard documents [BPM11]. Various definitions in this section are cited from this document. 15

16

2.1.1

CHAPTER 2. MAIN PROPERTIES OF BPM SYSTEMS

BPMN elements

In this section, basic elements of BPMN are introduced. It is not the aim of this lecture to discuss all constructs of BPMN. Instead, only some key concepts of BPMN are described here. An Event is something that happens during the course of a Process. These Events affect the flow of the model and usually have a cause (trigger) or an impact (result). Events are circles with open centers to allow internal markers to differentiate different triggers or results. There are three types of Events, based on when they affect the flow: Start, Intermediate, and End.

Start Event

Intermediate End

Figure 2.2: BPMN Events An Activity is a generic term for work that is performed in a Process. The types of Activities that are a part of a Process Model are: Sub-Process and Task. A sub-process contains again a process graph with the same elements as a top-level process graph. Tasks can have a repeating attribute so they can be executed multiple times until the activity is completed.

task

activity

repeating activity subprocess +

Figure 2.3: BPMN Activities

2.1. BPMN, BUSINESS PROCESS MODEL AND NOTATION

17

A Gateway is used to control the divergence and convergence of Sequence Flows in a Process. Thus, it will determine branching, forking, merging, and joining of paths.

X

Exclusive Exclusive Event-based

Gateway Inclusive

+

Parallel

Figure 2.4: BPMN Gateways A Sequence Flow is used to show the order that Activities will be performed in a Process. A Message is used to depict the contents of a communication between two Participants. A Timer is an Event.

Sequence Flow

Default Flow

Message Catching

Message Throwing

Timer Figure 2.5: Sequence Flows, Messages and Timer in BPMN The following figure shows a simple process with unspecified start and end events and an activity.

hello world Figure 2.6: Simple process in BPMN

18

CHAPTER 2. MAIN PROPERTIES OF BPM SYSTEMS

In BPMN, cycles are allowed, so it is straightforward to model all kinds of iterations in the process, for example:

i=0

X

i