1 / 38

Semantic business process for improved exception handling

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

naif
Télécharger la présentation

Semantic business process for improved exception handling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

  5. Introduction • 2 aspects considered: • how to identify exceptions • how to handle exceptions • enforce handling applied to Business Process Models (and BPMN specifically)

  6. Introduction: BPMN

  7. To make a long story short Before

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

  9. To make a long story short After (our contribution)

  10. Our Contribution • 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

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

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

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

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

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

  16. Our approach 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 3-Oct-14 16

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

  18. Why BPMN • 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.

  19. Why Prosero • Models in the repository are annotated with semantic meta-data, for the matching procedure • Future version could: • Use the repository data to infer on local semantics • Use the local semantics for the matching procedure 3-Oct-14 19

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

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

  22. Solution • Extend BPMN Activity • Errors • Handlers • Parameters • Offer recommendation • Classifications • Exceptions • Inference Relations () We constructed generic lists <elementsxsi:type="bpmn:Task" name="Don't Worry"> <eventHandler Trigger="Error" name="IsWorried" /> <errors name="IsWorried" /> <errors name="Timeout" /> </elements> • Perform action  Action failed • Complex action  Timeout • Send  Send rejected • Receive  Receive rejected • Query  Query failed • Update Update rejected

  23. Infer Potential Errors from Semantic Data When semantic parameters of construct are known, one can infer potential errors. • Activity is Send • Activity requires authentication  • Authentication fails • Send fails • Send rejected

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

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

  26. Template Instantiation • The abstract pattern, from the RMR, is instantiated into the CMR

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

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

  29. Evaluation

  30. Results

  31. Appropriate choices Added exception Should have added Correct exceptions All exception added     3-Oct-14 31

  32. Complexity metrics

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

  34. Future Work • Open issues: • 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).

  35. Feedback response • 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. 3-Oct-14 35

  36. The End (Event) Any failures?

  37. Results 3-Oct-14 37

  38. Results Recall = (TP) / (TP + FN) Accuracy = (TP + TN) / (TP + TN + FP + FN) Precision = (TP) / (TP + FP) F-measure = (2 * Precision * Recall) / (Precision + Recall) 3-Oct-14 38

More Related