Business Processes & Petri Nets IPA basic course on formal methods

1. Business Processes & Petri NetsIPA basic course on formal methods Prof.dr.ir. Wil van der Aalst Eindhoven University of Technology, Faculty of Technology Management, Department of Information and Technology, P.O.Box 513, NL-5600 MB, Eindhoven, The Netherlands.

2. Outline • 10.00 - 11.00 Lecture 1: Petri nets • 11.00 - 11.15 Break • 11.15 - 12.00 Exercises 1: Hands-on with CPN Tools • 12.00 - 12.15 Discussion of exercises 1 / demo • 12.15 - 13.15 Lunch • 13.15 - 14.15 Lecture 2: Workflow modeling and analysis • 14.15 - 14.30 Break • 14.30 - 15.15 Exercises 2: Hands-on with Protos and Woflan • 15.15 - 15.30 Discussion of excercises 2 / demo • 15.30 - 15.45 Break • 15.45 - 16.15 Wrap-up session: Process Mining

3. Lecture 1: Petri netsPetri-nets by example

4. Role of process models in information systems

5. Limitations of classical Petri nets • Inability to test for zero tokens in a place. • Models tend to become large. • Models cannot reflect temporal aspects • No support for structuring large models, cf. top-down and bottom-up design (As a result most things are decidable )

6. Inability to test for zero tokens in a place ? t p “Tricks” only work if p is bounded

7. High-level Petri nets • To tackle the problems identified. • Petri nets extended with: • Color (i.e., data) • Time • Hierarchy • For the time being be do not choose a concrete language but focus on the main concepts. • We focus on a concrete language: CPN. • We show use CPN Tools.

8. DEMO

9. Exercises 1: Hands-on with CPN Tools Model and simulate the following cases using CPN Tools ...

10. Coffee and tea example (1) • We need to produce 100 cups of tea and 100 cups of coffee. • There are two persons able to manufacture these drinks: Adam and Eve. • Assume "random allocation". • Production times:

11. Coffee and tea example (2) • Simulate the model a couple of times and record the makespan. • Evaluate two control strategies: • Eve just makes tea and Adam just makes coffee. • Adam makes coffee and Eve can make both. • Eve makes tea and Adam can make both. • Why is it diffcult to model priorities/preferences?

12. Coffee and tea example (3) • Assume a continuous flow of tea and coffee drinker, i.e., every 5 minutes there is request for tea and every 10 minutes there is a request of coffee. • There are two persons able to manufacture these drinks (Adam and Eve) and the production times are as before. • Process the requests in FIFO (first-in-first-out) order.

13. Coffee and tea example (4) • Assume a continuous flow of tea and coffee drinker, but now evaluate the following alternatives: • LIFO (last-in-first-out) order • SPT (tea before coffee) order • FIFO with Eve preferably working on tea and Adam on coffee. • Test also your own strategy.

14. Cheat sheet

15. Lecture 2: Workflow Modeling and Analysis

16. Reference model of the Workflow Management Coalition What? When? Who?

21. Focus on "classical" workflow management systems, but ... Four types of "workflow-like" systems: • Information systems with hard-coded workflows (process& organization specific). • Custom-made information systems with generic workflow support (organization specific). • Generic softwarewith embedded workflow functionality (e.g., the workflow components of ERP, CRM, PDM, etc. systems). • Generic softwarefocusing onworkflow functionality (e.g., Staffware, MQSeries Workflow, FLOWer, COSA, Oracle BPEL, Filenet, etc.).

22. Workflow perspectives • Process perspective (tasks and the routing of cases) • Resource perspective (workers, roles, 4-eyes principle, etc.) • Case/data perspective (process instances and their attributes) • Operation/application perspective (forms, application integration, etc.) • ...

23. Process perspective: Protos (extended Petri nets)

24. Process perspective: Staffware

25. Process perspective: COSA (Petri nets)

26. Process perspective: Baan DEM

27. Process perspective: Event driven process chains (ARIS/SAP)

28. <sequence name="main"> <flow name="Flow_1"> <links> <link name="receive-to-assess"/> <link name="receive-to-approval"/> <link name="approval-to-reply"/> <link name="assess-to-setMessage"/> <link name="setMessage-to-reply"/> <link name="assess-to-approval"/> </links> <sequence name="sequenceReceive"> <source linkName="receive-to-assess" transitionCondition="bpws:getVariableData('inputVariable','payload','/client:LoanApprovalProcessRequest/client:amount') &lt; 10000"/> <source linkName="receive-to-approval" transitionCondition="bpws:getVariableData('inputVariable','payload','/client:LoanApprovalProcessRequest/client:amount') &gt;= 10000"/> <receive name="receiveInput" partnerLink="client" portType="client:LoanApproval" operation="initiate" variable="inputVariable" createInstance="yes"/> </sequence> <sequence name="sequenceAssess"> <target linkName="receive-to-assess"/> <source linkName="assess-to-setMessage" transitionCondition="bpws:getVariableData('risk') = 'low'"/> <source linkName="assess-to-approval" transitionCondition="bpws:getVariableData('risk') != 'low'"/> <assign name="initiateAssessor"> <copy> <from variable="inputVariable" part="payload" query="/client:LoanApprovalProcessRequest/client:firstName"/> <to variable="invokeAssessor_initiate_InputVariable" part="payload" query="/ns1:AssessorProcessRequest/ns1:firstName"/> </copy> <copy> <from variable="inputVariable" part="payload" query="/client:LoanApprovalProcessRequest/client:name"/> <to variable="invokeAssessor_initiate_InputVariable" part="payload" query="/ns1:AssessorProcessRequest/ns1:name"/> </copy> <copy> <from variable="inputVariable" part="payload" query="/client:LoanApprovalProcessRequest/client:amount"/> <to variable="invokeAssessor_initiate_InputVariable" part="payload" query="/ns1:AssessorProcessRequest/ns1:amount"/> </copy> </assign> <invoke name="invokeAssessor" partnerLink="Assessor" portType="ns1:Assessor" operation="initiate" inputVariable="invokeAssessor_initiate_InputVariable"/> <receive name="receiveAssessor" partnerLink="Assessor" portType="ns1:AssessorCallback" operation="onResult" variable="receiveAssessor_onResult_InputVariable" createInstance="no"/> <assign name="completeAssessor"> <copy> <from variable="receiveAssessor_onResult_InputVariable" part="payload" query="/ns1:AssessorProcessResponse/ns1:level"/> <to variable="risk"/> </copy> </assign> </sequence> <sequence name="sequenceNoApproval"> <target linkName="assess-to-setMessage"/> <source linkName="setMessage-to-reply"/> <assign name="setAccepted"> <copy> <from expression="'Accepted'"/> <to variable="outputVariable" part="payload" query="/client:LoanApprovalProcessResponse/client:result"/> </copy> </assign> </sequence> (Oracle) BPEL

29. Design-time (a-priori) and run-time (a-posteriori) questions Run-time Design-time ProM Woflan -verification- validation- performance analysis - process mining

30. A-priori analysis: Woflan

31. A process in Staffware (a similar process could have been made using BPMN, etc.)

33. Corresponding WF-net Not sound!

34. Syntactic sugaring • Note silent (tau) steps. • Branching bisimulation is used as an equivalence relation to distinguish internal/external choices.

35. i o Soundness • A WF-net is sound if and only if • marking o is reachable from every reachable marking (initial marking is i), • marking o is the only reachable marking marking place o, and • there are no dead transitions.

36. Reachability analysis

37. Place invariants can be used to check detect errors • There should be a positive place invariant assigning positive weights to all places and identical weights to begin and end. • 1.begin + 1.end + ..... = constant begin end

38. Transition invariants can be used to detect errors short-circuited net • There should be a positive transition invariant assigning positive weights to all transitions. begin end

39. Languages/products we can verify: • Event-driven process chains (SAP, ARIS, ARIS PPM) • BPEL (Websphere and Oracle BPEL) • Staffware • COSA • Protos • YAWL • PNML (Yasper, ProM, XRL, ...) • ...

40. Exercises 2: Hands-on with Protos and Woflan Model the following cases using Protos, export models to Woflan and verify (make some mistakes on purpose). You can also start by rebuilding the example.

41. Insurance company • Insurance company X processes claims which result from traffic accidents with cars where customers of X are involved in. Therefore, it uses the following procedure for the processing of the insurance claims. • Every claim, reported by a customer, is registered by an employee of department CD (CD = Car Damages). After the registration of the claim, the insurance claim is classified by a claim handler of rank A or B within CD. There are two categories: simple and complex claims. • For simple claims two tasks need to be executed: check insurance and phone garage. These tasks are independent of each other.

42. Insurance company (2) • The complex claims require three tasks to be executed: check insurance, check damage history and phone garage. These tasks need to be executed sequentially in the order specified. • Both for the simple and complex claims, the tasks are done by employees of department CD. After executing the two respectively three tasks a decision is made. This decision is made by a claim handler of rank A and has two possible outcomes: OK (positive) or NOK (negative). • If the decision is positive, then insurance company X will pay. An employee of the finance department handles the payment. In any event, the insurance company sends a letter to the customer who sent the claim. An employee of the department CD writes this letter.

43. Complaints handling • Each year travel agency Y has to process a lot of complaints (about 10.000). There is a special department for the processing of complaints (department C). There is also an internal department called logistics (department L) which takes care of the registration of incoming complaints and the archiving of processed complaints. The following procedure is used to handle these complaints.

44. Complaints handling (2) • An employee of department L first registers every incoming complaint. After registration a form is sent to the customer with questions about the nature of the complaint. This is done by an employee of department C. There are two possibilities: the customer returns the form within two weeks or not. If the form is returned, it is processed automatically resulting in a report which can be used for the actual processing of the complaint. If the form is not returned on time, a time-out occurs resulting in an empty report. Note that this does not necessarily mean that the complaint is discarded. After registration, i.e., in parallel with the form handling, the preparation for the actual processing is started.

45. Complaints handling (3) • First, the complaint is evaluated by a complaint manager of department C. Evaluation shows that either further processing is needed or not. Note that this decision does not depend on the form handling. If no further processing is required and the form is handled, the complaint is archived. If further processing is required, an employee of the complaints department executes the task ‘process complaint’ (this is the actual processing where certain actions are proposed if needed). For the actual processing of the complaint, the report resulting from the form handling is used. Note that the report can be empty. The result of task ´process complaint´ is checked by a complaint manager. If the result is not OK, task ´process complaint´ is executed again. This is repeated until the result is acceptable. If the result is accepted, an employee of the department C executes the proposed actions. After this the processed complaint is archived by an employee of department L.

46. Travel agency • Consider a fragment of the process of booking trips involving six steps: register, (booking of) flight, (booking of) hotel, (booking of) car, pay, and cancel. • The process starts with task register andends with pay or cancel. • The tasks flight, hotel and car may succeed or fail. Let us consider a number of variants…

47. Travel agency: Variant 1 • Every trip involves a flight, hotel and car and these are booked in parallel. If all three succeed, the payment follows. Otherwise task cancel is executed. Cancel is delayed until all three bookings succeed/fail and does not withdraw work.

48. Travel agency: Variant 2 • Every trip involves a flight, hotel and car and these are booked in parallel. If all three succeed, the payment follows. Otherwise task cancel is executed. Task cancel can be executed the moment the first task fails and withdraws work-items waiting for remaining booking tasks.

49. Travel agency: Variant 3 • Every trip may involve a flight, hotel and/or car and these are booked in parallel. A trip should involve at least a flight, hotel or car but may be any combination of the three bookings, e.g., a flight and car but not a hotel. If all bookings succeed, the payment follows. Otherwise task cancel is executed. Task cancel can be executed the moment the first task fails and withdraws work-items waiting for remaining booking tasks.

50. Travel agency: Variant 4 • Every trip may involve a flight, hotel and/or car and these are booked in parallel. A trip should involve at least a flight, hotel or car but may be any combination of the three bookings, e.g., a flight and car but not a hotel. If all bookings succeed, the payment follows. Otherwise task cancel is executed. Task cancel can be executed the moment the first task fails and withdraws work items waiting for remaining booking tasks. All bookings that have completed successfully need to be compensated.