Browse Prior Art Database

A Token-based BPMN Process Execution Method for Inclusive Or-Joins

IP.com Disclosure Number: IPCOM000200680D
Publication Date: 2010-Oct-25
Document File: 2 page(s) / 40K

Publishing Venue

The IP.com Prior Art Database

Abstract

This article provides a method to determine whether an inclusive Or-join gateway is activated or not at any step during a BPMN (Business Process Model and Notation) process execution (or simulation). This method conforms with the semantics of the inclusive Or-join as defined in BPMN 2.0.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 01 of 2

A Token-based BPMN Process Execution Method for Inclusive Or -Joins

Disclosed is a token based BPMN process execution approach for inclusive Or-

j

                                                  oins, which uses several counters to compute the enabledness of an inclusive Or-

j

oin

oin) gateway.

Definition of the counters:

The basic idea is to use several counters for each Ior-

join. Each counter keeps track

of the number of tokens present in certain parts of the process. The counters are defined by labels on the edges, which are defined as follows.

Consider an Ior-

join

(Ior-

j

              , with inputs a1, a2, ..., ak. Each edge of the graph is labled by the set of inputs of A that can be reached from this edge without first going through
A. A counter is kept for every distinct label that appears on an edge (note that several edges may have the same label: in this case, they all refer to one common counter). Each counter CS, representing a subset S of A's inputs, stores the number of tokens in the current state which can still reach each of the inputs in S. Note that the number of counters required for an Ior-

join is bounded by the number of edges in

the process model.

When an Ior-

join is activated

:

A

By definition, an Ior-

join is activated if a token has arrived at least at one of its inputs,

and there is no other token for which it must wait. The latter condition can be checked by looking at the counters: A counter CS, representing a subset S of A's inputs, can be ignored if one of the inputs in S is already active, i.e., has a token, (because they represent tokens for which the join must not wait). The Ior-

join is

activated as soon as all of the counters which cannot be ignored are 0.

How to update the counters when tokens move:

Updating the counters is very simple: when a token is deleted from an edge, the corresponding counter is decreased by 1. When a token is added to an edge, the corresponding counter is increased by 1.

In addition, if a token arrives at an input of the Ior-

join, all counters which contain this

input (in their representative set) must be ignored, until the Ior-

join fires. To quickly

decide whether the Ior-

join is activated, the number of non-ignored counters which

are non-zero is tracked. After an Ior-

j

oin was triggered (executed), all counters

become non-ignored again.

Optimization options:

I. The counter which represents the set of all inputs of an Ior-

join does not need to

be tracked, because it will never be relevant (it would al...