Business Process Modelling -9.2/2013 -

1. Business Process Modelling-9.2/2013 - Marcello La Rosa Queensland University of Technology Brisbane, 19 September 2013

2. Quick Repeat from Week 8 What is a process event? What is the difference between a message and a timer event? How to interrupt an activity?

3. Event-based decision • With the XOR-split gateway, a branch is chosen based on conditions that evaluate over available data  The choice can be made immediately after the token arrives from the incoming flow • Sometimes, the choice must be delayed until an event happens  The choice is based on a race among events • This is why BPMN distinguishes data-driven and event-driven XOR-splits event-driven XOR split data-driven XOR-split

4. Example: event-based decision Restaurants submit orders to suppliers to replenish their food stocks every Thursday. The process for completing an order starts when a restaurant receives either a “PO Response” or an error message. However it may also happen that no response is received at all. If no response is received by Friday afternoon or if an error message is received, the purchasing officer should be notified. Otherwise, the PO Response is processed normally.

5. A possible solution

6. Quiz: find the bugs • not Intermediate Timer Event

7. Solution: event-based decision

8. Remember the quiz from slide 23 of Week 8?

9. Interlude: multiple start events The first such event that occurs, will trigger an instance of the process.

10. What is this process doing?

11. BPMN Modelling- Exception Handling -

12. Simplest form of exception: Terminate event Exceptions are events that deviate a process from its “normal” course The simplest form of exception is to notify that there is an exception (negative outcome) This can be done via the Terminate end event: it forces the whole process to abort (“wipes off” all tokens left behind, if any)

13. Example: terminate event Signal the negative outcome…

14. Example 2: terminate event Abort the process by removing all tokens…

15. Example: our PO handling process (see Week 8) A Purchase Order (PO) handling process starts when a PO is received. The PO is first registered. If the current date is not a working day, the process waits until the following working day before proceeding. Otherwise, an availability check is performed and a “PO response” is sent back to the customer. Anytime after the PO has been registered, the customer may send a “PO change request”. When such a PO change request is received, any processing related to the PO must be stopped. The PO change request is then registered. Thereafter, the process proceeds as it would do after a normal PO is registered. Further, if the customer sends a “PO cancelation request” after the PO registration, the PO processing must be stopped and the change request needs to be handled.

16. Solution

17. Exception handling • Handling exceptions often involves stopping a sub-process and performing a special activity • Types of exceptions for an activity (task/sub-process) in BPMN: Timeout: an activity takes too long and must be interrupted. Handled with the Timer event External: something goes wrong outside the process, and the execution of the current activity must be interrupted. Handled with the Message event Internal: something goes wrong inside an activity, whose execution must thus be interrupted. Handled with the Error event All these events stop the enclosing activity and start an exception handling routine.

18. Internal exceptions: error event Must be attached to the activity’s boundary

19. Example: error event Consider our “PO Handling process” example with the following extension: if an item is not available, any processing related to the PO must be stopped. Thereafter, the client needs to be notified that the PO cannot be further processed.

20. Solution Must catch an error event thrown from within the same activity

21. Compensation Handling May be used as part of an exception handling procedure Rollback of completed process activities E.g.: Bookings for holidays have successfully been completed. However, it turns out that the given credit card details were incomplete. A booking rescission is necessary. Triggered by throwing Compensate Event Compensation Handler (triggered bya catching Compensate event) performs the rollback

22. Compensate event Must be attached to the activity’s boundary

23. Example: compensation event Let’s extend out PO Handling process. After a PO has been registered, checked, and a response has been sent back, a payment sub-process and a fulfilment sub-process are started in parallel. During these two sub-processes, a PO cancellation may be received from the customer. In this case, both sub-processes are stopped, and a compensation routine is performed for each of them (e.g. reimbursement and/or goods return may need to occur).

24. Possible solution: compensation event Only one compensate activity must be linked from a catching compensate event, via a directed association

25. Recap: Terminate, Error and Compensate events

26. Non-interrupting boundary events Sometimes we may need to trigger a task/sub-process in parallel to the normal flow, i.e. without interrupting the normal flow. This can be achieved by using non-interrupting boundary events: • Double dashed border • Attached to the boundary of a task/sub-process

27. Example: non-interrupting boundary events Again, our PO handling process… A Purchase Order (PO) handling process starts when a PO is received. The PO is first registered. If the current date is not a working day, the process waits until the following working day before proceeding. Otherwise, an availability check is performed and a “PO response” is sent back to the customer. Anytime after the PO has been registered, the customer may send a “PO change request”. When such a PO change request is received, any processing related to the PO must be stopped. The PO change request is then registered. Thereafter, the process proceeds as it would do after a normal PO is registered. Further, if the customer sends a “PO cancelation request” after the PO registration, the PO processing must be stopped and the chance request needs to be handled. The customer may send a “Customer address change request” after the PO registration. When such a request is received, it is just registered, without further action.

28. Solution: non-interrupting boundary events

29. An alternative: Event Sub-Process To handle events that may not refer to a particular task/sub-process within a process. • Placed into a process or sub-process • Depicted within a dotted rectangle with rounded corners • Is activated when its start event is triggered • It may or may not interrupt the parent process or sub-process, depending on the type of its start event: • Non-Interrupting: • Interrupting:

30. Example: Event Sub-Process when the event sub-process is inside a sub-process, it can only be receptive of those events that occur during the execution of the enclosing sub-process

31. Recap: Events

32. References • Required • Sections 4.4.3 and 4.5 of Chapter 4 of textbook “Fundamentals of BPM” • Recommended • OMG (2011): BPMN 2.0 Specification • BPM Offensive (2011): BPMN 2.0 Poster • OGM (2010): BPMN 2.0 By Example • Web References • OMG BPM Initiative • BPMN Community • Books on BPMN • Silver B. (2011): “BPMN Method & Style” 2nd Edition, Cody-Cassidy

33. A/Prof. Marcello La RosaIS School Academic Director(Corporate Programs and Partnerships)BPM Discipline, IS School Science & Engineering FacultyQueensland University of Technology126 Margaret StreetBrisbane QLD 4000Australia p +61 (0)7 3138-9482e m.larosa@qut.edu.auw www.marcellolarosa.com