enabling flexibility in process-aware information...

P R E S E N T E D B Y B A R B A R A W E B E R

U N I V . O F I N N S B R U C K

Enabling Flexibility in Process-aware Information Systems

Challenges, Methods, Technologies

Content

Part 1 – Process-aware Information Systems Part 2 – Flexibility Issues Part 3– Flexibility Support for Pre-specified Process Models Pre-specified process models and flexibility-by-design Process configuration Flexible process execution and handling of anticipated exceptions Handling unforeseen exceptions Process Evolution Process Monitoring, Mining & Analysis

2

Content

Part 4– Loosely-specified Process Models Loosely-specified process models Constraint-based process models

3

B A R B A R A W E B E R U N I V . O F I N N S B R U C K

Business Processes and Workflows Process-aware Information Systems

4

A Retail Process

Mendling 2006

Welcome customer

Offer Clothes

Bill Clothes

Hand over clothes

5

http://sv.wikipedia.org/wiki/Bild:Hennes_%26_Mauritz.png

Business Process Lifecycle

Evaluation

Design &Analysis

Configuration

Enactment

Design: Business Process Identification and

Modeling

Analysis:ValidationSimulationVerification

Configuration:System SelectionImplementation

Test and Deployment

Enactment: OperationMonitoring

Maintenance

Evaluation:Process Mining

Business Activity Monitoring

Administration and

Stakeholders

Fig 1.5. Business process lifecycle

M. W

eske

: Bus

ines

s P

roce

ss M

anag

emen

t, ©

Spr

inge

r-V

erla

g B

erlin

Hei

delb

erg

2007

6

Value to shareholders and competitiveness

Stakeholders

Process modeling

Process execution

Knowledge

Efficiency

IT agility

Compliance & consistency

Process monitoring Business insight

BPM adoption maturity

Transformation

Workers, supervisors, and managers CIO CFO CXO CEO

Lower Higher Higher

Lower

Customers and partners Forester 2007 BPM Market Overview

Process Optimization

BPM Value Proposition

7

Process-aware Information System

Users

... Anwendungen / Application Server

Instance 4 Instance 3





Instance 7


Instance 12

Process-aware Information System (PAIS)

Process Execution Engine

Msg Queuing Time Mgmt Authorization

Late Modeling Web Clnt API Validatíon

Dyn. Change API Modeling API Admin. API

Exceptions Audit Trail ...

Process Engineer

Process Composer

Create Process Schema Modify Process Schema Check Process Schema …

Process Repository

Process Models

Application Components

8

+ x

Simple Process Model

Process Model S

Activity

XOR-Split/Join

AND-Split/Join

Patient Admission

Anamnesis & Clinical Examination

Non Operative Therapy

Sonography

MRT

X-ray

Initial Treatment & Operation Planning

Non Operative Therapy 1

Operative Treatment

Discharge & Documentation

clinicalSuspicionOf CruciateRupture = „Yes“

cruciateRupture = „Yes“ and operationIndicated = „Yes“

x

x x

x

+ +

9

Business Function 1

... Business

Function 2 Business

Function 3 Business

Function 4 Business

Function n

...

business functions

Function Perspective

EXECUTABLE PROCESS MODEL

control flow: order & execution constraints

Behavior Perspective

data objects & data flow

Information Perspective

time constraints (e.g., activity deadlines)

Time Perspective

organizational model (actors, roles,

organizational units)

Organization Perspective

activity implementations & application services

Operational Perspective

Proc

ess

Pers

pect

ives

10

Built-time versus Run-time - Process Type versus Process Instance Level -

11

+ x

Business Process – System Perspective

Enabled

Process Schema S

Completed Skipped

Execution Trace: σ1 = < „Patient Admission“, „Anamnesis & Clinical Examination“, „X-ray“>

Execution Trace: σ2 = < „Patient Admission“, „Anamnesis & Clinical Examination“, „Non Operative Therapy“>

Process Instance I1 Process Instance I2

Activity

XOR-Split/Join

AND-Split/Join

Activity States:

Patient Admission



Sonography

MRT

X-ray



Operative Treatment




x

x x

x

+ +

+ + x

x x x

+ + x

x x x

12

Activity Lifecycle

Inactive Enabled Running Completed

Skipped Suspended Failed

enable start complete

fail skip disable

skip

suspend resume

13

Offered Allocated Started Completed

Withdrawn

User Perspective and Work item Lifecycle

Joe Peter

MRT MRT

Process Instance I5

Patient Admission



Sonography

MRT

X-ray



Operative Treatment

Discharge & Documentation x

x x

x

+ +


Withdrawn

14

User Perspective

Joe Peter

MRT MRT

Process Instance I5

Patient Admission



Sonography

MRT

X-ray



Operative Treatment


x x

x

+ +

Let‘s do the MRT


Withdrawn


Withdrawn

15

User Perspective

Joe Peter Process Instance I5

Patient Admission



Sonography

MRT

X-ray



Operative Treatment


x x

x

+ +


Withdrawn


Withdrawn

16

User Perspective


Patient Admission



Sonography

MRT

X-ray



Operative Treatment


x x

x

+ +


Withdrawn


Withdrawn

17

User Perspective


Patient Admission



Sonography

MRT

X-ray



Operative Treatment


x x

x

+ +

Initial Initial

18


Business Processes and Workflows Flexibility Issues

19

Process Spectrum

Process Spectrum From fully predictable and highly repetitive to Fully unpredictable and non repetitive

20

Processes on the right side of the spectrum are mostly knowledge-intensive

Unpredictability Course of action depends on situation-specific parameters

Non-repeatability Two process instances hardly look the same

Emergence Future course of action depends on knowledge gained

through activity execution

Knowledge-intensive Processes

21

Flexibility Needs

22

Variability is typical for many domains and requires that processes are handled differently depending on the particular context

Drivers Product and service variability Differences in regulations Different customer groups Temporal differences

Variability

23

Knowledge-intensive processes cannot be fully pre-specified, but require loose specifications

Drivers Unpredictability Non-Repeatability Emergence

Looseness

24

Ability to adapt the process and its structure to temporary events

Drivers Special Situations Exceptions

Anticipation of Adaptation Planned Unanticipated

Adaptation

25

Ability of the implemented process to change when the business process evolves

Drivers

Evolution

External Internal Changing Business Context

Changing Technological Context

Changing Legal Context

Organizational Learning

Real-world Process PAIS

Design Errors

Technical Problems

Poor Internal Quality

represented in

provide feedback to

26

Extent of Evolution Incremental Continuous Process Improvement

Revolutionary Business Process Reengineering

Duration Temporary Permanent

Evolution

27

Swiftness Deferred Ongoing instances are not affected

Immediate Ongoing instances are affected

Visibility Observable Behavior Internal Structure

Evolution

28

Flexibility Issues along the Process Lifecycle

Instance I1

A

D

B

x x E C

Instance I1

A

D

B

x x E C

Schema S‘:

A

D

B

x x C

Traditional Process Lifecycle Support

Cre

ate

Inst

ance

s

Process Execution

Process engineer / Process administrator

Process participant

Arbeitsliste Tätigkeit 1 Tätigkeit 2 Tätigkeit 3 Tätigkeit 4

Schema S:

A

D

B

x x E C

Instance I1

A

D

B

x x E C

Execution Log

Process Monitoring

Need for Process Adaptation (Support for Planned and Unplanned Exceptions /

Special Cases)

Need for Process Evolution

Need for Variability Support

Need for Looseness of Process Specifications

[WRW+09] 29

Flexibility Needs and Technological Requirements

Flexibility Need

Dimension Technological Requirement

Variability Configuration Looseness Loosely-specified processes Adaptation Planned

Unplanned Exception Handling Ad-hoc Changes

Evolution Deferred Evolution Immediate Evolution Poor Internal Quality Organizational Learning

Versioning Process Instance Migration Refactoring Monitoring, Analysis and Mining

30


Business Processes and Workflows Pre-specified Process Models and Flexibility by Design

31

Basic Control Flow Concepts – Activities

Atomic Activities

Complex Activities

Automated Web services, Java applications, database function

Human Electronic forms

Refer to sub-process models

32

Basic Control Flow Concepts

Control Connectors (i.e., Gateways) (X)OR-Split / (X)OR-Join AND-Split / AND-Join

Control Flow Edges Sequence Flow Default Path

Transition Conditions

33

34

Sequence Flow Default Path

Transition Conditions

AND Gateway Atomic Activity

Basic Control Flow Concepts - Example

XOR Gateway

Basic Data Flow Concepts

Data objects + Data edges Data objects can be linked to activities via data edges

Read access Write access

referenced by transition conditions attached to outgoing messages

35

36

Data Object Data Edge – Read Access

Data Edge – Write Access

End Message with Data Obejct

Invoice

Transition Condition references

SparePartsList

Basic Data Flow Concepts - Example

Process Fragments Single Entry

Single Exit regions

Single activities: R2, R3, R4 Nested:

R2, R3, R4, R5 and R12 are contained in R1 Disjoint:

R6 and R7 37

Process Fragments Single Entry

Single Exit regions

Single activities: R2, R3, R4 Nested:

R2, R3, R4, R5 and R12 are contained in R1 Disjoint:

R6 and R7

Process Fragment

38

Process Structure Tree

Decomposition of process model into process structure tree

[VVK09] 39

Control Flow Patterns

Sequence Parallel-Spit (AND-Split) Synchronization (AND-Join) Exclusive Choice (XOR-Split) Simple Merge (XOR-Join) Structured Loop

40 [RHA+06, AHK+03, Wes07]

Activity Lifecycle

41

Inactive Enabled Running Completed

Skipped Suspended Failed

enable start complete

fail skip disable

skip

suspend resume

Sequence

42

AND-Split

43

AND-Join

44

XOR-Split

45

XOR-Join

46

Structured Loop

47

Deferred Choice

48

Interleaved Routing

49

Expressiveness and Flexibility by Design

50

Flexibility by Design (M

issi

ng) E

xpre

ssiv

enes

s an

d

Flex

ibili

ty b

y D

esig

n

51

Events Related to the Execution of Activities or Transition Conditions

52

Examples for Events Explanation

start(A) Activity A started

complete(A:d1=v1) Activity A completed writing data object d1 with value v1

start(cond1) Evaluation of transition condition cond1 started

complete(cond1:true) Transition condition cond1 evaluated to true

start(cond2) Evaluation of transition condition cond2started

complete(cond2:false) Transition condition cond2 evaluated to false

start(B) Activity B started

53

d5

Enabled

B) Execution Traces

Completed Skipped

σ1 = < start(1), complete(1:d1=v1), start(2), complete(2:d2=v2), start(3), complete(3,d3=v3;d4=v4), start(cond1), complete(cond1:true), start(cond2), complete(cond2:true)>

σ2 = < start(1), complete(1:d1=v5) >

Process Instance I1

Process Instance I2

Process Instance I3

Process Instance I4

Activity States:

A) Process Model Process Model S

1 2

4

+ +

C) Process Instances

1: Enter Repair Order 2: Determine Defect 3: Check Availability of Spare Parts 4: Order Spare Parts 5: Repair Car 6: Provide Replacement Car 7: Create Invoice 8: Notify Customer

Running

3 8

7 + +

x x 5

6 x x

cond1

cond2 + + + +

x x

x x

+ + + +

x x

x x

+ + + +

x x

x x

d1

d2 d3

d4

d1: Repair Order d2: Repair Service Request d3: Spare Parts List d4: Estimated Duration d5: Invoice

σ3 = < start(1), complete(1:d1=v6), start(2), complete(2:d2=v7), start(3), complete(3,d3=v8;d4=v9), start(cond1), complete(cond1:false), start(cond2), complete(cond2:false), start(5), complete(5), start(7), start(8), complete(7:d5=v10), complete(8)>

+ + + +

x x

x x

σ4 = < start(1), complete(1:d1=v11), start(2), complete(2:d2=v12), start(3), complete(3,d3=v13;d4=v14), start(cond1), complete(cond1:true), start(cond2), complete(cond2:false), start(4), complete(4) >

Exam

ples

– E

xecu

tion

Trac

es

Verification of Process Models

Soundness Option to Complete Proper Completion No dead activities

Data Flow Correctness No missing data No dead activities No lost updates

[WVA+09]

[RAS09]

54

Example: Option to Complete

55

Option to Complete A process instance, once started, can always complete.

Example: Proper Completion

56

Proper Completion When a process instance completes there exists no related activity of this instance which is still running or enabled.

Example: Dead Activity

57

No dead activities A process model does not contain any dead activity, i.e., for each activity there exists at least one completed trace producible on that model and containing this activity.

Example: Missing Data

58

Missing Data The data flow schema of a process model might cause missing data at run-time if a data object exists which can be read during run-time without having been written by any preceding activity or provided by the outside environment (i.e., by a start message).

Data Flow Errors: Unnecessary Data

59

Unnecessary Data A data object written by an activity of process model is called unnecessary if it is not read by any subsequent activity or transition condition or passed to the outside environment via an end message.

Data Flow Errors: Lost Updates

60

Lost Updates The data flow schema of a process model might cause lost data at run-time if a data object, which is written by an activity, is updated by a subsequent activity, but without reading the data object in between.

Well-stuctured versus Unstructured

A well-structured or block-structured process model is composed of blocks (Single-Entry Single-Exit fragments), which can be nested, but must not overlap

Blocks can be single activities, sequences, parallel branchings, alternative branchings, loop blocks or the entire process model

Unstructured models require advanced verification techniques

Unstructured models are more difficult to understand and are a considerable source of errors

61

Unstructured vs. well-structured Process Model

62

62

References

• [AHK+03] W.M.P van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros. Workflow Patterns. Distributed and Parallel Databases, 14(3), pages 5-51, July 2003.

• [RHA+06] N. Russell, A.H.M. ter Hofstede, W.M.P. van der Aalst, and N. Mulyar. Workflow Control-Flow Patterns: A Revised View. BPM Center Report BPM-06-22 , BPMcenter.org, 2006.

• [TAS09] Nikola Trcka, Wil M. P. van der Aalst, Natalia Sidorova: Data-Flow Anti-patterns: Discovering Data-Flow Errors in Workflows. CAiSE 2009: 425-439

• [VVK09] Jussi Vanhatalo, Hagen Völzer, Jana Koehler: The refined process structure tree. Data Knowl. Eng. 68(9): 793-818 (2009)

• [Wes07] Mathias Weske: Business Process Management: Concepts, Languages, Architectures, Springer 2007.

• [WVA+09] Wynn, M.T., Verbeek, H.M.W., Aalst, W.M.P. van der, Hofstede, A.H.M. ter and Edmond, D. (2009). Business process verification : finally a reality! Business Process Management Journal, 15(1), 74-92.

63


Business Processes and Workflows Configurable Process Models

64

Motivation – Change Management Process

3b) Stm. 3c) Stm.

4) Integration of Stm.

3a) Stm. Develop- ment (Dev.)

5) Permission

Project Leader

2) Request for Statements (Stm.)

Production- Planning (PP)

Pilot

6) Realization

7) Completion

1) Change request Applier

x Decision Board

x Dev.

Responsible

< <

Responsible

Standard Process variant I: Quality issues affected

Process variant II: Low risk/costs; long to realize

3b) Stm. 3c) Stm.


3a) Stm. Dev.

5) Permission

Project Leader


PP Pilot

6) Realization

7) Completion


x Decision Board

x Dev.

Responsible <

<

Responsible

3d) Stm.

Process variant III: Low risk/ costs; fast to realize; affects quality issues

d)

3b) Stm. 3c) Stm


3a) Stm. Dev.

5) Permission

Project Leader


PP Pilot

6b) Undo Realization

7) Completion


x

Decision Board

x

Responsible

< <

Responsible

< 6) Realization

Dev.

3b) Stm. 3c) Stm.


3a) Stm. Dev.

5) Permission

Project Leader


PP Pilot

6b) Undo Realization

7) Completion


x

Decision Board

x

Responsible

< <

Responsible

3d) Stm.

<

6) Realization Dev.

Quality Department (QDept.)

Dev. Dev.

QDept.

65

Reception

Example: Vehicle Repair Process

Standardized Process

Repair Diagnosis Hand Over

Reception Repair Diagnosis Hand Over Final Check

Maintain

Variant 3: Fast Run and Security Critical Repair

Variant 2: Security Critical Repair Repair Hand Over

Maintain

Reception Repair Diagnosis Hand Over Final Check

Variant 1: Fast Run

Diagnosis

Reception

Motivation – Vehicle Repair Process

Conclusion: Many processes with different variants, depending on the process context.

66

Fzg. Annahme

Reparatur Diagnose

d) Variant 3: Fast Run and security-critical Repair

Fzg. Übergabe

Prüfung Fzg. Annahme

Reparatur Diagnose

c) Variant 2: Security-critical Repair

Wartung

Prüfung Fzg. Annahme

Reparatur Diagnose Dauer = 2 Dauer = 2

b) Variant 1: Fast Run

Fzg. Übergabe

a) Standardized Process

Reception Repair Diagnosis Hand Over

Maintain

Multi-Model Solution

Single-Model Solution

Reception Hand Over

Diagnosis

Maintain

Diagnosis Shortened

Final Check

Variant 2 or Variant 3

Standard or Variant 1


Standard or Variant 2

Repair


Standard or Variant 2 or Variant 3 Standard or

Variant 2

Conclusion: Both approaches can be supported by commercial BPM tools, but do not enable transparent and explicit management of process variants

Configuring Process Variants in Existing BPM Tools

67

Motivation – Handling Medical Examinations 68

(c) 2012 Barbara Weber, Manfred Reichert

Variety of related variants

• Same business

objective • Commonalities

• Differences due

to varying application context

Two Main Approaches

Behaviour-based Approaches for Capturing Process

Variability

Structural Approaches for Capturing Process Variability

69 (c) 2012 Barbara Weber, Manfred Reichert

Two Main Approaches

Behaviour-based Approaches for Capturing Process

Variability



Configurable Nodes

Main idea: configurable nodes Extension of an existing process modeling language by adding

configurable elements E.g., C-EPC, E-YAWL

Configurable nodes represent variation points and can be associated with configuration alternatives

Possible combinations of configuration alternatives can be restriceted through constraints


Configurable Activities

Included (ON) Excluded (OFF) Conditional (OPT)


Configurable Control Connectors

Configurable OR Configurable XOR Configurable AND

73

Can be configured to a connector

equally restrictive or less restrictive


Configurable Control Connectors

Configurable OR Configurable XOR Configurable AND

74

Can be configured to a connector

equally restrictive or less restrictive


Configuration Requirements and Guidelines

Requirements Define constraints

over the configuration alternatives that can be chosen

Guidelines Do not prescribe

mandatory constraints, but serve as recommendations

75

a


Configurable Model: Handling Medical Examinations


Hiding and Blocking

Capturing variability in a language-independent way

(1) Represent process model as a labeled transition system (LTS)

(2) Apply hiding and blocking operators for configuring LTL-based reference process models


Expressing Process Behavior through Labeled Transition Sytems


Hiding and Blocking

Blocking: enables encapsulation – execution of an atomic activity (event is disabled)

Hiding: enables abstraction – execution of an event becomes non-observable (activity is replaced by silent activity)


Hiding and Blocking Example

(c) 2010 Barbara Weber 81

Two Main Approaches

Behavior-based Approaches for Capturing Process

Variability



Deriving Variants through Structurally Changing a Base Process Model


Representing a Process Family

Through a configurable base process model Policy 1: Standard Process Policy 2: Most frequently used process Policy 3: Superset of all process variants Policy 4: Intersection of all process variants

and a related set of pre-specified changes Adjustment points Change options (i.e., a grouping of change operations)


Examples of Change Operations


Exa

mpl

e of

Bas

e Pr

oces

s +

Opt

ions


Constraining Allowed Combinations of Change Operations

Implications Mutual exclusion Hierarchy


Context Model


Context-specific selection of change operations Context variables

The Whole Approach

(1) Select relevant options All change options whose context rules evaluate to true are selected

(2) Ensure compliance of the selected options with option constraints Compliance with option constraints has to be checked

(3) Determine the order in which options shall be applied (4) Configuring the base process by applying the selected

options and their change operations to it


Questionnaire-driven Process Configuration

(1) Questionnaire Model

(2) Using Questionnaire Models for Configuring a Reference Process Model (a) Linking Domain Facts and Configurable Activities

(b) Linking Domain Facts and Configurable Connectors


Questionnaire Model

(c) 2010 Barbara Weber

92

Linking Domain Facts and Configurable Activities


Linking Domain Facts and Configurable Connectors


Feature Diagram


References

• [GAV+08] Florian Gottschalk, Wil M. P. van der Aalst, Monique H. Jansen-Vullers, Marcello La Rosa: Configurable Workflow Models. Int. J. Cooperative Inf. Syst. 17(2): 177-221 (2008)

[HBR10] Alena Hallerbach, Thomas Bauer, Manfred Reichert: Capturing variability in business process models: the Provop approach. Journal of Software Maintenance 22(6-7): 519-546 (2010)

[HBR09] Alena Hallerbach, Thomas Bauer, Manfred Reichert: Guaranteeing Soundness of Configurable Process Variants in Provop. CEC 2009: 98-105

[HBR08] Alena Hallerbach, Thomas Bauer, Manfred Reichert: Managing Process Variants in the Process Life Cycle. ICEIS (3-2) 2008: 154-161

• [Ros09] M. La Rosa: Managing Variability in Process-Aware Information Systems, PhD Thesis, Queensland University of Technology, Brisbane, Australia. April 2009.

• [RDH09] M. La Rosa, M. Dumas, A.H.M. ter Hofstede: Modelling Business Process Variability for Design-Time Configuration. In J. Cardoso, W.M.P. van der Aalst (editors), Handbook of Research on Business Process Modeling, IDEA Group – Information Science Reference, 2009.

• [RLS+07] M. La Rosa, J. Lux, S. Seidel, M. Dumas and A.H.M. ter Hofstede: Questionnaire-driven Configuration of Reference Process Models. In Proc. CAiSE 2007, Trondheim, Norway. LNCS Vol. 4495, pp. 424–438, Springer, 2007.

• [RoAa07] Michael Rosemann, Wil M. P. van der Aalst: A configurable reference modelling language. Inf. Syst. 32 (1): 1-23 (2007)

96


Business Processes and Workflows Exception and Compensation Handling

97

Process Adaptations

Planned Unplanned

Exception Handling Ad-hoc Changes

98

Exception Handling in PAIS

Activity Failure

Sources for Exceptions

Technical Semantical

Deadline Expiry

Resource Unavailability

Inconsistence real-world / PAIS

Constraint Violations

Upon detection of a particular exception

a suitable handler is chosen

Trying Alternatives

Ordered Unordered

Exception Handler

Add Behavior

Deferred Fixing

Immediate Fixing

Retry Exception-driven Rework

Cancelling Behavior

Reject Compensate Resource Patterns

Delegate Escalate …

99

Exception Handling

Simple Handler

Exception Handling

Scopes

100

Exception Handling Patterns - Ordered Alternatives -

101 [LCB+10]

Exception Handling Patterns - Unordered Alternatives -

102

Exception Handling Patterns - Immediate Fixing -

103

Exception Handling Patterns - Deferred Fixing -

104

Exception Handling Patterns - Retry -

105

Exception Handling Patterns - Reject -

106

Exception Handling Patterns - Compensate -

107

Resource Patterns

Exception Handling Patterns (like Deferred Fixing, Reject etc.) focus on behavioral changes

Many exceptions (e.g., resource unavailability or deadline expiry) require changes regarding resource perspective like delegation, escalation or reallocation

108 [RHE+04]

Resource Patterns

109

Selected Resource Patterns

110

Flexible Handling of Work Items

Application of Exception Handling patterns often requires changes to the lifecycle of work items.

Work items may have to be Skipped Redone Done ahead of time Canceled Suspended/Resumed

111 [RAH+06]

Flexible Handling of Work items

112

Flexible Handling of Workitems

113

A B C D

System Log Bc Cc Ac

Commit Commit Commit

normal processing

Abort!

Rollback

Abort Transaction (Rollback Work)

Compensation of C

Compensation of B

Compensation of A ready!

The SAGAS concept

Compensation Information

[GaSa87]

114

Compensation Handling - Sagas

114

Compensation Spheres

115

Compensation Spheres

116

process

scope

scope

scope

scope scope

scope

scope

Scopes provide a context which influences the execution behavior of its enclosed activities

Isolated scopes provide control of concurrent access to shared resources

scope

Local declarations: partner links, message exchanges, variables, correlation sets

Local handlers: event handlers, fault handlers, a termination handler, and a compensation handler

Compensation handler to undo persisted effects of already

completed activities

Termination handler to deal with forced scope termination

(external faults)

primary activity

scope

117

Compensation and Fault Handling in BPEL (1)

117

process

scope

invoke

invoke

invoke

fault handler

compensate compensation

handler

compensate

compensation handler

compensation handler

invoke

invoke

1. Do some work (successfully invoke two services)

2. Invoke another service (throws fault)

3. The fault triggers the process-level fault handler

4. Compensate previous work

5. Propagate compensation

6. Undo work (in reverse order)

This example shows the default compensation behavior supported by BPEL; i.e., a completed scope is com-pensated by invoking the compensation handlers of its constituting activities in reverse order. How-ver, a more specific compensation handler for a scope may be provided as well (e.g., only com-pensating some of the already completed activities or invoking a specific process dealing with the exception).

118

Compensation and Fault Handling in BPEL (2)

118

Exlets

119 [AHA+07]

References

[AHA+07] Michael Adams, Arthur H. M. ter Hofstede, Wil M. P. van der Aalst, David Edmond: Dynamic, Extensible and Context-Aware Exception Handling for Workflows. OTM Conferences (1) 2007: 95-112

[LCO+10]Barbara Staudt Lerner, Stefan Christov, Leon J. Osterweil, Reda Bendraou, Udo Kannengiesser, Alexander E. Wise: Exception Handling Patterns for Process Modeling. IEEE Trans. Software Eng. 36(2): 162-183 (2010)

[MoSa87] Hector Garcia-Molina, Kenneth Salem: Sagas. SIGMOD Conference 1987: 249-259 [NAH06] N. Russell, W.M.P. van der Aalst, and A.H.M. ter Hofstede. Exception Handling Patterns in

Process-Aware Information Systems. BPM Center Report BPM-06-04 , BPMcenter.org, 2006. [RHE+04] N. Russell, A.H.M. ter Hofstede, D. Edmond, and W.M.P. van der Aalst. Workflow Resource

Patterns. BETA Working Paper Series, WP 127, Eindhoven University of Technology, Eindhoven, 2004.


Business Processes and Workflows Handling Unforeseen Exceptions

121

Process Adaptations

Planned Unplanned

Exception Handling Ad-hoc Changes

122

User View on an Ad-hoc Process Change

Explanation Operation Risks

X-Ray

Check Anesthesiology

Examination

End

Start Examinations

U Wallace, Edgar

U Miller, Anne

U Smith, Karl

U Jones, Isabelle

Exception – We need an additional lab test !

Lab Test

Explanation Operation Risks

X-Ray

Check Anesthesiology

Examination

123

123

Behavioral Changes Require Structural Process Model Adaptations

124

Behavioral Changes Require Adaptations of the Process Instance State

125

Behavioral Changes Require Adaptations of the Process Instance State

126

Behavioral Changes Must not Violate Process Model Soundness and Proper Instance Execution

127

No Proper Completion

ensured. End node can be reached while B is still enabled

Data flow error caused by

missing data

x

+ + x x x

Process Instance Level

Execution Trace: σ1 = < „Patient Admission“, „Anamnesis & Clinical Examination“, „X-ray“>

Execution Trace: σ2 = < „Patient Admission“>

Process Instance I1

Process Instance I2

x

x x x + +

Process Type Level

Process Schema S

Activity

XOR-Split/Join

AND-Split/Join

Patient Admission x Anamnesis &

Clinical Examination


Sonography

MRT

X-ray



Operative Treatment


+ + x x

x

x

+



Ad-hoc Changes of a Process Instance Must Not Affect any Other Process Instances

128

128

Change Primitives Add node Remove node Add edge Remove edge Move edge

High-Level Change Operations Combines a set of change primitives Referred to as Adaptation Patterns in the following

Structurally Adapting Pre-Specified Process Models

129

129

Adaptation Patterns

130 [WRR08]

Adaptation Patterns versus Change Primitives

131

Adaptation Patterns versus Change Primitives

Change Primitives Process Adaptation Patterns

Operate on single elements of process schema

Provide high-level change operations

Correctness has to be checked after adaptation

Correctness-by-construction

No Assumption regarding structure of process schema

Process schema needs to be block-structured

132

Dynamic Change Bug

133

134

Correctness of Process Instance Changes

Ensuring Dynamic Correctness

Need for general correctness criterion

State Compliance

invoice make invoice

Schema S‘:

A B

C

D E F

send invoice

Schema S:

A B

C

D

E F

activated step

May the depicted schema change be propagated to the process instance?

[ReDa98, RRW08a, RRD04a, RRD04b]

134

135


Ensuring Dynamic Correctness

invoice make invoice

Schema S‘:

A B

C

D E F

send invoice

Schema S:

A B

C

D

E F

activated step

<A> , , <D> Trace reproducible on new schema?

More complicated: loop backs

Further challenges: - How to efficiently check for compliance? - How to efficiently migrate process instances? [RRD04a, RRD04b]

135

x

+ + x x x

Execution Trace: σ3 = < „Patient Admission“, „Anamnesis & Clinical Examination“, „MRT“, „X-ray“, „Sonography“>

Process Instance I3

Process Instance Level

Process Type Level

Process Schema S

Activity

XOR-Split/Join

AND-Split/Join




Sonography

MRT

X-ray



Operative Treatment


+ + x x

x

x

+



I3 is not state compliant with change

Delete (I3, MRT)

136


[ReDa98]

136

User Assistance & Change Reuse (1)

The ProCycle (= ADEPT + CBRFlow) Approach for Assisting Users in Defining and Reusing Changes:

Annotate ad-hoc changes with information about the reasons for their introduction

Support users in retrieving past ad-hoc changes applied in similar context

Assist users in reusing a past ad-hoc change when coping with an exceptional situation

137

[RWR+05, WRW+09, WRR+05, WRW06, WWB04]

137

Patient Admission



Sonography

MRT

X-ray



Operative Treatment


Process Instance I1 Delete(I1,MRT)

pdc1 = The treatment of cruciate ruptures routinely includes a magnetic resonance tomography (MRT), an X-ray and a sonography. However, for a particular patient the MRT may have to be skipped as the respective patient has a cardiac pacemaker. solc1 = <Delete(SI,MRT)> qaSetc1= {(Does the patient have a cardiac pacemaker?, patient.problemList.hasPacemaker = ‘Yes‘)}

freqc1 = 1

Cas

e c 1

Memorization of instance deviations including their application context

Application Context Model

+

x x

+ x x

138


138

List of Question with Possible Answers

Answer Questions with Answer Expressions

Process participant


Exception for Instance I

Create List of Questions with Possible Answers

Calculate Similarity and Rank Cases

Add answered questions to query qu

Answer Question

Semi-automated retrieval of similar instance deviations using conversational case-based reasoning

Initiate Case Retrieval

Show Ranked Cases +

CCBR Component

139


139

qaSetc1 = {(Does the patient have a cardiac pacemaker?, Patient.problemList.hasPacemaker = 'Yes')}

List of Questions with Possible Answers Question Possible Answers

Does the patient have a cardiac pacemaker? {Patient.problemList.hasPacemaker = ‚Yes‘, OTHERANSWER}

Does the patient have fluid in the knee? {‚A significant amount‘, OTHERANSWER}

Does the patient have an acute effusion of the knee? {‚Yes‘, OTHERANSWER}

qaSetc2 = {(Does the patient have fluid in the knee?, 'A significant amount'),

(Does the patient have an acute effusion of the knee?, 'Yes')} Case c1

Case c2

Query qu

Question Given Answer Does the patient have a cardiac pacemaker? OTHERANSWER

List of Retrieved Cases for Query qu Case Appl. Context Similarity

c2 50%

c1 0%

Retrieving similar instance deviations based on the actual context

1||

),(),(*21),( +

−=

c

cc

qaSetqaSetqudiffqaSetqusamecqusim

Query qu‘

Question Given Answer Does the patient have a cardiac pacemaker? OTHERANSWER

Does the patient have fluid in the knee? ‚A significant amount‘

List of Retrieved Cases for Query qu‘ Case Appl. Context Similarity

c2 75%

c1 0%

140


140

Execution Trace: Patient Admission, Anamnesis & Clinical Examination, X-Ray, MRT

List of Retrieved Cases Case Similarity

c2 75% c2 does not have any effect, but is adjustable

c1 0% c1 is not case compliant and not adjustable

Retrieving similar instance deviations based on the actual context + status




Sonography

MRT

X-ray



Operative Treatment


+ + x

Process Instance I1

Are the instance deviations of these cases compliant with the process instance to be modified?

Is change Δc1

= <Delete(SI,MRT)>

applicable?

NO

Is change Δc2=<Insert(SI, Follow-Up Examination,

Non Operative Therapy, XOR-Join1), Insert(SI, Puncture, Follow-Up

Examination, XOR-Join1>

applicable? YES, but no effect

x

x

141


141

References

[ReDa98] Manfred Reichert, Peter Dadam: ADEPTflex-Supporting Dynamic Changes of Workflows Without Losing Control. J. Intell. Inf. Syst. 10(2): 93-129 (1998)

[RRD04a] Stefanie Rinderle, Manfred Reichert, Peter Dadam: Correctness criteria for dynamic changes in workflow systems - a survey. Data Knowl. Eng. 50(1): 9-34 (2004)

[RRD04b] Stefanie Rinderle, Manfred Reichert, Peter Dadam: Flexible Support of Team Processes by Adaptive Workflow Systems. Distributed and Parallel Databases 16(1): 91-116 (2004)

[RRW08] Stefanie Rinderle-Ma, Manfred Reichert, Barbara Weber: Relaxed Compliance Notions in Adaptive Process Management Systems. ER 2008: 232-247

[RWR+05] Stefanie Rinderle, Barbara Weber, Manfred Reichert, Werner Wild: Integrating Process Learning and Process Evolution - A Semantics Based Approach. Business Process Management 2005: 252-267

142

References

[WRR05] Barbara Weber, Stefanie Rinderle, Werner Wild, Manfred Reichert: CCBR-

Driven Business Process Evolution. ICCBR 2005: 610-624 [WRR08] Barbara Weber, Manfred Reichert, Stefanie Rinderle-Ma: Change

patterns and change support features - Enhancing flexibility in process-aware information systems. Data Knowl. Eng. 66(3): 438-466 (2008)

[WRW+09] Barbara Weber, Manfred Reichert, Werner Wild and Stefanie Rinderle-Ma: Providing Integrated Life Cycle Support in Process-Aware Information Systems. In: International Journal of Cooperative Information Systems 18 (2009) 1, pp. 115-165.

[WRW06] Barbara Weber, Manfred Reichert, Werner Wild: Case-Base Maintenance for CCBR-Based Process Evolution. ECCBR 2006: 106-120

Barbara Weber, Werner Wild, Ruth Breu: CBRFlow: Enabling Adaptive Workflow Management Through Conversational Case-Based Reasoning. ECCBR 2004: 434-448

143

Business Processes and Workflows Process Monitoring, Mining & Analysis


144

(c) 2010 Barbara Weber

145

Activity Event User Timestamp

Patient Admission Start Garry 2007/09/08 15:30

Patient Admission Complete Garry 2007/09/08 15:45


Start Helen 2007/09/09 11:00


Complete Helen 2007/09/09 11:45

X-Ray Start Paula 2007/09/09 13:00

Sonography Start Sandy 2007/09/09 13:20

X-Ray Complete Paula 2007/09/09 14:00

Sonography Complete Sandy 2007/09/09 14:30


Start Peter 2007/09/10 09:00


Complete Peter 2007/10/10 09:45

Follow-up Examination Start Helen 2007/10/12 11:07

Follow-up Examination Complete Helen 2007/10/12 11:20

Puncture Start Helen 2007/10/12 11:21

x

+ + x x x

c.) Execution Log - Process Instance 4711

Process Instance 4711

a.) Process Model

Process Model S

6

1 2

10 4 5

7

8 9

3

x

+ + x x x

b.) Process Instances

1: Patient Admission 2: Anamnesis & Clinical Examination 3: Non Operative Therapy 4: x-Ray 5: MRT 6: Sonography

7: Non Operative Therapy 1 8: Initial Treatment & Operation Planning 9: Operative Therapy 10: Discharge & Documentation



Enabled Completed Skipped Activity States:

Insert(S, Follow-up Examination, Non Operative Therapy, XOR-Join 1) Insert(S, Puncture, Follow-up Examination, XOR-Join 1)

Delete (S,MRT)

XOR-Join1

XOR-Join1

d.) Change Log - Process Instance 4711 Change TX

Applied Changes User Timestamp

001 Delete (S, MRT) Paula 2007/09/09 12:50

002 Insert(S, Follow-up Examination, Non Operative Therapy, XOR-Join 1)

Helen 2007/10/10 09:00

002 Insert(S, Puncture, Follow-up Examination, XOR-Join 1)

Helen 2007/10/10 09:00

Exe

cuti

on a

nd C

hang

e Lo

gs

- Res

tori

ng S

truc

ture

and

Sta

te o

f Pro

cess

Ins

tanc

es -

146

Process Instance 4711 2007/09/09 10:30

6

1 2

10

4

5

7

8 9

3

x

+ + x x x

XOR-Join1

146

Execution and Change Logs - Restoring Structure and State of Process Instances -




Execution Log - Process Instance 4711, Log Entries before 2007/09/09 10:30


6

1 2

10

4

5

7

8 9

3

x

+ + x x x

XOR-Join1

147

147


6

1 2

10

4

5

7

8 9

3

x

+ + x x x

XOR-Join1





Change TX


001 Delete (S, MRT) Paula 2007/09/09 12:50

Execution Log: Log Entries between 2007/09/09 10:30 and 2007/09/09 12:45

Change Log: Log Entries between 2007/09/09 10:30 and 2007/09/09 12:45


X-Ray Start Paula 2007/09/09 13:00

Sonography Start Sandy 2007/09/09 13:20

X-Ray Complete Paula 2007/09/09 14:00

Sonography Complete Sandy 2007/09/09 14:30


Start Peter 2007/09/10 09:00


Complete Peter 2007/10/10 09:45

Execution Log: Log Entries between 2007/09/09 12:45 and 2007/10/10 09:46


6

1 2

10

4

5

7

8 9

3

x

+ + x x x

XOR-Join1

148


Change Log: Log Entries between 2007/09/09 10:30 and 2007/09/09 12:45


6

1 2

10

4

5

7

8 9

3

x

+ + x x x

11 12

11: Follow-up Examination 12: Puncture

XOR-Join1

Change TX


002 Insert(S, Follow-up Examination, Non Operative Therapy, XOR-Join 1)

Helen 2007/10/10 09:00

002 Insert(S, Puncture, Follow-up Examination, XOR-Join 1)

Helen 2007/10/10 09:00

Design-time (a-priori) and run-time (a-posteriori) questions

processdesign

implementation/configuration

processenactment

diagnosis

Run-time Design-time

- process mining - verification - validation - performance analysis

149

Process mining can be used for: Process discovery (What is the process?) Conformance Testing (Are we doing what was specified?) Log verification (Is there any undesired behavior?)

process mining

Start

Register order

Prepareshipment

Ship goods

(Re)send bill

Receive paymentContactcustomer

Archive order

End

Process Mining

150

informationsystem

operationalprocess

processmodels

eventlogs

models

processdiscovery

conformancetesting

records

configures

supports/controls

(un)desiredproperties

log-based verification

refers to

What can Process Mining be used for?

151

MXML Format

152

Process Discovery – Reversing the Process

153

1) basic performance metrics

2) process model Start

Register order

Prepareshipment

Ship goods

(Re)send bill

Receive paymentContactcustomer

Archive order

End

3) organizational model 4) social network

5) performance characteristics

If …then …

153 [ARS05, ARV+10, AWM04, GGM+07, GGP+06, HeKa04, LRW10, MWA07, Sch04, WWA+10]

154

A) Original Process Model

Original Process Model S

6

1 2

10 4 5

7

8 9

3

x

+ + x x x

1: Patient Admission 2: Anamnesis & Clinical Examination 3: Non Operative Therapy 4: x-Ray 5: MRT 6: Sonography

7: Non Operative Therapy 1 8: Initial Treatment & Operation Planning 9: Operative Therapy 10: Discharge & Documentation



XOR-Join1

B) Discovered Process Model

Activities FollowUpExamination and Puncture are not part of the original model, but appear in 132 traces

Activity MRT is executed less frequently than X-Ray and Sonography, i.e., it has been deleted for some of the instances

Proc

ess

Dis

cove

ry

- Heu

rist

ic M

iner

-

[WeAa03]

Conformance Testing

Registerorder

Prepareshipment

Shipgoods

Receivepayment

(Re)sendbill

Contactcustomer

Archiveorder

Materialis released

TO itemconfirmed

withoutdifferences

Warehouse/Stores

Transferorderitem

is confirmed

Paymentmust

be effected

PurchaseRequisition

Requirementfor materialhas arisen

Requisitionreleased

for schedulingagreement

schedule/SA release

InvoiceVerification

Purchaserequisitionreleased

for purchaseorder

Inbounddeliveryentered

Goodsreceived

Goodsreceiptposted

GoodsReceipt

Purchaseorder

created

Purchasing

Invoicereceived

Conformance Testing - Example -

156

Log based verification

Can there any undesired properties be observed in the log? 157 [ABD07]

Lecture Workflow Management by Will van der Aalst (Univ. of Eindhoven), http://www.workflowcourse.com

Some slides of the process mining part are based on

http://www.workflowcourse.com/

References

[ABD07] Wil M. P. van der Aalst, H. T. de Beer, Boudewijn F. van Dongen: Process Mining and Verification of Properties: An Approach Based on Temporal Logic. OTM Conferences (1) 2005: 130-147

[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.

[ARS05] Wil M. P. van der Aalst, Hajo A. Reijers, Minseok Song: Discovering Social Networks from Event Logs. Computer Supported Cooperative Work 14(6): 549-593 (2005)

[ARV+10] Wil M. P. van der Aalst, Vladimir Rubin, H. M. W. Verbeek, Boudewijn F. van Dongen, Ekkart Kindler, Christian W. Günther: Process mining: a two-step approach to balance between underfitting and overfitting. Software and System Modeling 9(1): 87-111 (2010)

[AWM04] W.M.P. van der Aalst, A.J.M.M. Weijters, and L. Maruster. Workflow Mining: Discovering Process Models from Event Logs. IEEE Transactions on Knowledge and Data Engineering 16(9):1128-1142, 2004.

References

[GGM+07] Gianluigi Greco, Antonella Guzzo, Giuseppe Manco, Domenico

Saccà: Mining unconnected patterns in workflows. Inf. Syst. 32(5): 685-712 (2007)

[GGP06] Gianluigi Greco, Antonella Guzzo, Luigi Pontieri, Domenico Saccà: Discovering Expressive Process Models by Clustering Log Traces. IEEE Trans. Knowl. Data Eng. 18(8): 1010-1027 (2006)

[HeKa04] Joachim Herbst and Dimitris Karagiannis: Workflow Mining with InWoLvE. Computers and Industry 53(3): 245-264 (2004).

[LRW10] Chen Li, Manfred Reichert, Andreas Wombacher: The Minadept Clustering Approach for Discovering Reference Process Models Out of Process Variants. Int. J. Cooperative Inf. Syst. 19(3-4): 159-203 (2010)

[MWA07] Ana Karla A. de Medeiros, A. J. M. M. Weijters, Wil M. P. van der Aalst: Genetic process mining: an experimental evaluation. Data Min. Knowl. Discov. 14(2): 245-304 (2007)

References

[PiGo04] S. Pinter and M. Golani: Discovering workflow models from activities' lifespans. Computers and Industry 53(3): 283-296 (2004).

[RoAa08] Anne Rozinat, Wil M. P. van der Aalst: Conformance checking of processes based on monitoring real behavior. Inf. Syst. 33(1): 64-95 (2008)

[Sch04] Guido Schimm: Mining exact models of concurrent workflows. Computers and Industry 53(3): 265-281 (2004).

[WeAa03] A.J.M.M. Weijters and W.M.P. van der Aalst. Rediscovering Workflow Models from Event-Based Data using Little Thumb. Integrated Computer-Aided Engineering, 10(2):151-162, 2003.

[WWA+10] Lijie Wen, Jianmin Wang, Wil M. P. van der Aalst, Biqing Huang, Jiaguang Sun: Mining process models with prime invisible tasks. Data Knowl. Eng. 69(10): 999-1021 (2010)

Business Processes and Workflows Process Evolution


162

Drivers

Evolution

External Internal Changing Business Context

Changing Technological Context

Changing Legal Context

Organizational Learning

Real-world Process PAIS

Design Errors

Technical Problems

Poor Internal Quality

represented in

provide feedback to

163

Schema Evolution 164

164

Change Support Features Schema Evolution, Version Control and Instance Migration

Schema Evolution Changes at the process type level

How to deal with running instances when adapting the original process schema? Scenario 1: No version control Scenario 2: Co-existence of instances of old / new schema Scenario 3: Change propagation and instance migration

165

165

Schema is overwritten and instances are migrated

A B D

C

+ + E F X

Y

A B D

C

+ + E F X

Y

Type change overwrites schema S

Process Schema S’

Schema Evolution

Process Schema S

Process Instance I1

Change is propagated to

all running process instances

Process Instance I2

Process Instance I1

Process Instance I2

Insert X between A and B Insert Y between C and AND-Join1

AND-Split1 AND-Join1

A B D

C

+ + E F

A B D

C

+ + E F

A B D

C

+ + E F

A B D

C

+ + E F X

Y


Inconsistent state

Scenario 1 - No Version Control 166

166

Co-existence of instances of different schema versions

Scenario 2 - Version Control

A B D

C

+ + E F X

Y

Type change results into a new version of schema S

Process Schema S’

Schema Evolution

Process Schema S

Process Instance I1

Process Instance I2

Process Instance I4

Process Instance I5

Old instances remain with schema S Instances created from S (before schema evolution) Instances created from S’ (after schema evolution)


A B D

C

+ + E F A B D

C

+ + E F X

Y

A B D

C

+ + E F

A B D

C

+ + E F A B

D

C

+ + E F X

Y



167

167

Compliant instances are migrated to the new schema

Scenario 3 – Instance Migration

Type change results into a new version of schema S

Process Schema S‘

Schema Evolution

Process Schema S

Process Instance I1

Propagation of compliant

process instances to schema S’

(incl. state adaptations)

Process Instance I2

Process Instance I1

Migration of compliant process instances to S’


A B D

C

+ + E F A B D

C

+ + E F X

Y

A B D

C

+ + E F

A B D

C

+ + E F Process Instance I2 not compliant with S’

A B D

C

+ + E F X

Y



168

[RRD04a] 168

Process Model Refactoring

(1) Identify refactoring opportunities

(2) Determine which refactoring should be applied

(3) Ensure that the applied refactoring preserves model behavior

(4) Apply the refactoring

(5) Assess the effect of the refactoring on the quality characteristics of the process model repository

169

Catalogue of Process Model Smells

PMS5: Lazy Process Model

PMS8: Frequently Occurring Variant Change

[WeRe08, WRR+xx] 170

Process Model Smells: Example

PMS3: Redundant Process Fragment

171


PMS1: : Non Intension Revealing Naming of Activity

172


PMS4: Large Process Model

173

Catalogue of Process Model Refactorings

RF5: Replace Process Fragment by Reference

RF8: Remove Redundancies

RF9: Generalize Variant Change

RF11: Pull up Instance Change

174

175


(c) 2010-2011 Barbara Weber, Manfred Reichert

PMS3: Redundant Process Fragment RF5: Replace Process Fragment by

Reference


PMS1: : Non Intension Revealing Naming of Activity

176


PMS4: Large Process Model

177

Process Model After Refactoring

178

Instance I1

A

D

B

x x E C

Instance I1

A

D

B

x x E C

Schema S‘:

A

D

B

x x C

Traditional Process Lifecycle Support

Cre

ate

Inst

ance

s

Process Execution


Process participant


Integrated Lifecycle Support for Adaptive and Dynamic Processes (1)

Schema S:

A

D

B

x x E C

Instance I1

A

D

B

x x E C

Execution Log

Process Monitoring

179

179

Instance I1

A

D

B

x x E C

Instance I1

A

D

B

x x E C

Schema S‘:

A

D

B

x x C

Lifecycle Support in adaptive PAISs

Cre

ate

Inst

ance

s

Process Execution


Process Monitoring

Change Log

Instance-specific Change

Exception: Delete (I1, E)

Process participant


Cha

nge

Prop

agat

ion

Schema S:

A

D

B

x x E C

Instance I1

A

D

B

x x E C

Execution Log

180


180

Instance I1

A

D

B

x x E C

Instance I1

A

D

B

x x E C

Schema S‘:

A

D

B

x x C

Revised lifecycle for dynamic processes – The ProCycle Approach

Cre

ate

Inst

ance

s

Process Execution


Process Monitoring

Change Log

Instance-specific Change

Exception: Delete (I1, E)

Process participant


Cha

nge

Prop

agat

ion

Memorization and Change Reuse

Case Base

Derive Process Type Change

Schema S:

A

D

B

x x E C

Instance I1

A

D

B

x x E C

Execution Log

Migrate Case Base


181 [WRW+09]

References

• [RRD04a] Stefanie Rinderle, Manfred Reichert, Peter Dadam: Correctness criteria for dynamic changes in workflow systems - a survey. Data Knowl. Eng. 50(1): 9-34 (2004)

• [WeRe08] B. Weber and M. Reichert: Refactoring Process Models in Large Process Repositories In Proc. CAiSE'08 (2008), pp. 124-139

• [WRR+11] B. Weber and M. Reichert and H. Reijers and J. Mendling: Refactoring Large Process Model Repositories Computers and Industry 62(2011) 5, pp. 467-486.

• [WRW+09] Weber B., Reichert M., Wild W. and Rinderle-Ma S.: Providing Integrated Life Cycle Support in Process-Aware Information Systems. In: International Journal of Cooperative Information Systems 18 (2009) 1, pp. 115-165.

182


Business Processes and Workflows Loosely Specified Processes

183

Process Spectrum

Process Spectrum From fully predictable and highly repetitive to Fully unpredictable and non repetitive

184

Processes on the right side of the spectrum are mostly knowledge-intensive

Unpredictability Course of action depends on situation-specific parameters

Non-repeatability Two process instances hardly look the same

Emergence Future course of action depends on knowledge gained

through activity execution

Knowledge-intensive Processes

185

Loosely specified Processes

To deal with unpredictability, non repeatability and emergence loosely specified processes keep (parts) of the process unspecified during build-time

Loosely specified processes are characterized by decision deferral Decision on how the process exactly looks like are deferred to the

run-time

186

Taxonomy of Decision Deferral

187

Decision Deferral Patterns

188

Late Selection Pattern

189

Late Selection – The Worklets Approach

190 [AHE+06]

Late Selection – Static Process-based Composition

191 [CPE+08, AVM+04, CaSh01, Kli00]

Late Modeling

192

Late Modeling – Pockets of Flexibility

193 [SSO01, SSO05]

Late Modeling – Interleaved Routing

194 [RHA+06]

Late Modeling – Dynamic Process-based Composition

195 [SuWe03, ZNB+08]

Ad-hoc Composition - Declare

196 [AaPe06, PSS+07]

Iterative Refinement - Alaska

197 [WZP+09]

Iterative Refinement – Hierarchical Task Networks

198 [ELM+01]

References

[AaPe06] van der Aalst, W., Pesic, M.: DecSerFlow: Towards a Truly Declarative Service Flow Language. Tech. Rep., BPMcenter.org (2006) [AHE+06] Adams, M., ter Hofstede, A., Edmond, D., van der Aalst, W.: A Service-Oriented Implementation of Dynamic Flexibility in Workflows. In: Proc. Coopis’06 (2006) [AVM+04] R. Aggarwal, Kunal Vernal, John Miller and William Milnor : Constraint-driven Web Service Composition in METEOR-S: In Proc. SCC‘04, pp. 23-30. [CaSa01] Fabio Casati, Ming-Chien Shan: Dynamic and adaptive composition of e-services. Inf. Syst. 26(3): 143-163 (2001) [CPE+08] Gerardo Canfora, Massimiliano Di Penta, Raffaele Esposito, Maria Luisa Villani: A framework for QoS-aware binding and re-binding of composite web services. Journal of Systems and Software 81(10): 1754-1769 (2008) van Elst; Andreas Lauer; Heiko Maus; Sven Schwarz; Michael Sintek, A.A.A.B.L.: Frodo: A framework for distributed organizational memories. milestone 1: Requirements analysis and system architecture. Dfki document (2001). URL http://www.dfki.unikl.de/dfkidok/publications/D/01/01/abstract.html [Kli00] Justus Klingemann: Controlled Flexibility in Workflow Management. CAiSE 2000: 126-141

199

http://www.dfki.unikl.de/dfkidok/publications/D/01/01/abstract.html

References

[PSS+07] Pesic, M., Schonenberg, M., Sidorova, N., van der Aalst, W.: Constraint-Based Workflow Models: Change Made Easy. In: Proc. CoopIS’07, pp. 77–94 (2007) [RHA+06] N. Russell, A.H.M. ter Hofstede, W.M.P. van der Aalst, and N. Mulyar. Workflow Control-Flow Patterns: A Revised View. BPM Center Report BPM-06-22 , BPMcenter.org, 2006. [SSO01] Sadiq, S., Sadiq, W., Orlowska, M.: Pockets of flexibility in workflow specifications. In: Proc. ER’01, pp. 513–526 (2001) [SSO05] Sadiq, S., Sadiq, W., Orlowska, M.: A Framework for Constraint Specification and Validation in Flexible Workflows. Information Systems 30(5), 349 – 378 (2005) [SuWe03] Hilmar Schuschel, Mathias Weske: Integrated Workflow Planning and Coordination. DEXA 2003: 771-781 [ZNB+08] Liangzhao Zeng, Anne H. H. Ngu, Boualem Benatallah, Rodion M. Podorozhny, Hui Lei: Dynamic composition and optimization of Web services. Distributed and Parallel Databases 24(1-3): 45-72 (2008)

200


Business Processes and Workflows Declarative Processes

201

Declarative Processes

Declarative approaches allow for Late Composition of business processes and are thus highly flexible

Advantages commonly attributed to declarative processes Support for partial workflows (Wainer et al. 2004 [WBB04])

Allow users to defer decisions to run-time (Weber et al. 2008 [WeRR08])

Absence of over-specification (Pesic et al. 2007 [PSSA07])

More maneuvering room for end users (Pesic et al. 2007 [PSSA07]),

202

202

Declarative Processes

Instead of describing exactly how a business process should be executed, declarative processes describe the activities to be executed and constraints prohibiting undesired behavior (e.g., selection

constraints, ordering constraints, resource constraints)

203

203 [PSSA07]

Modeling Declarative Processes

B A B C

D E F

Declarative Process Model S

A B NOT CO-EXISTENCE A and B are mutually exclusive

A RESPONSE If A is executed, B needs to executed afterwards

Execution trace producible on S: σ1 = < A, A, D, E, A> σ2 = < B, C, F, E, B> σ3 = < B, E, F> Execution trace not producible on S: σ4 = < A, C, E, A> σ5 = < B, D, C> σ6 = < A, D, B, F, E>

A B

C F

C1

C2

Activities A

Constraints C

Legend

C2 C2 C1

204

Modeling Declarative Processes

5 Major Categories Selection Constraints Relation Constraints Branching Constraints Negation Constraints Choice Constraints

205

Activity a must occur at least n times in every trace

existence(a, n) a

n..*

Activity a must occur at most n times in every trace

at_most(a, n) a

0..n

Activity a must occur exactly n times in every trace

exactly(a, n) a n

Example: existence(A,1) Supported traces, e.g.: <A>,<A,A,A> Unsupported trace, e.g.: <>

Example: at_most(A,3) Supported traces, e.g.: <>,<A>,<A,A>,<A,A,A> Unsupported trace, e.g.: <A,A,A,A>

Example: exactly(A,2) Supported trace, e.g.: <A,A> Unsupported traces, e.g.,: <A>,<A,A,A>

Activity a must be the first executed activity in every trace init(a)

a init

Example: init(A) Supported trace, e.g.: <A,C,D,B> Unsupported trace, e.g.: <D,C,B,A> SE

LEC

TIO

N C

ON

STR

AIN

TS

b a

b a

If a is executed, b needs to be executed afterwards (but not necessarily directly after)

response(a, b) Example: response(A,B) Supported traces, e.g.: <A,B>,<A,A,A,B>, Unsupported trace, e.g.: <A>

Activity b needs to be preceded by activity a

precedence(a, b) Example: precedence(A,B) Supported traces, e.g.: <A,B>,<A,B,B,B>,<A> Unsupported trace, e.g.: 

If a is executed, b needs to be executed afterwards (but not necessarily directly after); activity b needs to be preceded by activity a

succession(a, b) Example: succession(A,B) Supported traces, e.g.: <A,B>,<A,A,A,B>,<A,B,B,B> Unsupported traces, e.g.: <A>,

b a If activity a is executed, activity b needs to be executed either before or after a

respondedExistence(a, b) Example: respondedExistence(A,B) Supported traces, e.g.: <A,B>,<B,A>,<A,B,A>, Unsupported trace, e.g.: <A>

b a

RELATION CONSTRAINTS

b1 a

If a is executed, at least one activity from set {b1,..,bn} has to be executed afterwards (but not necessarily directly after)

response(a, {b1,..,bn}) Example: response(D,{E,F}) Supported traces, e.g.: <D,E>,<D,F>,<F>,<D,E,F> Unsupported trace, e.g.: <D>

bn

If one activity from set {a1,..,am} is executed, at least one activity from set {b1,..,bn} has to executed afterwards. To execute an activity from set {b1,..,bn}, at least one activity from set {a1,..,nm} has to be executed before. succession ({a1,..,am},

{b1,..,bn})

Example: succession({D},{E,F}) Supported traces, e.g.: <D,F>,<E,F>,<D,E,F> Unsupported traces, e.g.: <D>,<E>,<F>

a1

am

…

… b1

bn

…

BRANCHING CONSTRAINTS

Activity a and b cannot co-occur in any trace

neg_coexistence(a, b)

b a

a b

Example: neg_coexistence(A,B) Supported traces, e.g.: <A>, Unsupported traces, e.g.: <A,B>,<B,A>

If activity a is executed, activity b must not be executed afterwards anymore

neg_response(a, b) Example: neg_response(A,B) Supported traces, e.g.: <A>,,<B,A> Unsupported trace, e.g.: <A,B>

NEGATION CONSTRAINTS

At least m distinct activities out of n activities from set {a1,…,an}, m ≤ n must be executed

a1

a2

an

…

m of n

Example: choice(2-of-3, {A,B,C}) Supported traces, e.g.: <A,B>,<B,C>,<A,C>,<A,B,C> Unsupported traces, e.g.: <A>,<B,B>

choice(m-of-n, {a1,..,an})

Exactly m distinct activities out of n activities from set {a1,…,an}, m ≤ n must be executed

a1

a2

an

…

m of n

Example: choice(2-of-3, {A,B,C}) Supported traces, e.g.: <A,B>,<B,C>,<A,C> Unsupported traces, e.g.: <A>,<B,B>,<A,B,C>

exact_choice(m-of-n, {a1,..,an})

CHOICE CONSTRAINTS

Enabled Activities

B A B C

D E F

Declarative Process Model S A B NOT CO-EXISTENCE

A and B are mutually exclusive


A B

C F

C1

C2

Activities A

Constraints C Partial Trace Set of Enabled Activities

< > {A, B, C, D, E, F}

<A> {A, C, D, E, F} B is not included since partial trace <A, B> violates constraint C1

<A, C> {A, C, D, E, F} B is not included since partial trace <A, B> violates constraint C1

211

A B C D E F

Execution Termination

Tim

elin

e

Process Instantiation

Process Termination

A B C

D E F


A B

C F

C1

C2

Activities A

Constraints C

Activities A, B, C, D, E, F and G are enabled

Instance I can terminate, i.e., no

termination constraints violated

212

A B C D E F


Tim

elin

e


Process Termination

A B C

D E F


A B

C F

C1

C2

Activities A

Constraints C

A A started A completed

As A is executed B cannot be executed

any longer

No termination constraint violations, i.e., I can terminate

213

A B C D E F


Tim

elin

e


Process Termination

A B C

D E F


A B

C F

C1

C2

Activities A

Constraints C


C started C completed C

Constraint violations, i.e., I cannot terminate

214

A B C D E F


Tim

elin

e


Process Termination

A B C

D E F


A B

C F

C1

C2

Activities A

Constraints C



E started E completed E

Constraint violations, i.e., I cannot terminate

215

A B C D E F


Tim

elin

e


Process Termination

A B C

D E F


A B

C F

C1

C2

Activities A

Constraints C




F started F completed F

No constraint violations, i.e., I can

terminate

216

Overriding of Constraints

A B C D E F


Tim

elin

e


Process Termination

A B C

D E F


A B

C F

C1

C2

Activities A

Constraints C




!

Warning “F not executed after C”

!

Soft constraints can be ignored during

process execution

Users terminating process instance I are

informed about constraint violation

217

218

1


B



Execution trace Instance I1: σ1 = < A, C>

S [ΔS>S ‘ with ΔS = <addConstraint(exactly_1(A)), addConstraint(respondedExistence(D,E))>

EXACTLY_1 A must be executed exactly once A

σ1 is producible on S‘

Migrate

Execution Trace Instance I2: σ2 = < A, C, A, F>

Execution Trace Instance I3: σ3 = < A, D, F>

σ2 not producible on S‘


Migrate

Don‘t Migrate

A B

C D

E F

A B

C F

C1

C2

Activities A Constraints C

Declarative Process Model S‘

A B

C D

F

A B

C F

C1

C2


E

D

1 A C3

E C4

Legend

B A RESPONDED EXISTENCE If A is executed, B needs to executed either before or after A

Ad-hoc changes and Schema Evolution

219

1


B



Execution trace Instance I1: σ1 = < A, C>

S [ΔS>S ‘ with ΔS = <addConstraint(exactly_1(A)), addConstraint(respondedExistence(D,E))>

EXACTLY_1 A must be executed exactly once A


Migrate

Execution Trace Instance I2: σ2 = < A, C, A, F>

Execution Trace Instance I3: σ3 = < A, D, F>

σ2 not producible on S‘


Migrate

Don‘t Migrate

A B

C D

E F

A B

C F

C1

C2


Declarative Process Model S‘

A B

C D

F

A B

C F

C1

C2


E

D

1 A C3

E C4

Legend

B A RESPONDED EXISTENCE If A is executed, B needs to executed either before or after A

Ad-hoc changes and Schema Evolution

Changed regulations require a

modification.

Modification may refer to a single instance (ad-hoc

change) or all process instances (schema

evolution)

Changes are only applied to instances which are compliant with change

The Declare System

van der Aalst, Pesic and Schonenberg 2009 [APS09]

Composing Declarative Processes with Declare

Executing Declarative Processes with Declare

220

220

Late Composition in Alaska Simulator (1)

A B

C

D

E

F

Declarative Process Model

Calendar

Process Instance I1

New Process Instance I1 is created

A C

D E F

Available Actions B

A

User can partially model the process

instance

Current Problems

221

221


A B

C

D

E

F


Calendar

Process Instance I1

A C

D E F

Available Actions B

A

Process Instance is incrementally

validated

C

Current Problems

F must be executed

222

222

A B

C

D

E

F


Calendar

Process Instance I1

A C

D E F

Available Actions B

C

Current Problems

F

User resolves problems A

223


223

A B

C

D

E

F


Calendar

Process Instance I1

A C

D E F

Available Actions B

A

C

Current Problems

F

User starts execution of Instance I1

224


224

A B

C

D

E

F


Calendar

Process Instance I1

A C

D

E F

Available Actions B

A

C

Current Problems

F

Instance I1 can be altered at all times

E

D

225


225

A B

C

D

E

F


Calendar

Process Instance I1

A C

D

E F

Available Actions B

A

C

Current Problems

F

Execution of Instance I1 is proceeded

E

D

226


226

The Alaska Simulator

Is an interactive planning tool providing support for late composition

Uses journey as a metaphor for business processes

Actions, accommodations and routes correspond to

activities

Selection, ordering and resource constraints are relevant in both settings

Information on benefits (i.e., business value), cost and duration are essential for

decision making

Effectively handling uncertainty is

fundamental in both domains

http:\\alaskasimulator.org

Weber, Zugal, Pinggera and Wild 2009 [WZP+09]

Both the planning of a journey and the

execution of a business process is oriented

towards a goal

227

227

Declarative workflows provide a lot of flexibility to the end user, but on the other hand require adequate user support

Schonenberg, Weber, Aalst and van Dongen 2008 [SWD+08]

Process-aware Information System (PAIS)

Process Engine

Recommendation Service

Partial case, enabled activities

Recommendation result (ordered enabled activities)

Event Log logs

uses

Optimization Goal

Plugin

Plugin

Plugin

Assistance and Support for Declarative Workflows 228

228

References

[AaPe06] W.M.P. van der Aalst and M. Pesic : DecSerFlow: Towards a Truly Declarative Service Flow Language. In WS-FM 2006, 2006, pp 1-23.

[APS09] Wil M. P. van der Aalst, Maja Pesic, Helen Schonenberg: Declarative workflows: Balancing between flexibility and support. Computer Science - R&D 23(2): 99-113 (2009)

[PSS+07] Pesic, M., Schonenberg, M., Sidorova, N., van der Aalst, W.: Constraint-Based Workflow Models: Change Made Easy. In: Proc. CoopIS’07, pp. 77–94 (2007)

[SWD+08] Helen Schonenberg, Barbara Weber, Boudewijn F. van Dongen, Wil M. P. van der Aalst: Supporting Flexible Processes through Recommendations Based on History. BPM 2008: 51-66

[WRR08] Barbara Weber, Manfred Reichert, Stefanie Rinderle-Ma: Change patterns and change support features - Enhancing flexibility in process-aware information systems. Data Knowl. Eng. 66(3): 438-466 (2008)

229

References

[WBB04] Jacques Wainer, Fábio de Lima Bezerra, Paulo Barthelmess: Tucupi: a flexible workflow system based on overridable constraints. SAC 2004: 498-502

[WRZ+09] Barbara Weber, Hajo A. Reijers, Stefan Zugal, Werner Wild: The Declarative Approach to Business Process Execution: An Empirical Test. CAiSE 2009: 470-485

230

--- Coming soon ---

Enabling Flexibility in Process-aware

Information Systems Challenges, Methods, Technologies

Springer 2012

by

Manfred Reichert and Barbara Weber

enabling flexibility in process-aware information...

Documents