Query Stability in Monotonic Data-aware Business Processes* Ognjen - PowerPoint PPT Presentation

Query Stability in Monotonic Data-aware Business Processes* Ognjen Savković - “ Ogi ” joint work with Elisa Marengo and Werner Nutt Oxford, 2016 * Supported by the project MAGIC, funded by the Province of Bozen-Bolzano

Thesis Scope: • Query Completeness • Query Stability

Overview • Background on business processes that manipulate data • Our approach query stability in monotonic data-aware business processes

Business Process (BP) • A set of activities that are performed in coordination in an organizational environment … • Standardized languages for BPs • graphical format: BPMN • executable format: BPEL • Popular formalism : (Colored) Petri Nets

An example of BPMN model

Data-aware view of BPs • Data representation in BPMN/Petri Nets is limited • Data-centric approaches • Model processes as (infinite) relational transition systems • Verifying properties expressed in temporal logics • Verification is done using model checking • E.g., Data-Centric Business Processes [Deutsch, Vianu, et al.], Data-Centric Dynamic Systems (DCDS) [Calvanese, et al.]

DCDS Example Data Layer peer Schema Instance Customer These are foundational work that Cust ( ann ) peer ( mark , john ) focuses on decidability borders of In Debt Customer Gold ( john ) verification over BPs closed owes ( mark , @25) owes Gold Customer Loan · · · Process Layer Actions Condition Action Rules GetLoan ( x ) : No fine-grained analysis of peer ( x, y ) ^ Gold ( y ) 9 y. peer ( x, y ) { owes ( x, UInput ( x )) } , ! GetLoan ( x ) sources of complexity. 7� Cust ( z ) { Cust ( z ) } , Loan ( z ) { Loan ( z ) } , Service Calls InDebt ( z ) { InDebt ( z ) } , UInput ( x ) Control-flow is abstracted-away Gold ( z ) { Gold ( z ) } Examples: LTL FO : ∀ x. Customer ( x ) → F Gold ( x )

Objectives We want a “ simple ” process model that captures • Actions • Reading and writing of data • Conditions for executing actions based on data Over such a model we want to “ check ” query stability: Does the query answer stay the same while the process executes?

Students at UNIBZ • UNIBZ has around 3,500 students • Our former Dean of the Faculty of Computer Science used to say: “Every student is a precious flower”

Student Office Reports on Enrolled Students Enrollments Enrollments Faculty(of(Economics % 2014(/(2015 2015(/(2016 231 279 Bachelor)in)Economics)and)Management 20,78% 153 267 Bachelor)in)Tourism,)Sport)and)Event)Management 74,51% 87 102 Bachelor)in)Economics)and)Social)Sciences 17,24% 42 90 Master)in)Entrepreneurship)and)Innovation 114,29% 66 81 Master)in)Economics)and)Management)of)the)public)sector 22,73% 579 819 Sum 41,45% Enrollments Enrollments Faculty(of(Computer(Science % 2014(/(2015 2015(/(2016 115 150 Bachelor)in)Computer)Science)and)Engineering) 30,43% 180 100 Master)of)Science)in)Computer)Science <44,44% 295 250 Sum <15,25%

What is Wrong with the CS Master? Keep calm … Why do we have so few students? Of Course! The deadline for international programs is not over. The part of registration Dean of the Faculty process is still running. Prof. X Secretary

Can we prevent this in the future? Can you code a procedure that will add a reliability/stability flag for each of the figures? Dean of the Faculty Our process models are in standard language called • BPMN . However, BPMN doesn’t describe how the process manipulates data Checking the code would be too much work • Also, when the code changes, the procedure for • getting the flags may become obsolete IT Technician

Our Solution: Query Stability in Monotonic Data- aware Business Processes (MDBPs)

An example of BPMN model

MDBP: Process Net (control-flow) early / intl. late register directly intl. ontime is admitted is intl. register app. accept app. app. isn't approve approve cond. stud. end start admitted app. decis. withdraw app. complete app. is reg. app. acad. reg. ontime reject app. check early / reg. late Modeled as directed graph with: - States/Places (= vertices) - Transitions (= edges)

MDBP: Database StudyPlan AdmittedIntl course type program student course compLogic intl mscCS bob compLogic compLogic reg mscCS mary compLogic econ reg mscECO Deadline Registered registration date student course 1 st Jul noregst bob compLogic 30 th Sept pre-enrol alice econ 31 st Oct reg 31 st Dec intl

MDBP : Input Relation • We want to model fresh data brought by the instances from the external world • E.g., a student who wants to register fills into a web form • the student name • the course • The web site records the timestamp • We model this by a one-tuple relation In for each process instance In(alice, compLogic, 1/11/2015)

MDBP: Execution Conditions 𝑭 𝒖 ∶ 𝑱𝒐 𝒕 9 , 𝑺 𝟐 𝒗 < 𝟐 , … , 𝑺 𝒍 𝒗 < 𝒍 , ¬𝑺 𝒍?𝟐 𝒗 < 𝒍?𝟐 , … , ¬𝑺 𝒏 𝒗 < 𝒏 early / intl. late register directly intl. ontime is admitted is intl. register app. accept app. app. isn't approve approve cond. stud. end start admitted app. decis. withdraw app. complete app. is reg. app. acad. reg. ontime reject app. check early / reg. late Transition t Execution Condition E t 𝑱𝒐 𝑻, 𝑫, 𝑼 , 𝑻𝒖𝒗𝒆𝒛𝑸𝒎𝒃𝒐 𝑫, 𝒔𝒇𝒉, 𝑸 , ¬𝑻𝒖𝒗𝒆𝒛𝑸𝒎𝒃𝒐(𝑫, 𝒋𝒐𝒖𝒎, 𝑸) is reg. app. …. …

MDBP: Writing Rules 𝑿 𝒖 ∶ 𝑺 𝒗 < ← 𝑱𝒐 𝒕 9 , 𝑺 𝟐 𝒗 < 𝟐 , … , 𝑺 𝒍 𝒗 < 𝒍 , ¬𝑺 𝒍?𝟐 𝒗 < 𝒍?𝟐 , … , ¬𝑺 𝒏 𝒗 < 𝒏 a writing rule is not a recursive rule early / intl. late register directly intl. ontime is admitted is intl. register app. accept app. app. isn't approve approve cond. stud. end start admitted app. decis. withdraw app. complete app. is reg. app. acad. reg. ontime reject app. check early / reg. late Transition t Writing Rule W t register app. 𝑺𝒇𝒉𝒋𝒕𝒖𝒇𝒔 𝑻, 𝑫 ← 𝑱𝒐 𝑻, 𝑫, 𝑼 , 𝑻𝒖𝒗𝒆𝒛𝑸𝒎𝒃𝒐 𝑻, 𝒁, 𝑸 …. …

MDBP: Process Instances We allow an unbounded number of instances to: • execute the process simultaneously • interact with each other via the database The process instances are modeled by a pair I = (O,M) where • O is the set of active process ids (objects) O = = {o jo john , , o al , o bo bob } alice, • M determines input record and current state for each instance e.g. process instance M In M P start o john In(john, compLogic, 23/10/2014) M = end o alice In(nick, econ, 10/10/2014) end o bob In(bob, compLogic, 20/09/2014)

The process only combines MDBP: Execution data from instances and database Two kinds of execution steps: Introduction and Traversal • Introduction of a fresh process instance with fresh In- record Fresh data can be imported only by starting new instances Inp ( John , EMCL , 05 / 06 / 2014 @ 14 : 00 In(alice, compLogic, 12/12/2014) start start Process instances share the Enabled : always same database • Traversal of transition t by a process instance with record 𝑱𝒐 𝒕 9 (excluding input records) cond: E t cond: E t action: W t action: W t Database can only grow Enabled : if D ∪ 𝑱𝒐 𝒕 9 ⊨ 𝑭 𝒖 D += 𝑿 𝒖 ( D ∪ 𝑱𝒐 𝒕 Effect : 9 )

Monotonic Data-aware Business Processes (Static Part) Process Net early / intl. late register directly intl. ontime is admitted is intl. accept app. register app. app. isn't approve approve cond. stud. end start admitted app. decis. withdraw app. complete app. is reg. app. acad. reg. ontime reject app. check early / reg. late 𝑱𝒐 𝑻, 𝑫, 𝑼 , 𝑻𝒖𝒗𝒆𝒛𝑸𝒎𝒃𝒐 𝑫, 𝒔𝒇𝒉, 𝑸 , ¬𝑻𝒖𝒗𝒆𝒛𝑸𝒎𝒃𝒐 𝑫, 𝒋𝒐𝒖𝒎, 𝑸 Execution Condition 𝑺𝒇𝒉𝒋𝒕𝒖𝒇𝒔 𝑻, 𝑫 ← 𝑱𝒐 𝑻, 𝑫, 𝑼 , 𝑻𝒖𝒗𝒆𝒛𝑸𝒎𝒃𝒐 𝑻, 𝒁, 𝑸 Writing Action

Monotonic Data-aware Business Processes (Dynamic Part) Process Net early / intl. late register directly intl. ontime is admitted is intl. accept app. register app. app. isn't approve approve cond. stud. end start admitted app. decis. withdraw app. complete app. is reg. app. acad. reg. ontime reject app. check early / reg. late ids Instance record place o john In(john, compLogic, 23/10/2014) start o alice In(nick, econ, 10/10/2014) acad. check o bob In(bob, compLogic, 20/09/2014) end Database Tables Running Instances