Automatic Detection of Business Process Interference Nick van Beest , Eirini Kaldeli, Pavel Bulanov, Hans Wortmann, Alexander Lazovik University of Groningen, Netherlands KIBP 2012 15-06-2012
Context Distributed or service-oriented information systems Knowledge-intensive External stakeholders Assumption of process independence Concurrent business process execution
Problem [D = X] A1 A2 A3 A4 [D ≠ X ] B1 Change D t
Process interference: the situation where data mutations by one process affect one or more other concurrently executing processes, causing undesired process outcomes for one or more of these processes.
Related work Single process verification Analysis of failing process instances Run-time vs design-time
Solution (1) Awareness of dependencies of a process Define special sections in the business process that are vulnerable for external changes → Dependency Scope: A section in the business process whose correct execution relies on the accuracy of a volatile process variable. A volatile process variable is a process variable that can be changed externally during execution of the process.
Solution (2) Automatic execution of compensation activities → Intervention Process: sub-process comprising a set of compensation activities, which together restore the consistent state of a business process.
Dependency scope Dependency Scope DS1 [D] [D = X] A1 A2 A5 A3 A4 [D ≠ X ]
Intervention process Dependency Scope DS1 [D] [D = X] A1 A2: Halt A5 A3 A4 [D ≠ X ] Continue Activity P Activity Q A3 A4
Case Study: e-Government Dutch Law for Societal Support Home modifications Wheelchair provision Domestic help
Example: WMO Process Research and [Approved] Request Decision Provision Payment + + [Rejected] [No appeal] Terminate [Affirm Terminate decision] [Appeal] [Revise decision]
Provision [Personal budget] [Domestic help] Receive Handle Send request delivery Invoice to supplier [Care in kind] confirmation + [Approved] Acquire Send order to requirements supplier [Wheelchair] Receive Handle delivery Invoice [Else] confirmation + Send order Tender Check tender [Tender ok] confirmation to [Home procedure with decision Modification] selected supplier [Tender not ok]
Dependency scopes [Personal budget] [Domestic DS3: {Address, Medical Condition} help] Receive Handle Send request delivery Invoice to supplier [Care in kind] confirmation + DS1: {Address, Medical Condition} [Approved] Acquire Send order to requirements supplier [Wheelchair] Receive Handle delivery Invoice [Else] DS2: {WMO Eligibility Criteria} confirmation + Send order Tender Check tender [Tender ok] confirmation to [Home procedure with decision Modification] selected supplier [Tender not ok]
Intervention processes Receive Acquire Send order to a) Home visit delivery requirements supplier confirmation [New Requirements] Send order to Cancel order supplier Receive Acquire b) Pause order Home visit delivery requirements confirmation Resume order [Requirements Unchanged] [Rejected] Terminate Decision [Different situation] [Approved] [Tender ok] Receive Tender Check tender Send order to c) Home visit delivery procedure with decision supplier [Similar situation] confirmation [Tender not ok] [Rejected] Terminate Decision [Different situation] [Approved] [Tender ok] Receive Tender Check tender Send order to d) Cancel order Home visit delivery procedure with decision supplier [Similar situation] confirmation [Tender not ok] e) Cancel order Notify city hall
Components of a DS Sub-process in the BP to be monitored A number of events to react upon A number of intervention processes to be triggered Guard block : specifies the sub-process of the BP Verify block : specifies the types of events that require intervention
XML example <ds> <guard> <variables> <variable name="address" dataType="dt:address"/> <variable name="medCond" dataType="dt:medInfo"/> </variables> <!– Sub-process covered by DS1 as in Figure 2 --> </guard> <verify> <case condition="address.county!='Groningen'"> <terminate> <invoke name="IPa"/> </terminate> </case> <case condition="address.county='Groningen' && medCond!='deceased'"> <invoke name="IPb"/> </case> <case condition="medCond='deceased'"> <terminate> <invoke name="IPc"/> </terminate> </case> </verify> </ds>
DS and IP: the manual way Service Repository Business Process Modeller BP specification DS specification IP specification Process Executor BP execution IP execution Environment
Architecture: the manual way Process Modeller Service Repository Service Descriptions BP Specification Design Time Runtime Service Descriptions Process Executor Environment
DS and IP: the automated way Service Repository DS generator Business Process Modeller DS specification BP specification DS specification IP specification Process Executor CSP-based Planner BP execution IP generation IP execution Environment
Architecture: the automated way Process Modeller Service Repository Service DS Generator Descriptions BP Specification Compose DSs DS definition BP Specification Design Time Runtime Service Descriptions Process Executor Environment Goal + Initial State BP Specification Domain Generator Planning Domain Compose Planning Domain CSP-based Planner Intervention Process
Identification of a DS DSs cover all activities that are directly or indirectly dependent on a certain volatile variable (VV), i.e.: using the VV as input using the output of another activity, which is dependent on that VV. part of an XOR-construct with a condition over VV. Any part of the process in a potential execution path between two activities dependent on the same VV should also be covered by the respective DS.
Dependency scopes: some examples a) b) c)
Algorithm Branching End Branching Start TR TR DEP TR DEP TR All branches covered DSs are adjacent
Implementation Demonstrated and tested on the e-Government case study Three volatile variables were identified: Address Medical condition Eligibility criteria Five dependency scopes: Three for provision (as shown) Two regarding the decision
Screenshot
Conclusion Data is scattered No single ownership Cloud etc. A lot of work to be done in this area Continuity of the process can be ensured in an automated way Easy integration with existing BPMS platforms
Thank you for your attention
Architecture Process Modeller Service Repository prec: DS Generator eff: BP Specification Process Specific Compose Constraints DSs DS definition BP Specification Design Time Runtime Service Descriptions Process Executor DS Verifier + + Environment Goal + Initial State BP Specification + CSP-based Planner Atomic actions Planning Domain + Goal + Initial State Domain Generator prec: goal: Planning Domain Compose eff: Planning Domain Initial state: Generate IP Intervention Process
About the planner CSP Knowlege-level representation XOR, sensing, replanning Domain independent Supports extended goals temporal maintainability
Golog The goal to be achieved has to be specified in a procedural way, as a non-deterministic program, No use of high-level declarative goals The adaptation process has to be pre- specified in an action-centric way, which requires domain-specific knowledge of the available services Arduous hand-coding by a human expert.
Domain Example HomeVisit(hvIn_cid, hvIn_address) Prec: hvIn_cid = bpCid hvIn_address = bpAddress known(itOut_prov) Eff: sense(hvOut_homeInfo) sense(hvOut_maRequired) AcquireRequirements(arIn_cid, arIn_homeInfo) Prec: (itOut_prov = 3 OR itOut_prov = 4) itOut_prov = 3 arIn_cid = bpCid arIn_homeInfo = hvOut_homeInfo known(dcOut_approvalCheck) dcOut_approvalCheck = true Eff: sense(arOut_requirements)
Example: WMO Process Research and [Approved] Request Decision Provision Payment + + [Rejected] [No appeal] Terminate [Affirm Terminate decision] [Appeal] [Revise decision]
Research and Decision [No medical advice] Home visit Decision [Medical Medical advice] advice
Recommend
More recommend
