Definitions

Worktop/ Web UI

The DEM specific help in Worktop/ Web UI is only available online.

To access this help, refer to help menu in Worktop/ Web UI; you can search on DEM.

Language Codes

The languages are divided into three categories, A, B and C.

Language codes
A Code	Language	B Code	Language	C Code	Language
2	US English	4	French	a	Arabic
1	Dutch	5	Spanish	b	Bulgarian
3	German	6	Italian	c	Catalan
j	Japanese	7	Danish	d	Polish
		8	Norwegian	e	Elladi (Greek)
		9	Swedish	E	Estonian
		P	Portuguese (European)	h	Hebrew
		p	Portuguese (Brazilian)	H	Hrvatski (Croat)
		f	Finnish	L	Latvian
		n	Chinese Traditional	m	Magyar (Hungarian)
		o	Chinese Simplified	q	Canadian French
		k	Korean	r	Romanian
				R	Russian
				S	Slovenian
				t	Czech
				T	Turkish
				v	Lithuanian

Petri-nets modeling conventions

Process modeling with Petri nets is based on the principles explained below:

An activity is enabled when there is at least one token in all connected input states of the activity.
An activity consumes one token from every input state, and produces one token to every connected output state.
Control activities are dedicated for the routing of tokens and have special capabilities.
Typically, control activities behave like normal activities regarding token consumption and production.
The actual behavior of control activities is fully determined by assigning static conditions to the input and output transitions with states. Static conditions refer to an implementation decision. Dynamic conditions refer to a run-time decision moment. The static condition overrules the dynamic condition because the static condition enables/disables paths in the business process. Dynamic conditions determine the path through the business process.
There can be more than two incoming or outgoing transitions.

The control structures

The R1 and R2 references used in the following texts refer to dynamic conditions.

AND split

The control activity will unconditionally consume one token and produce two tokens, with one for each output state.

OR/XOR split

The control activity will consume one token and produce one or two tokens, with one for each output state at the most, depending on the actual dynamic condition values of R1 and R2.

If R1 and R2 exclude each other, the construction is an exclusive OR, called XOR (R1 or R2, but not both). Otherwise, the construction is an OR (R1 or R2, or both).

AND join

If all input states contain at least one token, the control activity is enabled. The control activity will unconditionally consume the two tokens and produce one token.

OR/XOR join

Depending on the actual condition values of R1 and R2, the control activity will consume one or two tokens and produce one token. If R1 and R2 exclude each other, the construction is an exclusive OR (R1 or R2, but not both). Otherwise, the construction is an OR (R1 or R2, or both).

Logically applying these control structure principles will result in the following basic building blocks. Each process can be modeled with these building blocks, and using these blocks guarantees the correct syntax.

The Petri-net building blocks

AND: activities executed in parallel (mandatory)

The sequence in which B and C are executed is not important.

OR: activities executed in parallel (optional)

The first control activity has a variable number of output states, determined by the conditions R1 and R2. The second control activity has a variable number of input states, determined by the same conditions R1 and R2.

XOR: specialized activities

Based on the conditions R1 and R2, activity B or C is selected (not both, hence an exclusive OR). An OR join is represented by a single output state at the end of the process.

Iteration of activities

The execution of activity B, one or more times. The number of iterations is set.