Semantic business process for improved exception handling Extend

Semantic business process for improved exception handling Extend BPMN, with semantic data, to enforce exception handling - for robust processes 18 -Mar-18 1

Semantic business process for improved exception handling A thesis submitted as a requirement for a Master's degree in the Faculty of Natural Sciences By: Ziv Ben-Eliahu Supervisor: Michael Elhadad Department of Computer Science Ben-Gurion University of the Negev, Israel 18 -Mar-18 2

Things to come n Introduction n n Exceptions in business processes Our contribution: elicit potential exceptions at modeling time ------------------n Previous work n n Our approach n n Use semantic and structural information to infer potential exceptions modeling time. Empirical Evaluation n n Formal methods for verification, runtime analysis. Dataset, usability experiment Conclusions 18 -Mar-18 3

Introduction Process execution may fail n Identifying potential problems as early as possible is critical n n Engineering n Applications n Productions n Business n processes Define problems: any deviations from the normal flow 18 -Mar-18 4

Introduction n 2 aspects considered: n how to identify exceptions n how to handle exceptions n enforce handling applied to Business Process Models (and BPMN specifically) 18 -Mar-18 5

Introduction: BPMN 18 -Mar-18 6

To make a long story short Before 18 -Mar-18 7

To make a long story short n Business analysts seldom use Exception Flow n Empirical review of 302 BPDs – we found only 3% with exceptions. n To encourage them: n n n add intuitive semantic data infer less intuitive exception data verify handling 18 -Mar-18 8

To make a long story short After (our contribution) 18 -Mar-18 9

Our Contribution n n n Intervene during modeling, in an intuitive and non-intrusive manner Remind the business analyst he should pay attention to errors Do not deal with handling strategies (how to organize compensation) Do not want too many “false alarms” Do want to catch as many correct errors as possible Key issue we address: what knowledge on the activity and the process is helpful to raise such warnings 18 -Mar-18 10

To make a long story long n Background n Related work: handling, verify n IDE as motivation (intuitive) Early detection of exceptions: handling exceptions at modeling time. n Semantic activity classification to infer potential exceptions. n Empirical Evaluation n 18 -Mar-18 11

Background: Exceptions in BPM Handling exceptions at execution time n n n [Bonatti 04] chooses optimal web service – failure handled by automatically replacing service by another equivalent one. [Shang 07] collaborative exception handling platform proposes handling strategies (at failures) [Adams 07] records handling decisions, attempts to re-use, and reverse-engineer into model 18 -Mar-18 et al. 12

Verification of BPEL/ECA Verification of exception handling in execution languages n n n [Fu 04] WSAT: analyzes web services composition using modelbased formal methods. [Bry 06] realizing business processes with Event-Condition. Action rules (instead of BPEL) with datalog-like verification. [Casati 99] suggests ECA-Patterns to the design of exceptions 18 -Mar-18 et al. 13

Verification of BPMN Verification at modeling time n n [Dijkman 08] transform BPMN to Petri -Nets then uses Petri-net analysis for verification [Wong 07] propose a CSP-based semantics of BPMN to allow model analysis including exception handling et al. 18 -Mar-18 14

Exception handling in WF Handling exceptions at modeling time in other workflow language n n n [Russell 06] (a) graphical lang. for exception handling, (b) handling patterns per exception [Song 03] (a) exception specification in workflow definition, (b) an exception handling mechanism [Eder 95] specify whether special tasks are essential and whethere are compensation et al. 18 -Mar-18 15

Our approach n n n Identify exceptions at modeling time. Many focus on runtime. Current verification handles only explicit exception. We elicit implicit exceptions. Verification of exceptions requires extending BPMN specifications. An intuitive method for a business analyst should involve business semantics Except [Adams], we did not find evaluations of system usability 18 -Mar-18 16

A better way to handle exceptions… Exception handling at design time IDE is our motivation n Many programming languages require handlers at compilation time (Java, ADA…) 18 -Mar-18 17

Why BPMN n n BPMN is the standard de-facto Capture models of business activity in an explicit form Model description can be approved by all stakeholders (balancing expressivity and readability). Model description can serve as abstract specification of executable process. 18 -Mar-18 18

Why Prosero n Models in the repository are annotated with semantic metadata, for the matching procedure n Future version could: n Use the repository data to infer on local semantics n Use the local semantics for the 18 -Mar-18 matching procedure 19

Background - summary Ø It is important for BPDs to be as close to reality as possible; including exception handling. Ø “Exception” in broader terms. Ø We reviewed several methods to add semantic metadata to a BPD. But few methods are as intuitive as IDEs, and those do not support BPMN. 18 -Mar-18 20

Objectives: early detection 1) How do we prevent the business analyst from missing possible exceptions, but without interrupting his work on the happy path? 2) How can we help the business analyst decide which exception an Activity might throw? 18 -Mar-18 21

Solution 1) 2) Extend BPMN Activity n Errors n Handlers n Parameters Offer recommendation n <elements xsi: type="bpmn: Task" name="Don't Worry"> <event. Handler Trigger="Error" name="Is. Worried" /> <errors name="Timeout" /> </elements> o Classifications o Exceptions o Inference Relations ( ) o o We constructed generic lists 18 -Mar-18 o Perform action Action failed Complex action Timeout Send rejected Receive rejected Query failed Update rejected 22

Infer Potential Errors from Semantic Data When semantic parameters of construct are known, one can infer potential errors. 1. Activity is Send 2. Activity requires authentication 1. Authentication fails 2. Send fails 3. Send rejected 18 -Mar-18 23

Define Constructs Define construct as: - Activity - Semantic class - Exceptions Functional classes: n Internal-Activity n Send-Receive n Receive-Process. Reply 18 -Mar-18 24

Define Templates n Our semantic parameters can be associated with an abstract sub-process (Update, Notif…) 18 -Mar-18 25

Template Instantiation The abstract pattern, from the RMR, is instantiated into the CMR 18 -Mar-18 n 26

Hypothesis Use of semantically annotated constructs and patterns at modeling time will: n Detect early potential errors n Remain usable by analysts n Small time increase n High quality increase n More benefit for complex processes 18 -Mar-18 27

Methodology Collect dataset: 11 process models of various complexities. n Analyze error handling in dataset. n Re-model processes using implemented BPMN modeling tool (Prosero). n Measure usability parameters n Measure quality of resulting 18 -Mar-18 28 models. n

Evaluation Complexity Business Process Simple Deliver item, Return goods, Issue credit Medium Receive returned goods, Perform disposition, Administer return request Complex Update return, Approve return, HR Hiring, Software defect management, Software release product 18 -Mar-18 29

Results Complexity level Source REC% ACC% PRE% Time Simple origin. 16. 67 55. 6 33. 3 5: 36 enhan. 50. 0 58. 3 38. 9 7: 14 origin. 50. 0 84. 1 66. 6 5: 59 enhan. 83. 3 82. 1 66. 7 9: 55 origin. 16. 89 64. 5 50. 0 14: 23 enhan. 54. 1 73. 1 50. 0 17: 31 Medium Complex 18 -Mar-18 30

Appropriate choices Added exception Should have added Correct exceptions All exception added Complexity level Source REC% ACC% PRE% Time Simple origin. 16. 67 55. 6 33. 3 5: 36 enhan. 50. 0 58. 3 38. 9 7: 14 origin. 50. 0 84. 1 66. 6 5: 59 Medium enhan. Complex 83. 3 82. 1 66. 7 9: 55 origin. 16. 89 64. 5 50. 0 14: 23 50. 0 17: 31 enhan. 18 -Mar-18 54. 1 73. 1 31

Complexity metrics 18 -Mar-18 32

Conclusions n We provide an important feature for business analysts: suggest suitable exceptions. n Empirical evaluation proved value of the tool n Stakeholders receive a more accurate and robust business process 18 -Mar-18 33

Future Work n Open issues: n n 18 -Mar-18 Where does the semantic classification come from? (employ heuristics) Must be coordinated with a Business Repository system (Prosero). Usability is critical – should be improved (GUI: icons, perspectives). Feedback from runtime can provide valuable data on possible exceptions (Learning). 34

Feedback response C C C C Contribution in introduction Related work Why Prosero – values semantics Use Prosero RMR – future impl. Schema changes ramification – shorter OCL and XSL. Unclear solution – “To recommend and enforce”. See demo. Experiment participant – me. my. mi. Writing style – see paper. 18 -Mar-18 35

The End (Event) Any failures? 18 -Mar-18 36

Results Complexity level Source REC% ACC% PRE% F-M% Time Simple origin. 16. 67 55. 6 33. 3 22. 2 5: 36 enhan. 50. 0 58. 3 38. 9 43. 8 7: 14 origin. 50. 0 84. 1 66. 6 57. 1 5: 59 enhan. 83. 3 82. 1 66. 7 74. 1 9: 55 origin. 16. 89 64. 5 50. 0 25. 3 14: 23 enhan. 54. 1 73. 1 50. 0 52. 0 17: 31 Medium Complex 18 -Mar-18 37

Results Recall = (TP) / (TP + FN) n Accuracy = (TP + TN) / (TP + TN + FP + FN) n Precision = (TP) / (TP + FP) n F-measure = (2 * Precision * Recall) / (Precision + Recall) n 18 -Mar-18 38