9. Data-aware processes
• An “urban legend”
• Cons: no formal definition of the concept (only
a set of “recommendations”)
• Pros: very permissive and allow to attack the
dichotomy problem from various perspectives
11. Travel reimbursement in a
company
Financial
accounting
review
Employee
prepare
travel request
prepare
reimbursement
request
request
info
send
result
Travel
log data
13. In database expert’s mind
External
input
Financial
accounting
review
Employee
prepare
travel request
prepare
reimbursement
request
request
info
send
result
Travel
log data
• We have a fixed storage…
• … and some process in mind
14. In database expert’s mind
Financial
accounting
review
Employee
prepare
travel request
prepare
reimbursement
request
request
info
send
result
Travel
log data
External
input
• We have a fixed storage…
• … and some process in mind
How to model, implement, and analyse this
DAP?
15. Relational data-aware processes
Setting:
• the database is given, and can be directly accessed and
updated by running processes
• builds on the previously proposed formalism of DCDSs
Desiderata:
• A representation of DCDSs fully embedded in SQL
• An execution engine running on top of an RDBMS + logging
functionalities
• Suitable for formal analysis
16. dapSL
data-aware process specification language
dapSL specification
data layer process layer
• A relational database
• Supported constraints:
PK, FK, CHECK
• Data updates via atomic
actions
• Control-flow via CA-rules
(determine when actions
can be executed)
• Data injections via
service calls
17. dapSL: modeling
Data layer uses the standard SQL DDL
CurrReq
ID Empl Dest Status
1 Bob NY submitd
2 Kriss Rome submitd
TrvlMaxAmnt
ID FID maxAmnt
- - -
“requests under process”
“maximum allowed
trip budgets”
{submitd,
acceptd,
reimbursed,
…}
FK_TrvlMaxAmnt_CurrReq
18. dapSL: modeling
“. . . examine an employee’s trip reimbursement request and, if
accepted, assign the maximum reimbursable amount to it . . . ”
CA-rules = SELECT queries with action signature references
dapSL. StartWF creates a new travel reimbursement request by picking a pending requests
the current DB. We represent this in dapSL as an action with three formal parameters, denot
pending request id, its responsible employee, and her intended destination:
SELECT id, emp, dest FROM Pending ENABLES StartWF(id, emp, dest);
StartWF(id, emp, dest):{DELETE FROM Pending WHERE Pending.id = id;
INSERT INTO CurrReq(id, emp, dest, status) VALUES(@genpk(), emp, dest, submi
Here, a new request is generated by removing from Pending the entry that matches the give
then inserting a new tuple into CurrReq with the emp and dest values of the deleted tuple
the status set to ‘submitd’. To get a unique id for such a tuple, we invoke the nullary service
@genpk, returning a fresh primary key value.
ReviewRequest examines an employee trip request and, if accepted, assigns its maxim
reimbursable amount. The action can be executed only if a request in CurrReq actually exi
SELECT id, emp, dest FROM CurrReq WHERE CurrReq.status = ‘submitd’
ENABLES RvwRequest(id, emp, dest);
RvwRequest(id, emp, dest):{DELETE FROM CurrReq WHERE CurrReq.id = id;
INSERT INTO CurrReq(id, emp, dest, status)
VALUES(id, emp, dest, @status(emp, dest));
INSERT INTO TrvlMaxAmnt(tid, tfid, tmaxAmnt)
VALUES(@genpk(), id, @maxAmnt(emp, dest))}
19. dapSL: modeling
“. . . examine an employee’s trip reimbursement request and, if
accepted, assign the maximum reimbursable amount to it . . . ”
CA-rules = SELECT queries with action signature references
dapSL. StartWF creates a new travel reimbursement request by picking a pending requests
the current DB. We represent this in dapSL as an action with three formal parameters, denot
pending request id, its responsible employee, and her intended destination:
SELECT id, emp, dest FROM Pending ENABLES StartWF(id, emp, dest);
StartWF(id, emp, dest):{DELETE FROM Pending WHERE Pending.id = id;
INSERT INTO CurrReq(id, emp, dest, status) VALUES(@genpk(), emp, dest, submi
Here, a new request is generated by removing from Pending the entry that matches the give
then inserting a new tuple into CurrReq with the emp and dest values of the deleted tuple
the status set to ‘submitd’. To get a unique id for such a tuple, we invoke the nullary service
@genpk, returning a fresh primary key value.
ReviewRequest examines an employee trip request and, if accepted, assigns its maxim
reimbursable amount. The action can be executed only if a request in CurrReq actually exi
SELECT id, emp, dest FROM CurrReq WHERE CurrReq.status = ‘submitd’
ENABLES RvwRequest(id, emp, dest);
RvwRequest(id, emp, dest):{DELETE FROM CurrReq WHERE CurrReq.id = id;
INSERT INTO CurrReq(id, emp, dest, status)
VALUES(id, emp, dest, @status(emp, dest));
INSERT INTO TrvlMaxAmnt(tid, tfid, tmaxAmnt)
VALUES(@genpk(), id, @maxAmnt(emp, dest))}
the rule
condition
the parametrised
action
20. dapSL: modeling
“. . . examine an employee’s trip reimbursement request and, if
accepted, assign the maximum reimbursable amount to it . . . ”
Actions = collections of parametrised INSERT’s/DELETE’s
pending request id, its responsible employee, and her intended destination:
SELECT id, emp, dest FROM Pending ENABLES StartWF(id, emp, dest);
StartWF(id, emp, dest):{DELETE FROM Pending WHERE Pending.id = id;
INSERT INTO CurrReq(id, emp, dest, status) VALUES(@genpk(), emp, dest, submit
Here, a new request is generated by removing from Pending the entry that matches the given
then inserting a new tuple into CurrReq with the emp and dest values of the deleted tuple,
the status set to ‘submitd’. To get a unique id for such a tuple, we invoke the nullary service
@genpk, returning a fresh primary key value.
ReviewRequest examines an employee trip request and, if accepted, assigns its maxim
reimbursable amount. The action can be executed only if a request in CurrReq actually exist
SELECT id, emp, dest FROM CurrReq WHERE CurrReq.status = ‘submitd’
ENABLES RvwRequest(id, emp, dest);
RvwRequest(id, emp, dest):{DELETE FROM CurrReq WHERE CurrReq.id = id;
INSERT INTO CurrReq(id, emp, dest, status)
VALUES(id, emp, dest, @status(emp, dest));
INSERT INTO TrvlMaxAmnt(tid, tfid, tmaxAmnt)
VALUES(@genpk(), id, @maxAmnt(emp, dest))}
• Use SELECT inside VALUES to get a bulk update
• @ to specify service call invocations
21. dapSL: modeling
“. . . examine an employee’s trip reimbursement request and, if
accepted, assign the maximum reimbursable amount to it . . . ”
Actions = collections of parametrised INSERT’s/DELETE’s
pending request id, its responsible employee, and her intended destination:
SELECT id, emp, dest FROM Pending ENABLES StartWF(id, emp, dest);
StartWF(id, emp, dest):{DELETE FROM Pending WHERE Pending.id = id;
INSERT INTO CurrReq(id, emp, dest, status) VALUES(@genpk(), emp, dest, submit
Here, a new request is generated by removing from Pending the entry that matches the given
then inserting a new tuple into CurrReq with the emp and dest values of the deleted tuple,
the status set to ‘submitd’. To get a unique id for such a tuple, we invoke the nullary service
@genpk, returning a fresh primary key value.
ReviewRequest examines an employee trip request and, if accepted, assigns its maxim
reimbursable amount. The action can be executed only if a request in CurrReq actually exist
SELECT id, emp, dest FROM CurrReq WHERE CurrReq.status = ‘submitd’
ENABLES RvwRequest(id, emp, dest);
RvwRequest(id, emp, dest):{DELETE FROM CurrReq WHERE CurrReq.id = id;
INSERT INTO CurrReq(id, emp, dest, status)
VALUES(id, emp, dest, @status(emp, dest));
INSERT INTO TrvlMaxAmnt(tid, tfid, tmaxAmnt)
VALUES(@genpk(), id, @maxAmnt(emp, dest))}
• Use SELECT inside VALUES to get a bulk update
• @ to specify service call invocations
formal
parameters
22. dapSL: execution semantics
CurrReq
ID Empl Dest Status
1 Bob NY submitd
2 Kriss Rome submitd
TrvlMaxAmnt
ID FID maxAmnt
- - -DB_state
Example 3. We focus on three tasks of the process in Example 1, showing their encodin
dapSL. StartWF creates a new travel reimbursement request by picking a pending requests
the current DB. We represent this in dapSL as an action with three formal parameters, denot
pending request id, its responsible employee, and her intended destination:
SELECT id, emp, dest FROM Pending ENABLES StartWF(id, emp, dest);
StartWF(id, emp, dest):{DELETE FROM Pending WHERE Pending.id = id;
INSERT INTO CurrReq(id, emp, dest, status) VALUES(@genpk(), emp, dest, submi
Here, a new request is generated by removing from Pending the entry that matches the give
then inserting a new tuple into CurrReq with the emp and dest values of the deleted tuple
the status set to ‘submitd’. To get a unique id for such a tuple, we invoke the nullary service
@genpk, returning a fresh primary key value.
ReviewRequest examines an employee trip request and, if accepted, assigns its maxim
reimbursable amount. The action can be executed only if a request in CurrReq actually exi
SELECT id, emp, dest FROM CurrReq WHERE CurrReq.status = ‘submitd’
ENABLES RvwRequest(id, emp, dest);
RvwRequest(id, emp, dest):{DELETE FROM CurrReq WHERE CurrReq.id = id;
INSERT INTO CurrReq(id, emp, dest, status)
VALUES(id, emp, dest, @status(emp, dest));
INSERT INTO TrvlMaxAmnt(tid, tfid, tmaxAmnt)
VALUES(@genpk(), id, @maxAmnt(emp, dest))}
23. dapSL: execution semantics
CurrReq
ID Empl Dest Status
1 Bob NY submitd
2 Kriss Rome submitd
TrvlMaxAmnt
ID FID maxAmnt
- - -DB_state
Example 3. We focus on three tasks of the process in Example 1, showing their encodin
dapSL. StartWF creates a new travel reimbursement request by picking a pending requests
the current DB. We represent this in dapSL as an action with three formal parameters, denot
pending request id, its responsible employee, and her intended destination:
SELECT id, emp, dest FROM Pending ENABLES StartWF(id, emp, dest);
StartWF(id, emp, dest):{DELETE FROM Pending WHERE Pending.id = id;
INSERT INTO CurrReq(id, emp, dest, status) VALUES(@genpk(), emp, dest, submi
Here, a new request is generated by removing from Pending the entry that matches the give
then inserting a new tuple into CurrReq with the emp and dest values of the deleted tuple
the status set to ‘submitd’. To get a unique id for such a tuple, we invoke the nullary service
@genpk, returning a fresh primary key value.
ReviewRequest examines an employee trip request and, if accepted, assigns its maxim
reimbursable amount. The action can be executed only if a request in CurrReq actually exi
SELECT id, emp, dest FROM CurrReq WHERE CurrReq.status = ‘submitd’
ENABLES RvwRequest(id, emp, dest);
RvwRequest(id, emp, dest):{DELETE FROM CurrReq WHERE CurrReq.id = id;
INSERT INTO CurrReq(id, emp, dest, status)
VALUES(id, emp, dest, @status(emp, dest));
INSERT INTO TrvlMaxAmnt(tid, tfid, tmaxAmnt)
VALUES(@genpk(), id, @maxAmnt(emp, dest))}
Query
24. dapSL: execution semantics
CurrReq
ID Empl Dest Status
1 Bob NY submitd
2 Kriss Rome submitd
TrvlMaxAmnt
ID FID maxAmnt
- - -DB_state
Example 3. We focus on three tasks of the process in Example 1, showing their encodin
dapSL. StartWF creates a new travel reimbursement request by picking a pending requests
the current DB. We represent this in dapSL as an action with three formal parameters, denot
pending request id, its responsible employee, and her intended destination:
SELECT id, emp, dest FROM Pending ENABLES StartWF(id, emp, dest);
StartWF(id, emp, dest):{DELETE FROM Pending WHERE Pending.id = id;
INSERT INTO CurrReq(id, emp, dest, status) VALUES(@genpk(), emp, dest, submi
Here, a new request is generated by removing from Pending the entry that matches the give
then inserting a new tuple into CurrReq with the emp and dest values of the deleted tuple
the status set to ‘submitd’. To get a unique id for such a tuple, we invoke the nullary service
@genpk, returning a fresh primary key value.
ReviewRequest examines an employee trip request and, if accepted, assigns its maxim
reimbursable amount. The action can be executed only if a request in CurrReq actually exi
SELECT id, emp, dest FROM CurrReq WHERE CurrReq.status = ‘submitd’
ENABLES RvwRequest(id, emp, dest);
RvwRequest(id, emp, dest):{DELETE FROM CurrReq WHERE CurrReq.id = id;
INSERT INTO CurrReq(id, emp, dest, status)
VALUES(id, emp, dest, @status(emp, dest));
INSERT INTO TrvlMaxAmnt(tid, tfid, tmaxAmnt)
VALUES(@genpk(), id, @maxAmnt(emp, dest))}
InstantiateQuery
2 Kriss Rome
25. dapSL: execution semantics
CurrReq
ID Empl Dest Status
1 Bob NY submitd
2 Kriss Rome submitd
TrvlMaxAmnt
ID FID maxAmnt
- - -DB_state
Example 3. We focus on three tasks of the process in Example 1, showing their encodin
dapSL. StartWF creates a new travel reimbursement request by picking a pending requests
the current DB. We represent this in dapSL as an action with three formal parameters, denot
pending request id, its responsible employee, and her intended destination:
SELECT id, emp, dest FROM Pending ENABLES StartWF(id, emp, dest);
StartWF(id, emp, dest):{DELETE FROM Pending WHERE Pending.id = id;
INSERT INTO CurrReq(id, emp, dest, status) VALUES(@genpk(), emp, dest, submi
Here, a new request is generated by removing from Pending the entry that matches the give
then inserting a new tuple into CurrReq with the emp and dest values of the deleted tuple
the status set to ‘submitd’. To get a unique id for such a tuple, we invoke the nullary service
@genpk, returning a fresh primary key value.
ReviewRequest examines an employee trip request and, if accepted, assigns its maxim
reimbursable amount. The action can be executed only if a request in CurrReq actually exi
SELECT id, emp, dest FROM CurrReq WHERE CurrReq.status = ‘submitd’
ENABLES RvwRequest(id, emp, dest);
RvwRequest(id, emp, dest):{DELETE FROM CurrReq WHERE CurrReq.id = id;
INSERT INTO CurrReq(id, emp, dest, status)
VALUES(id, emp, dest, @status(emp, dest));
INSERT INTO TrvlMaxAmnt(tid, tfid, tmaxAmnt)
VALUES(@genpk(), id, @maxAmnt(emp, dest))}
RunInstantiateQuery
2 Kriss Rome
26. RvwRequest(2,Kriss,Rome)
dapSL: execution semantics
CurrReq
ID Empl Dest Status
1 Bob NY submitd
2 Kriss Rome submitd
TrvlMaxAmnt
ID FID maxAmnt
- - -DB_state
Example 3. We focus on three tasks of the process in Example 1, showing their encodin
dapSL. StartWF creates a new travel reimbursement request by picking a pending requests
the current DB. We represent this in dapSL as an action with three formal parameters, denot
pending request id, its responsible employee, and her intended destination:
SELECT id, emp, dest FROM Pending ENABLES StartWF(id, emp, dest);
StartWF(id, emp, dest):{DELETE FROM Pending WHERE Pending.id = id;
INSERT INTO CurrReq(id, emp, dest, status) VALUES(@genpk(), emp, dest, submi
Here, a new request is generated by removing from Pending the entry that matches the give
then inserting a new tuple into CurrReq with the emp and dest values of the deleted tuple
the status set to ‘submitd’. To get a unique id for such a tuple, we invoke the nullary service
@genpk, returning a fresh primary key value.
ReviewRequest examines an employee trip request and, if accepted, assigns its maxim
reimbursable amount. The action can be executed only if a request in CurrReq actually exis
SELECT id, emp, dest FROM CurrReq WHERE CurrReq.status = ‘submitd’
ENABLES RvwRequest(id, emp, dest);
RvwRequest(id, emp, dest):{DELETE FROM CurrReq WHERE CurrReq.id = id;
INSERT INTO CurrReq(id, emp, dest, status)
VALUES(id, emp, dest, @status(emp, dest));
INSERT INTO TrvlMaxAmnt(tid, tfid, tmaxAmnt)
VALUES(@genpk(), id, @maxAmnt(emp, dest))}
27. Service callsRvwRequest(2,Kriss,Rome)
dapSL: execution semantics
CurrReq
ID Empl Dest Status
1 Bob NY submitd
2 Kriss Rome submitd
TrvlMaxAmnt
ID FID maxAmnt
- - -DB_state
Example 3. We focus on three tasks of the process in Example 1, showing their encodin
dapSL. StartWF creates a new travel reimbursement request by picking a pending requests
the current DB. We represent this in dapSL as an action with three formal parameters, denot
pending request id, its responsible employee, and her intended destination:
SELECT id, emp, dest FROM Pending ENABLES StartWF(id, emp, dest);
StartWF(id, emp, dest):{DELETE FROM Pending WHERE Pending.id = id;
INSERT INTO CurrReq(id, emp, dest, status) VALUES(@genpk(), emp, dest, submi
Here, a new request is generated by removing from Pending the entry that matches the give
then inserting a new tuple into CurrReq with the emp and dest values of the deleted tuple
the status set to ‘submitd’. To get a unique id for such a tuple, we invoke the nullary service
@genpk, returning a fresh primary key value.
ReviewRequest examines an employee trip request and, if accepted, assigns its maxim
reimbursable amount. The action can be executed only if a request in CurrReq actually exis
SELECT id, emp, dest FROM CurrReq WHERE CurrReq.status = ‘submitd’
ENABLES RvwRequest(id, emp, dest);
RvwRequest(id, emp, dest):{DELETE FROM CurrReq WHERE CurrReq.id = id;
INSERT INTO CurrReq(id, emp, dest, status)
VALUES(id, emp, dest, @status(emp, dest));
INSERT INTO TrvlMaxAmnt(tid, tfid, tmaxAmnt)
VALUES(@genpk(), id, @maxAmnt(emp, dest))}
28. Service callsRvwRequest(2,Kriss,Rome)
dapSL: execution semantics
CurrReq
ID Empl Dest Status
1 Bob NY submitd
2 Kriss Rome submitd
TrvlMaxAmnt
ID FID maxAmnt
- - -DB_state
Example 3. We focus on three tasks of the process in Example 1, showing their encodin
dapSL. StartWF creates a new travel reimbursement request by picking a pending requests
the current DB. We represent this in dapSL as an action with three formal parameters, denot
pending request id, its responsible employee, and her intended destination:
SELECT id, emp, dest FROM Pending ENABLES StartWF(id, emp, dest);
StartWF(id, emp, dest):{DELETE FROM Pending WHERE Pending.id = id;
INSERT INTO CurrReq(id, emp, dest, status) VALUES(@genpk(), emp, dest, submi
Here, a new request is generated by removing from Pending the entry that matches the give
then inserting a new tuple into CurrReq with the emp and dest values of the deleted tuple
the status set to ‘submitd’. To get a unique id for such a tuple, we invoke the nullary service
@genpk, returning a fresh primary key value.
ReviewRequest examines an employee trip request and, if accepted, assigns its maxim
reimbursable amount. The action can be executed only if a request in CurrReq actually exis
SELECT id, emp, dest FROM CurrReq WHERE CurrReq.status = ‘submitd’
ENABLES RvwRequest(id, emp, dest);
RvwRequest(id, emp, dest):{DELETE FROM CurrReq WHERE CurrReq.id = id;
INSERT INTO CurrReq(id, emp, dest, status)
VALUES(id, emp, dest, @status(emp, dest));
INSERT INTO TrvlMaxAmnt(tid, tfid, tmaxAmnt)
VALUES(@genpk(), id, @maxAmnt(emp, dest))}
status(Kriss,Rome)=acceptd
maxAmnt(Kriss,Rome)=900
genpk()=10
29. Update!Service callsRvwRequest(2,Kriss,Rome)
dapSL: execution semantics
CurrReq
ID Empl Dest Status
1 Bob NY submitd
2 Kriss Rome acceptd
TrvlMaxAmnt
ID FID maxAmnt
10 2 900DB_state’
Example 3. We focus on three tasks of the process in Example 1, showing their encodin
dapSL. StartWF creates a new travel reimbursement request by picking a pending requests
the current DB. We represent this in dapSL as an action with three formal parameters, denot
pending request id, its responsible employee, and her intended destination:
SELECT id, emp, dest FROM Pending ENABLES StartWF(id, emp, dest);
StartWF(id, emp, dest):{DELETE FROM Pending WHERE Pending.id = id;
INSERT INTO CurrReq(id, emp, dest, status) VALUES(@genpk(), emp, dest, submi
Here, a new request is generated by removing from Pending the entry that matches the give
then inserting a new tuple into CurrReq with the emp and dest values of the deleted tuple
the status set to ‘submitd’. To get a unique id for such a tuple, we invoke the nullary service
@genpk, returning a fresh primary key value.
ReviewRequest examines an employee trip request and, if accepted, assigns its maxim
reimbursable amount. The action can be executed only if a request in CurrReq actually exis
SELECT id, emp, dest FROM CurrReq WHERE CurrReq.status = ‘submitd’
ENABLES RvwRequest(id, emp, dest);
RvwRequest(id, emp, dest):{DELETE FROM CurrReq WHERE CurrReq.id = id;
INSERT INTO CurrReq(id, emp, dest, status)
VALUES(id, emp, dest, @status(emp, dest));
INSERT INTO TrvlMaxAmnt(tid, tfid, tmaxAmnt)
VALUES(@genpk(), id, @maxAmnt(emp, dest))}
status(Kriss,Rome)=acceptd
maxAmnt(Kriss,Rome)=900
genpk()=10
30. Towards implementing dapSL
• dapSL specification is maintained by the RDBMS
• Interaction is provided by a Flow Engine, which:
• executes calls to the RDBMS
• interplays with external services through a Service
Manager
vanese, Montali, Patrizi, Rivkin
DB
Engine
Flow
Engine
Service
Manager
Persistent Storage
DAPHNE system
DAPHNE
state
dapSL Spec.
RDBMS
...
user
input
web
service
Fig. 2: Conceptual architecture of DAPHNE
status of CurrReq is updated by calling service @status, that tak
me and a trip destination, and returns a new status value. Also, a new tu
reimbursable amount is added to TrvlMaxAmnt. To get the maximu
rvlMaxAmnt, we employ service @maxAmnt with the same argument
Reimb updates the current request by adding a compiled form wi
31. Three modalities of DAPHNE
Modeling and In-Database Management of Relational, Dat
Enactment
I I0
Enactment with history recall
t0 t1
. . . tn tn+1
Sta
s0
The three main usage modalities for DAPHNE, and ske
ructures stored within the DBMS
gement system (DBMS) to support its execution. The DB
ta relevant to the input dapSL model and supports, th
derlying DBMS, the application of a set of operation
dapSL actions. The Flow Engine constitutes the applicati
Enactment
n-Database Management of Relational, Data-Aware Processe
Enactment with history recall
t0 t1
. . . tn tn+1
State space construction
s0
s1
s2 s3
. . .
usage modalities for DAPHNE, and sketch of the corre
within the DBMS
DBMS) to support its execution. The DBMS takes care o
l, Data-Aware Processes 7
State space construction
s0
s1
s2 s3
...
Enactment with history recall
State space construction
“casually run the process”
“casually run the process
and record its execution”
“automatically generate
(all?) possible executions
for formal analysis”
32. Three modalities of DAPHNE
Modeling and In-Database Management of Relational, Dat
Enactment
I I0
Enactment with history recall
t0 t1
. . . tn tn+1
Sta
s0
The three main usage modalities for DAPHNE, and ske
ructures stored within the DBMS
gement system (DBMS) to support its execution. The DB
ta relevant to the input dapSL model and supports, th
derlying DBMS, the application of a set of operation
dapSL actions. The Flow Engine constitutes the applicati
Enactment
n-Database Management of Relational, Data-Aware Processe
Enactment with history recall
t0 t1
. . . tn tn+1
State space construction
s0
s1
s2 s3
. . .
usage modalities for DAPHNE, and sketch of the corre
within the DBMS
DBMS) to support its execution. The DBMS takes care o
l, Data-Aware Processes 7
State space construction
s0
s1
s2 s3
...
Enactment with history recall
State space construction
“casually run the process”
“casually run the process
and record its execution”
“automatically generate
(all?) possible executions
for formal analysis”
Unique database to represent all
the modalities!
34. Implementing three modalities
Idea: Use actual SQL and (its dialects) to represent
dapSL specifications in RDBMSs
Pros: doesn’t require special knowledge
+ can exploit various RDBMS features
35. Implementing three modalities
Idea: Use actual SQL and (its dialects) to represent
dapSL specifications in RDBMSs
Pros: doesn’t require special knowledge
+ can exploit various RDBMS features
Cons: specifying a workflow inside the RDBMS could
be quite complex
37. Implementing three modalities
Problem #1: how to represent the whole system
evolution in the DB and respect integrity
constraints between relations over time?
Solution: use a clever encoding of relations into
tables that account for temporal and atemporal
parts
38. Implementing three modalities
CurrReq_raw
RID Empl Dest Status
4 Bob NY submitd
5 Kriss Rome submitd
6 Kriss Rome acceptd
TrvlMaxAmnt_raw
RID maxAmnt
15 900
CurrReq_log
state ID RID
2 1 4
2 2 5
3 2 4
3 2 6
TrvlMaxAmnt_log
state ID RID FID
3 10 15 2
FK_TrvlMaxAmnt_CurrReq
CurrReq
ID Empl Dest Status
1 Bob NY submitd
2 Kriss Rome acceptd
TrvlMaxAmnt
ID FID maxAmnt
10 2 900
FK_TrvlMaxAmnt_CurrReq
40. Implementing the modalities
SELECT id, emp, dest FROM Pending ENABLES StartWF(id, emp, dest);
StartWF(id, emp, dest):{DELETE FROM Pending WHERE Pending.id = id;
INSERT INTO CurrReq(id, emp, dest, status) VALUES(@genpk(), emp, dest, submit
Here, a new request is generated by removing from Pending the entry that matches the given
then inserting a new tuple into CurrReq with the emp and dest values of the deleted tuple,
the status set to ‘submitd’. To get a unique id for such a tuple, we invoke the nullary service
@genpk, returning a fresh primary key value.
ReviewRequest examines an employee trip request and, if accepted, assigns its maxim
reimbursable amount. The action can be executed only if a request in CurrReq actually exist
SELECT id, emp, dest FROM CurrReq WHERE CurrReq.status = ‘submitd’
ENABLES RvwRequest(id, emp, dest);
RvwRequest(id, emp, dest):{DELETE FROM CurrReq WHERE CurrReq.id = id;
INSERT INTO CurrReq(id, emp, dest, status)
VALUES(id, emp, dest, @status(emp, dest));
INSERT INTO TrvlMaxAmnt(tid, tfid, tmaxAmnt)
VALUES(@genpk(), id, @maxAmnt(emp, dest))}
A compact Review Request action in dapSL
turns into…
42. Representing dapSL spec.
• How do we translate the specifications?
• Define an object model for dapSL using jOOQ,
including component-specific translators
44. Implementing the 3rd modality
• The state-space is in general infinite
• Use the finite-state abstraction technique of
DCDSs
• the abstraction can be automatically
constructed using DAPHNE (service) APIs
45. Implementing the 3rd modality
• The state-space is in general infinite
• Use the finite-state abstraction technique of DCDSs
• the abstraction can be automatically constructed
using DAPHNE (service) APIs
• The generated state space is stored in the DB
use SQL to run analytic queries
the same model for enactment and verification!
46. Connections with other
approaches
• dapSL is a front-end language for DCDSs
• We know how to relate DCDSs (and thus dapSL) to:
✓ GSM-based business artifacts
✓ -Petri nets equipped with resources and tokens
with abstract data
✓ recent variants of (colored) Petri nets equipped
with a DB storage
⌫<latexit sha1_base64="YGPqV/Iq5qj1Ohe4ayAdToTjy64=">AAAB6nicbZC7SgNBFIbPeo3rLWppMxgEq7Bro40YtLGMaC6QLGF2MpsMmZ1dZs4KYQn4AjYWitj6LvZ2vo2TS6GJPwx8/P85zDknTKUw6HnfztLyyuraemHD3dza3tkt7u3XTZJpxmsskYluhtRwKRSvoUDJm6nmNA4lb4SD63HeeODaiETd4zDlQUx7SkSCUbTWXVtlnWLJK3sTkUXwZ1C6/HQvHgGg2il+tbsJy2KukElqTMv3UgxyqlEwyUduOzM8pWxAe7xlUdGYmyCfjDoix9bpkijR9ikkE/d3R05jY4ZxaCtjin0zn43N/7JWhtF5kAuVZsgVm34UZZJgQsZ7k67QnKEcWqBMCzsrYX2qKUN7HdcewZ9feRHqp2XfK/u3fqlyBVMV4BCO4AR8OIMK3EAVasCgB0/wAq+OdJ6dN+d9WrrkzHoO4I+cjx/NK4+h</latexit><latexit sha1_base64="GWRCYrUuf4tRLwmEljXBNHCMHTs=">AAAB6nicbZC7SgNBFIbPxltcb1FLm8EgWIVdG23EoI1lRHOBZAmzk5NkyOzsMjMrhCWPYGOhiKW+i72N+DZOLoUm/jDw8f/nMOecMBFcG8/7dnJLyyura/l1d2Nza3unsLtX03GqGFZZLGLVCKlGwSVWDTcCG4lCGoUC6+HgapzX71FpHss7M0wwiGhP8i5n1FjrtiXTdqHolbyJyCL4MyhefLjnyduXW2kXPludmKURSsME1brpe4kJMqoMZwJHbivVmFA2oD1sWpQ0Qh1kk1FH5Mg6HdKNlX3SkIn7uyOjkdbDKLSVETV9PZ+Nzf+yZmq6Z0HGZZIalGz6UTcVxMRkvDfpcIXMiKEFyhS3sxLWp4oyY6/j2iP48ysvQu2k5Hsl/8Yvli9hqjwcwCEcgw+nUIZrqEAVGPTgAZ7g2RHOo/PivE5Lc86sZx/+yHn/Ab66kRU=</latexit><latexit sha1_base64="GWRCYrUuf4tRLwmEljXBNHCMHTs=">AAAB6nicbZC7SgNBFIbPxltcb1FLm8EgWIVdG23EoI1lRHOBZAmzk5NkyOzsMjMrhCWPYGOhiKW+i72N+DZOLoUm/jDw8f/nMOecMBFcG8/7dnJLyyura/l1d2Nza3unsLtX03GqGFZZLGLVCKlGwSVWDTcCG4lCGoUC6+HgapzX71FpHss7M0wwiGhP8i5n1FjrtiXTdqHolbyJyCL4MyhefLjnyduXW2kXPludmKURSsME1brpe4kJMqoMZwJHbivVmFA2oD1sWpQ0Qh1kk1FH5Mg6HdKNlX3SkIn7uyOjkdbDKLSVETV9PZ+Nzf+yZmq6Z0HGZZIalGz6UTcVxMRkvDfpcIXMiKEFyhS3sxLWp4oyY6/j2iP48ysvQu2k5Hsl/8Yvli9hqjwcwCEcgw+nUIZrqEAVGPTgAZ7g2RHOo/PivE5Lc86sZx/+yHn/Ab66kRU=</latexit><latexit sha1_base64="U7EZbS6a8V4gnG4KkgSjlFXrLVM=">AAAB6nicbVA9TwJBEJ3DL8Qv1NJmIzGxInc2WhJtLDEKksCF7C17sGFv77I7a0Iu/AQbC42x9RfZ+W9c4AoFXzLJy3szmZkXZVIY9P1vr7S2vrG5Vd6u7Ozu7R9UD4/aJrWa8RZLZao7ETVcCsVbKFDyTqY5TSLJH6Pxzcx/fOLaiFQ94CTjYUKHSsSCUXTSfU/ZfrXm1/05yCoJClKDAs1+9as3SJlNuEImqTHdwM8wzKlGwSSfVnrW8IyyMR3yrqOKJtyE+fzUKTlzyoDEqXalkMzV3xM5TYyZJJHrTCiOzLI3E//zuhbjqzAXKrPIFVssiq0kmJLZ32QgNGcoJ45QpoW7lbAR1ZShS6fiQgiWX14l7Yt64NeDu6DWuC7iKMMJnMI5BHAJDbiFJrSAwRCe4RXePOm9eO/ex6K15BUzx/AH3ucPXfON1A==</latexit>
47. What’s next?
• Benchmarking on data-intensive (and not only) scenarios
• Interfacing DAPHNE with concrete languages
• Augment the state-space construction with native temporal
Model Checking capabilities
• DAPHNE generates logs with all performed actions and data
changes —> investigate possible applications of logs to:
• business auditing in small- and average-sized companies
• (multi-perspective) process mining
49. PostDoc and PhD Positions
at KRDB Research Centre in Bolzano
This year we are starting 5 new projects involving OBDA / VKGs
• EU Project INODE on data management infrastructures (3 years)
• Italian basic research project HOPE on open data publishing (3 years)
• CHIST-ERA EU Project PACMEL on OBDA for process mining (2 years)
• ESF Project IDEE on data integration in the energy sector (3 years)
• Industrial project on temporal OBDA (9 months)
We are hiring 5-6 new postdocs on these projects
We are also opening several 4-year PhD positions with bursary
For more info, CONTACT ASAP diego.calvanese@unibz.it
