| # 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. |