Faster Or-join Enactment for BPMN 2.0

Transcription

1 Faster Or-join Enactment for BPMN 2.0 Hagen Völzer, IBM Research Zurich Joint work with Beat Gfeller and Gunnar Wilmsmann

2 Contribution: BPMN Diagram Enactment Or-join Tokens define the control state Execution (or simulation) engine needs to determine, for any given control state, what flow elements (activities, gateways, etc.) are enabled Determining enabledness of Or-joins is relatively difficult (compared to other flow elements) Linear time per Or-join for each change of control-state This can be a problem for high-performance execution and simulation We improve that to essentially constant time 2

3 Outline The Or-Join Enactment Problem BPMN 2.0 Or-join semantics Analysis of the current enactment algorithm A New Solution 3

4 Or-Join for Closing Or-Splits (1/3) Or-split provides conditional concurrent branching Any non-empty subset of the available branches may be selected Or-join cannot be enabled before at least one token has arrived 4

5 Or-Join for Closing Or-Splits (2/3) Filled slot of the join Empty slot of the join Red path from token to empty slot indicates that join must wait Or-join should synchronize the active branches (i.e. tokens produced by split) Join should wait for Book car to complete but not for Book flight The semantics is non-local Enabling depends on tokens that are not at the join 5

6 Or-Join for Closing Or-Splits (3/3) Splits and joins may not be exactly paired Synchronize tokens that were produced upstream of the Or-join Again: existence of a path from a token to an empty slot determines waiting 6

7 Or-Join for Closing a Combination of And- and Xor-Splits Similar to Or-splits Synchronize tokens that were produced upstream 7

8 A Cyclic Diagram (1/2) How does this diagram behave? 8

9 A Cyclic Diagram (2/2) In cyclic diagrams, it gets more complicated Meaning of upstream gets problematic The existence of a path from a token to an empty slot is not sufficient To characterize waiting for an Or-join Otherwise j waits for h and h waits for j We want h to execute first in this example 9

10 BPMN 2.0 Semantics: Enabledness of j Starting from filled slots of j Color all backward-reachable edges in blue, stop at j Computes the area that does not need to be searched for tokens Intuition: The slots there are satisfied already Starting from empty slots of j All backward-reachable edges in red, stop at j or any blue edge Computes the area that needs to be searched for tokens If there is a token on a red edge, j needs to wait Otherwise j is enabled 10

11 BPMN 2.0 Semantics: Enabledness of h Or-join h is enabled here (So, indeed h executes first) Search takes linear time in the number of edges Search needs to be repeated upon each state change (anywhere in the graph)! This can be a problem for high-performance execution and simulation 11

12 Outline The Or-Join Enactment Problem A New Solution Main idea Runtime analysis Limitations Further Optimization 12

13 Solution Overview Introduce and maintain data structure for each Or-join Keeps track of the tokens that the Join may need to wait for Update data structure upon each state change Maintain an explicit flag whether Join is enabled 13

14 Preprocessing Enumerate incoming slots of j by j1, j2, Label each edge of the graph with set of slots that can be reached from this edge without going through j The full set {j1,j2,j3} and the empty set { } can be omitted 14

15 New Solution Allocate a counter X L for each distinct label L = { } X L counts the number of tokens that reside at edges labeled with L Incremented whenever such an edge gets a token, decremented whenever such an edge loses a token Counter X L is ignored whenever L contains a filled slot Or-join j is enabled whenever all non-ignored counters are zero 15

16 Correctness If edge e is blue, e has a path to a filled slot j k j k is in label L of e corresponding counter X L is ignored and vice versa If red edge e with Label L = { } has a token, value of counter X L is non-zero counter X L is not ignored (because e is not blue) Enabled flag is false and vice versa 16

17 Analysis Preprocessing: linear in the number of edges: once per process model Initialization of counters: linear in the number of edges: once per process instance Update of the counters: (only for gateway execution): linear in the degree of the gateway If a token is added to an incoming slot, update ignored values (linear in edges) If the Or-join executes, ignored values need to be updated as well The latter two cases can be considered seldom (see paper) Effort of enacting state change is essentially the same whereas checking enabledness gets reduced from linear to constant time 17

18 Limitation Cost of allocation of data structure and its maintenance is for each separate Or-join in the diagram If there are many Or-joins in a diagram, further optimization may pay off 18

19 Further Optimizations Start tracking only when first token arrives at Or-join Decompose diagram into SESE fragments Use Dead Path Elimination for Or-joins inside acyclic fragments Don t track tokens inside a subfragment in the scope of the Or-join 19

20 Conclusion Naïve BPMN 2.0 Or-join enactment requires a linear search in the graph upon each state change This can be optimized to essentially constant time cost per update Further room for improvement when there are many Or-joins per process Experimental validation desirable, e.g. in simulation engine 20