- 
+ 
@@ -71,52 +71,52 @@ The elements marked in orang
- 
+ 
- 
+ 
@@ -394,26 +394,26 @@ chapter of the [BPMN Modeling Reference](http://operaton.org/bpmn/reference.html
- 
+ 
- 
+ 
@@ -423,61 +423,61 @@ chapter of the [BPMN Modeling Reference](http://operaton.org/bpmn/reference.html
- 
+ 
- 
+ 
4. A user manually starts Task A by calling `caseService.manuallyStartCaseExecution(taskAExecutionId);`. As a consequence, Task A reaches state `ACTIVE` and a task instance is added to the assignee's task list. Note that starting a task is only allowed if that task is in state `ENABLED`. Thus, trying to manually start Task B here by `caseService.manuallyStartCaseExecution(taskBExecutionId);` would fail. The state is now:
5. The assignee completes the task instance by calling `taskService.complete(taskId);`. Task A reaches the state `COMPLETED`.
6. Task A's state transition triggers Task B's sentry. In consequence, Task B becomes `ENABLED`. This happens synchronously in the invocation from step 5. Accordingly, the case's new state is:
7. Similar to Task A, a user may now use the `CaseService` and `TaskService` to start Task B, complete the corresponding task instance, and complete Task B. Ultimately, Task B reaches the state `COMPLETED`.
8. With both tasks in state `COMPLETED`, the case instance automatically reaches the state `COMPLETED` as well. The state has case has reached the following state:
9. A user may close the case instance by invoking `caseService.closeCaseInstance(caseInstanceId);`. The case instance reaches the state `CLOSED`.
@@ -65,7 +65,7 @@ Note that a `CaseExecution` object corresponds to a plan item, here the plan ite
*Case instance* refers to an instance of the case plan model. More specific, it is an instance of the single top-level stage in a case definition. The lifecycle of a case instance is the following:
-
+
States:
@@ -112,7 +112,7 @@ States:
The lifecycle of a task or stage plan item is the following:
-
+
States:
@@ -175,7 +175,7 @@ States:
The lifecycle of a milestone plan item is the following:
-
+
States
diff --git a/docs/documentation/reference/cmmn11/markers/img/repetition-on-completion/repetition-rule-example.png b/docs/documentation/reference/cmmn11/markers/img/repetition-on-completion/repetition-rule-example.png
deleted file mode 100644
index b927782..0000000
Binary files a/docs/documentation/reference/cmmn11/markers/img/repetition-on-completion/repetition-rule-example.png and /dev/null differ
diff --git a/docs/documentation/reference/cmmn11/markers/img/repetition-on-completion/state-1.png b/docs/documentation/reference/cmmn11/markers/img/repetition-on-completion/state-1.png
deleted file mode 100644
index fe1f00b..0000000
Binary files a/docs/documentation/reference/cmmn11/markers/img/repetition-on-completion/state-1.png and /dev/null differ
diff --git a/docs/documentation/reference/cmmn11/markers/img/repetition-on-completion/state-2.png b/docs/documentation/reference/cmmn11/markers/img/repetition-on-completion/state-2.png
deleted file mode 100644
index 503d10d..0000000
Binary files a/docs/documentation/reference/cmmn11/markers/img/repetition-on-completion/state-2.png and /dev/null differ
diff --git a/docs/documentation/reference/cmmn11/markers/img/repetition-on-completion/state-3.png b/docs/documentation/reference/cmmn11/markers/img/repetition-on-completion/state-3.png
deleted file mode 100644
index ce54390..0000000
Binary files a/docs/documentation/reference/cmmn11/markers/img/repetition-on-completion/state-3.png and /dev/null differ
diff --git a/docs/documentation/reference/cmmn11/markers/img/repetition-on-completion/state-4.png b/docs/documentation/reference/cmmn11/markers/img/repetition-on-completion/state-4.png
deleted file mode 100644
index c5be66e..0000000
Binary files a/docs/documentation/reference/cmmn11/markers/img/repetition-on-completion/state-4.png and /dev/null differ
diff --git a/docs/documentation/reference/cmmn11/markers/repetition-rule.md b/docs/documentation/reference/cmmn11/markers/repetition-rule.md
index 216f03d..32a8983 100644
--- a/docs/documentation/reference/cmmn11/markers/repetition-rule.md
+++ b/docs/documentation/reference/cmmn11/markers/repetition-rule.md
@@ -60,7 +60,7 @@ It is not advisable to define a repetition rule without entry criteria on a mile
Consider the following excerpt of a CMMN case definition:
-
+
The corresponding XML representation could look like this:
@@ -91,15 +91,15 @@ In our example, the following steps might take place:
1. A user instantiates the case and sets the variable `score` to the value `10`.
2. An instance *A* for the human task is created. The instance *A* transitions into state `ENABLED`.
-
+
3. A user manually starts task *A* and the instance reaches the state `ACTIVE`.
4. A user completes task *A*. During the transition into state `COMPLETED`, the repetition rule is evaluated. As a consequence that the variable `score` is less than `50`, a new instance `A'` of the corresponding task is created. The new instance moves into state `ENABLED`.
-
+
5. Once again, a user manually starts and completes task *A'*. Since the variable `score` is still less than `50`, the repetition rule evaluates to `true` when *A'* transitions into state `COMPLETED`. As a result, a new instance *A''* is created.
-
+
6. A user changes the value of the variable `score` to `55`.
7. A user manually starts and completes task *A''* and the instance reaches the state `COMPLETED`. Since the variable `score` has been set to `55` the repetition rule evaluates to `false` and a new instance is not created.
-
+
8. From now on, no more repetitions of *A* can occur.
The transition in which the repetition rule is evaluated can be changed by a Operaton extension attribute named `operaton:repeatOnStandardEvent`. For a task it looks as follows:
@@ -133,7 +133,7 @@ A trigger for a repetition of a milestone, stage or task is a satisfied [sentry]
Consider the following excerpt of a CMMN case definition, where the repetition of the tasks depends on the occurrence of an entry criterion:
-
+
The corresponding XML representation could look like this:
@@ -181,18 +181,18 @@ In our example, the following steps might take place:
1. A user instantiates the case and sets the variable `score` to the value `10`.
2. Two instances for each human task are automatically created and both transition in state `AVAILABLE`.
-
+
1. When the entry criterion (*Sentry_1*) of instance *B* is satisfied, the task *B* reaches the state `ENABLED`. During the transition to the state `ENABLED`, the repetition rule is evaluated. As a consequence that the variable `score` is less than `50`, a new instance *B'* of the corresponding task is created. The instance *B'* moves into state `AVAILABLE`.
-
+
1. A user manually starts and completes task *B* and the instance reaches the state `COMPLETED`.
2. The completion of instance *B* satisfies the entry criterion (*Sentry_2*) of *A*. In consequence, task *A* becomes `ENABLED` and a new instance *A'* is created, because the evaluation of the repetition rule during the transition returns `true`.
-
+
1. A user changes the value of the variable `score` to `55`.
2. The entry criterion (*Sentry_1*) of instance *B'* is satisfied (once again). The instance *B'* reaches the state `ENABLED`. As a consequence that the variable `score` has been set to `55`, the repetition rule evaluates to `false`. So, a new instance is not created.
-
+
1. A user manually starts and completes task *B'* and the instance reaches the state `COMPLETED`.
2. The completion of instance *B'* satisfies the entry criterion (*Sentry_2*) of *A'*. So that *A'* becomes `ENABLED` and a new instance of the corresponding task is not created, because the repetition rule evaluates to `false`.
-
+
1. From now on, no more repetitions of *A* or *B* can occur.
diff --git a/docs/documentation/reference/cmmn11/sentry.md b/docs/documentation/reference/cmmn11/sentry.md
index 18dba68..2dcbcd6 100644
--- a/docs/documentation/reference/cmmn11/sentry.md
+++ b/docs/documentation/reference/cmmn11/sentry.md
@@ -118,7 +118,7 @@ Variable event that occurs in the scope of the execution triggers the sentry wit
Consider the below example in which there are two human tasks. `HumanTask1` is defined inside the case model and the `HumanTask_2` is defined inside the stage.
Each human task is attached with a entry criterion sentry and both the sentries are evaluated when the update event for the variable `foo` occurs.
-
+
Scenario 1:
diff --git a/docs/documentation/reference/dmn/decision-literal-expression/img/decision-id.png b/docs/documentation/reference/dmn/decision-literal-expression/img/decision-id.png
deleted file mode 100644
index a651528..0000000
Binary files a/docs/documentation/reference/dmn/decision-literal-expression/img/decision-id.png and /dev/null differ
diff --git a/docs/documentation/reference/dmn/decision-literal-expression/img/decision-literal-expression.dmn b/docs/documentation/reference/dmn/decision-literal-expression/img/decision-literal-expression.dmn
deleted file mode 100644
index ccf1c6d..0000000
--- a/docs/documentation/reference/dmn/decision-literal-expression/img/decision-literal-expression.dmn
+++ /dev/null
@@ -1,11 +0,0 @@
-
-
-
-
-
-
-
- calendar.getSeason(date)
-
-
-
diff --git a/docs/documentation/reference/dmn/decision-literal-expression/img/decision-literal-expression.png b/docs/documentation/reference/dmn/decision-literal-expression/img/decision-literal-expression.png
deleted file mode 100644
index 15075dd..0000000
Binary files a/docs/documentation/reference/dmn/decision-literal-expression/img/decision-literal-expression.png and /dev/null differ
diff --git a/docs/documentation/reference/dmn/decision-literal-expression/img/decision-name.png b/docs/documentation/reference/dmn/decision-literal-expression/img/decision-name.png
deleted file mode 100644
index e3e2848..0000000
Binary files a/docs/documentation/reference/dmn/decision-literal-expression/img/decision-name.png and /dev/null differ
diff --git a/docs/documentation/reference/dmn/decision-table/hit-policy.md b/docs/documentation/reference/dmn/decision-table/hit-policy.md
index 0b510bf..b9898b6 100644
--- a/docs/documentation/reference/dmn/decision-table/hit-policy.md
+++ b/docs/documentation/reference/dmn/decision-table/hit-policy.md
@@ -13,7 +13,7 @@ menu:
aliases: [reference/dmn/decision-table/hit-policy/]
---
-
+
A decision table has a hit policy that specifies what the
results of the evaluation of a decision table consist of.
@@ -77,7 +77,7 @@ output entries of the satisfied rule.
If more than one rule is satisfied, the Unique hit policy is violated.
See the following decision table.
-Hit Policy Unique" class="no-lightbox
+Hit Policy Unique" class="no-lightbox
Depending on the current season the dish should be chosen.
Only one dish can be chosen, since only one season can exist at the same time.
@@ -91,7 +91,7 @@ If multiple rules are satisfied which generate different outputs, the hit policy
is violated.
See the following example:
-Hit Policy Any" class="no-lightbox
+Hit Policy Any" class="no-lightbox
This is a decision table for the leave application. If the applier
has no vacation days left or is currently in the probation period, the application will be refused.
Otherwise the application is applied.
@@ -101,7 +101,7 @@ Otherwise the application is applied.
Multiple rules can be satisfied. The decision table result contains only
the output of the first satisfied rule.
-Hit Policy First" class="no-lightbox
+Hit Policy First" class="no-lightbox
See the above decistion table for advertisement. Regarding the current age of the user, which
advertisement should be shown is decided. For example, the user is 19 years old. All the rules will match, but since
the hit policy is set to first only, the advertisement for Cars is used.
@@ -111,7 +111,7 @@ the hit policy is set to first only, the advertisement for Cars is used.
Multiple rules can be satisfied. The decision table result contains the output
of all satisfied rules in the order of the rules in the decision table.
-Hit Policy Rule Order" class="no-lightbox
+Hit Policy Rule Order" class="no-lightbox
Again, see the advertisement example with the rule order policy. Say we have a user at the age of 19 again.
All rules are satisfied so all outputs are given, ordered by the rule ordering.
It can perhaps be used to indicate the priority of the displayed advertisements.
@@ -121,7 +121,7 @@ It can perhaps be used to indicate the priority of the displayed advertisements.
Multiple rules can be satisfied. The decision table result contains the output
of all satisfied rules in an arbitrary order as a list.
-Hit Policy Collect" class="no-lightbox
+Hit Policy Collect" class="no-lightbox
With this hit policy, the output list has no ordering. So the advertisement will be arbitrary
if, for example, the age is 19.
@@ -175,21 +175,21 @@ the Operaton DMN engine:
#### SUM aggregator
The SUM aggregator sums up all outputs from the satisfied rules.
-Hit Policy Collect SUM" class="no-lightbox
+Hit Policy Collect SUM" class="no-lightbox
The showed decision table can be used to sum up the salary bonus for an employee. For example, the employee has been working in the company for
3.5 years. So the first, second and third rule will match and the result of the decision table is 600, since the output is summed up.
#### MIN aggregator
The MIN aggregator can be used to return the smallest output value of all satisfied rules.
See the following example of a car insurance. After years without a car crash the insurance fee will be reduced.
-Hit Policy Collect MIN" class="no-lightbox
+Hit Policy Collect MIN" class="no-lightbox
For example, if the input for the decision table is 3.5 years, the result will be 98.83, since the first three rules match
but the third rule has the minimal output.
#### MAX aggregator
The MAX aggregator can be used to return the largest output value of all satisfied rules.
-Hit Policy Collect MAX" class="no-lightbox
+Hit Policy Collect MAX" class="no-lightbox
This decision table represents the decision for the amount of pocket money for a child.
Depending of the age, the amount grows. For example, an input of 9 will satisfy the first and second rules.
@@ -199,7 +199,7 @@ will be 5. A child at the age of 9 will get 5 as pocket money.
#### COUNT aggregator
The COUNT aggregator can be use to return the count of satisfied rules.
-Hit Policy Collect COUNT" class="no-lightbox
+Hit Policy Collect COUNT" class="no-lightbox
For example, see the salary bonus decision table again, this time with the COUNT aggregator.
With an input of 4, the first three rules will be satisfied. Therefore, the result from the decision table will be 3, which means
diff --git a/docs/documentation/reference/dmn/decision-table/img/dish-table.svg b/docs/documentation/reference/dmn/decision-table/img/dish-table.svg
deleted file mode 100644
index 6ed669a..0000000
--- a/docs/documentation/reference/dmn/decision-table/img/dish-table.svg
+++ /dev/null
@@ -1,1176 +0,0 @@
-
-
-
-
diff --git a/docs/documentation/reference/dmn/decision-table/img/map.js b/docs/documentation/reference/dmn/decision-table/img/map.js
deleted file mode 100644
index 9f0945e..0000000
--- a/docs/documentation/reference/dmn/decision-table/img/map.js
+++ /dev/null
@@ -1,169 +0,0 @@
-/* Use this as helper to determine the overlay % / regions
-const img = document.querySelector(".no-lightbox img");
-
-function offset(element) {
- const rect = element.getBoundingClientRect(),
- const left = window.pageXOffset || document.documentElement.scrollLeft,
- const top = window.pageYOffset || document.documentElement.scrollTop;
- return { top: rect.top + top, left: rect.left + left }
-}
-
-img.addEventListener("click", (e) => {
- console.log(`top: ```${(e.pageY - offset(img).top) / img.height * 100}`);
- console.log(`left: ```${(e.pageX - offset(img).left) / img.width * 100}`);
-}); */
-
-
-(function () {
-'use strict';
-var keys = Object.keys;
-
-function eachKeys(obj, ite) {
- keys(obj).forEach(function (key) {
- ite(key, obj[key]);
- });
-}
-
-function query(sel, ctx) {
- ctx = ctx || document;
- return ctx.querySelector(sel);
-}
-
-function mkEl(tagName, attrs) {
- attrs = attrs || {};
- var el = document.createElement(tagName);
- eachKeys(attrs, function (key, val) {
- el.setAttribute(key, val);
- });
- return el;
-}
-
-var regions = {
- name: {
- title: 'Decision Name',
- href: '#decision-name',
- coords: [
- {
- top: 0,
- left: 0.5,
- width: 13.5,
- height: 5.5
- },
- {
- top: 7,
- left: 0.7,
- width: 12,
- height: 14.5
- }
- ]
- },
-
- hitPolicy: {
- title: 'Hit policy',
- href: 'hit-policy/',
- coords: [
- {
- top: 3.6,
- left: 19,
- width: 8,
- height: 5
- },
- {
- top: 10,
- left: 13,
- width: 20,
- height: 9.5
- }
- ]
- },
-
- rule: {
- title: 'Rule',
- href: 'rule',
- coords: [
- {
- top: 95,
- left: 30,
- width: 4,
- height: 5.5
- },
- {
- top: 52,
- left: 0,
- width: 100,
- height: 7.5
- }
- ]
- },
-
- conditions: {
- title: 'Input Entry (Condition)',
- href: 'rule/#input-entry-condition',
- coords: [
- {
- top: 95,
- left: 6,
- width: 20.5,
- height: 5.5
- },
- {
- top: 65,
- left: 6,
- width: 18,
- height: 7.5
- }
- ]
- },
-
- conclusions: {
- title: 'Output Entry (Conclusion)',
- href: 'rule/#output-entry-conclusion',
- coords: [
- {
- top: 95,
- left: 41.5,
- width: 23,
- height: 5.5
- },
- {
- top: 66,
- left: 43,
- width: 19.0,
- height: 6.5
- }
- ]
- }
-};
-
-var fig = query('figure.no-lightbox');
-var img = query('img', fig);
-
-var wrapper = mkEl('div', {
- style: 'transition:all 0.218s linear;position:absolute;' +
- 'top:0;left:0;' +
- 'width:100%;' +
- 'height:100%;'
-});
-
-var holder = img.parentNode;
-holder.appendChild(wrapper);
-holder.style.position = 'relative';
-
-keys(regions).forEach(function (name) {
- regions[name].coords.forEach(function (coords/*, c*/) {
- var el = mkEl('a', {
- href: regions[name].href,
- title: regions[name].title,
- style: 'position:absolute;' +
- 'display:block;' +
- // 'background-color:rgba('+ (c ? '0,122' : '122,0') +',0,0.5);' +
- 'cursor:pointer;' +
- 'top:' + coords.top + '%;' +
- 'left:' + coords.left + '%;' +
- 'width:' + coords.width + '%;' +
- 'height:' + coords.height + '%;'
- });
- wrapper.appendChild(el);
- });
-});
-})();
diff --git a/docs/documentation/reference/dmn/decision-table/index.md b/docs/documentation/reference/dmn/decision-table/index.md
index 6bef45d..28ac37a 100644
--- a/docs/documentation/reference/dmn/decision-table/index.md
+++ b/docs/documentation/reference/dmn/decision-table/index.md
@@ -5,7 +5,7 @@ sidebar_position: 10
---
-
+
A decision table represents decision logic which can be depicted as a table in
@@ -26,7 +26,7 @@ A decision table is represented by a `decisionTable` element inside a
## Decision Name
-
+
The name describes the decision for which the decision table provides the
decision logic. It is set as the `name` attribute on the `decision` element.
@@ -43,7 +43,7 @@ It can be changed via the Properties Panel after selecting the respective
## Decision Id
-
+
The id is the technical identifier of the decision. It is set in the `id`
attribute on the `decision` element.
diff --git a/docs/documentation/reference/dmn/decision-table/input.md b/docs/documentation/reference/dmn/decision-table/input.md
index 2523d70..cfcecbe 100644
--- a/docs/documentation/reference/dmn/decision-table/input.md
+++ b/docs/documentation/reference/dmn/decision-table/input.md
@@ -13,7 +13,7 @@ menu:
aliases: [reference/dmn/decision-table/input/]
---
-
+
A decision table can have one or more inputs, also called input clauses. An
input clause defines the id, label, expression and type of a decision table
@@ -57,7 +57,7 @@ the `id` attribute of the `input` XML element.
## Input Label
-Input Label" class="no-lightbox
+Input Label" class="no-lightbox
An input label is a short description of the input. It is set on the `input`
XML element in the `label` attribute. Note that the label is not required but
@@ -73,7 +73,7 @@ recommended, since it helps to understand the decision.
## Input Expression
-Input Expression" class="no-lightbox
+Input Expression" class="no-lightbox
An input expression specifies how the value of the input clause is generated.
It is an expression which will be evaluated by the DMN engine. It is usually
@@ -91,7 +91,7 @@ expression is set inside a `text` element that is a child of the
## Input Type Definition
-Input Type Definition" class="no-lightbox
+Input Type Definition" class="no-lightbox
The type of the input clause can be specified by the `typeRef` attribute on the
`inputExpression` XML element. After the input expression is evaluated by the
diff --git a/docs/documentation/reference/dmn/decision-table/output.md b/docs/documentation/reference/dmn/decision-table/output.md
index 35c132c..5629733 100644
--- a/docs/documentation/reference/dmn/decision-table/output.md
+++ b/docs/documentation/reference/dmn/decision-table/output.md
@@ -13,7 +13,7 @@ menu:
aliases: [reference/dmn/decision-table/output/]
---
-Output" class="no-lightbox
+Output" class="no-lightbox
A decision table can have one or more outputs, also called output clauses. An
output clause defines the id, label, name and type of a decision table output.
@@ -47,7 +47,7 @@ set as the `id` attribute of the `output` XML element.
## Output Label
-Output Label" class="no-lightbox
+Output Label" class="no-lightbox
An output label is a short description of the output. It is set on the `output`
XML element in the `label` attribute. Note that the label is not required but
@@ -59,7 +59,7 @@ recommended, since it helps to understand the decision.
## Output Name
-Output Name" class="no-lightbox
+Output Name" class="no-lightbox
The name of the output is used to reference the value of the output in the
[decision table result]. It is specified by the `name` attribute on the
@@ -74,7 +74,7 @@ unique name.
## Output Type Definition
-Output Type Definition" class="no-lightbox
+Output Type Definition" class="no-lightbox
The type of the output clause can be specified by the `typeRef` attribute on the
`output` XML element. After an [output entry] is evaluated by the
diff --git a/docs/documentation/reference/dmn/decision-table/rule.md b/docs/documentation/reference/dmn/decision-table/rule.md
index adb6bf3..9882b01 100644
--- a/docs/documentation/reference/dmn/decision-table/rule.md
+++ b/docs/documentation/reference/dmn/decision-table/rule.md
@@ -13,7 +13,7 @@ menu:
aliases: [reference/dmn/decision-table/rule/]
---
-Rule" class="no-lightbox
+Rule" class="no-lightbox
A decision table can have one or more rules. Each rule contains input and
output entries. The input entries are the condition and the output entries the
@@ -48,7 +48,7 @@ A rule is represented by a `rule` element inside a `decisionTable` XML element.
## Input Entry (Condition)
-Input Entry" class="no-lightbox
+Input Entry" class="no-lightbox
A rule can have one or more input entries, which are the conditions of the rule.
Each input entry contains an expression in a `text` element as child of an
@@ -96,7 +96,7 @@ languages.
## Output Entry (Conclusion)
-Output Entry" class="no-lightbox
+Output Entry" class="no-lightbox
A rule can have one or more output entries, which are the conclusions of the
rule. Each output entry contains an expression in a `text` element as child of
@@ -173,7 +173,7 @@ will be determined with precedence of the empty input outcome.
## Description
-Description" class="no-lightbox
+Description" class="no-lightbox
A rule can be annotated with a description that provides additional
information. The description text is set inside the `description` XML element.
diff --git a/docs/documentation/reference/dmn/drg/img/drg.dmn b/docs/documentation/reference/dmn/drg/img/drg.dmn
deleted file mode 100644
index d64da3b..0000000
--- a/docs/documentation/reference/dmn/drg/img/drg.dmn
+++ /dev/null
@@ -1,74 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/documentation/reference/dmn/drg/index.md b/docs/documentation/reference/dmn/drg/index.md
index debd75e..d4d3727 100644
--- a/docs/documentation/reference/dmn/drg/index.md
+++ b/docs/documentation/reference/dmn/drg/index.md
@@ -5,7 +5,7 @@ sidebar_position: 30
---
-
+
A Decision Requirements Graph (DRG) models a domain of decision-making, showing the most important elements involved in it and the dependencies
between them. The elements modeled are [decisions], [input data], and [knowledge sources].
@@ -27,7 +27,7 @@ In the XML a DRG is represented by the `definitions` element.
## Decision Requirements Graph Name
-
+
The name describes the DRG. It is set as the `name` attribute on the `definitions` element.
@@ -42,7 +42,7 @@ The name describes the DRG. It is set as the `name` attribute on the `definition
## Decision Requirements Graph Id
-
+
The id is the technical identifier of the DRG. It is set in the `id` attribute on the `definitions` element.
@@ -61,7 +61,7 @@ The engine uses the id as the decision requirements definition key of the deploy
## Decision
-
+
A decision requirements graph can have one or more decisions. A decision has a [name] which is shown in the DRD and an [id]. The decision logic inside the decision must be either a [decision table] or a [decision literal expression].
@@ -79,7 +79,7 @@ A decision is represented by a `decision` element inside the `definitions` XML e
### Required Decisions
-
+
A decision can have one or more required decisions which it depends on.
@@ -97,7 +97,7 @@ It has a `href` attribute and the value starts with `#` followed by the [decisio
## Input Data
-
+
An input data denotes information used as an input by one or more decisions.
@@ -119,7 +119,7 @@ Note that an input data has no execution semantics and is ignored by the Operato
## Knowledge Source
-
+
A knowledge source denotes an authority for a Decision.
diff --git a/docs/documentation/reference/dmn/feel/legacy/data-types.md b/docs/documentation/reference/dmn/feel/legacy/data-types.md
index aa2f4fd..4b47867 100644
--- a/docs/documentation/reference/dmn/feel/legacy/data-types.md
+++ b/docs/documentation/reference/dmn/feel/legacy/data-types.md
@@ -15,14 +15,14 @@ The Operaton DMN engine supports the following FEEL data types.
## String
-String" class="no-lightbox
+String" class="no-lightbox
FEEL supports Strings. They must be encapsulated in double quotes. They
support only the equal [comparison] operator.
## Numeric Types
-Integer" class="no-lightbox
+Integer" class="no-lightbox
FEEL supports numeric types like integer. In the Operaton DMN engine the
following numeric types are available:
@@ -35,14 +35,14 @@ Numeric types support all [comparison] operators and [ranges].
## Boolean
-Boolean" class="no-lightbox
+Boolean" class="no-lightbox
FEEL supports the boolean value `true` and `false`. The boolean type only
supports the equal [comparison] operator.
## Date
-Date" class="no-lightbox
+Date" class="no-lightbox
FEEL supports date types. In the Operaton DMN engine the following date types
are available:
diff --git a/docs/documentation/user-guide/dmn-engine/evaluate-decisions.md b/docs/documentation/user-guide/dmn-engine/evaluate-decisions.md
index 3a7b0bf..0978706 100644
--- a/docs/documentation/user-guide/dmn-engine/evaluate-decisions.md
+++ b/docs/documentation/user-guide/dmn-engine/evaluate-decisions.md
@@ -189,7 +189,7 @@ which contains only one entry. This entry represents the expression value and is
Assume the following example of making a decision to select a dish.
-Select Dish
+Select Dish
The decision table returns the `desiredDish` as the output.
@@ -253,11 +253,11 @@ If a decision has one or more [required decisions], then the required decisions
Assume the following example of making a decision to select beverages.
-Beverages Decision
+Beverages Decision
The following [decision requirements diagram] shows that the `Beverages` decision requires the `Dish` decision (from the previous example).
-Select beverages
+Select beverages
When the `Beverages` decision is evaluated then the DMN engine evaluates the `Dish` decision first.
diff --git a/docs/documentation/user-guide/ext-client/img/externalTaskCient.png b/docs/documentation/user-guide/ext-client/img/externalTaskCient.png
deleted file mode 100644
index 7c3cfd3..0000000
Binary files a/docs/documentation/user-guide/ext-client/img/externalTaskCient.png and /dev/null differ
diff --git a/docs/documentation/user-guide/model-api/bpmn-model-api/create-a-model.md b/docs/documentation/user-guide/model-api/bpmn-model-api/create-a-model.md
index 21d75b0..09b832a 100644
--- a/docs/documentation/user-guide/model-api/bpmn-model-api/create-a-model.md
+++ b/docs/documentation/user-guide/model-api/bpmn-model-api/create-a-model.md
@@ -91,7 +91,7 @@ Bpmn.writeModelToFile(file, modelInstance);
With the basic helper methods from above it is very easy and straightforward to create simple processes. First, create a
process with a start event, user task and an end event.
-Single User Task Example
+Single User Task Example
The following code creates this process using the helper methods from above (without the DI elements).
@@ -126,7 +126,7 @@ Bpmn.writeModelToFile(file, modelInstance);
Even more complex processes can be created with a few lines of code with the standard BPMN model API.
-Parallel Task Example
+Parallel Task Example
```java
// create an empty model
diff --git a/docs/documentation/user-guide/process-applications/maven-archetypes.md b/docs/documentation/user-guide/process-applications/maven-archetypes.md
index 6772bbe..22447fc 100644
--- a/docs/documentation/user-guide/process-applications/maven-archetypes.md
+++ b/docs/documentation/user-guide/process-applications/maven-archetypes.md
@@ -83,28 +83,28 @@ In case you need more flexibility and customization for your project, you can ge
### Detailed Instructions
1. Go to **Preferences -> Maven -> Archetypes -> Add Remote Catalog**
-Eclipse Preferences: Maven Archetypes
+Eclipse Preferences: Maven Archetypes
2. Enter the following URL and description, click on **Verify...** to test the connection and if that worked click on **OK** to save the catalog.
Catalog File: **https://artifacts.camunda.com/artifactory/operaton-bpm/**
Description: **Operaton**
-Eclipse Preferences: Add Maven Archetype Catalog
+Eclipse Preferences: Add Maven Archetype Catalog
Now you should be able to use the archetypes when creating a new Maven project in Eclipse:
1. Go to **File -> New -> Project...** and select **Maven -> Maven Project**
-Create new Maven project
+Create new Maven project
2. Select a location for the project or just keep the default setting.
-Eclipse: Select Maven project location
+Eclipse: Select Maven project location
3. Select the archetype from the catalog that you created before.
-Eclipse: Select Maven archetype from catalog
+Eclipse: Select Maven archetype from catalog
4. Specify Maven coordinates and Operaton version and finish the project creation.
-Eclipse: Specify Maven coordinates and Operaton version
+Eclipse: Specify Maven coordinates and Operaton version
The resulting project should look like this:
-Generated Maven Project in Eclipse
+Generated Maven Project in Eclipse
### Troubleshooting
diff --git a/docs/documentation/user-guide/process-applications/process-application-event-listeners.md b/docs/documentation/user-guide/process-applications/process-application-event-listeners.md
index 86eb33d..824e8cd 100644
--- a/docs/documentation/user-guide/process-applications/process-application-event-listeners.md
+++ b/docs/documentation/user-guide/process-applications/process-application-event-listeners.md
@@ -16,7 +16,7 @@ Task Event listeners allow to react to Task Events (Tasks are Created, Assigned,
When using the process application API, the process engine makes sure that Events are delegated to the right process application. For example, assume there is a process application deployed as "invoice.war" which deploys a process definition named "invoice". The invoice process has a task named "archive invoice". The application "invoice.war" further provides a Java Class implementing the [ExecutionListener](../../user-guide/process-engine/delegation-code.md#execution-listener) interface and is configured to be invoked whenever the END event is fired on the "archive invoice" activity. The process engine makes sure that the event is delegated to the listener class located inside the process application:
-Process Application Events
+Process Application Events
On top of the Execution and Task Listeners which are [explicitly configured in the BPMN 2.0 XML](../../user-guide/process-engine/delegation-code.md#execution-listener), the process application API supports defining a global ExecutionListener and a global TaskListener which are notified about *all events* happening in the processes deployed by a process application:
```java
diff --git a/docs/documentation/user-guide/process-applications/process-application-resources.md b/docs/documentation/user-guide/process-applications/process-application-resources.md
index eab1107..315e2f9 100644
--- a/docs/documentation/user-guide/process-applications/process-application-resources.md
+++ b/docs/documentation/user-guide/process-applications/process-application-resources.md
@@ -12,7 +12,7 @@ menu:
Process applications provide and logically group resources specific to the processes they contain. There are resources that are part of the application itself, like a classloader and its classes and resources, as well as resources managed by the process engine at runtime, like a set of [scripting engines](../../user-guide/process-engine/scripting.md) or [Spin data formats](../../user-guide/data-formats/index.md). This section describes under which conditions the process engine looks up resources on process application level and how that lookup can be enforced.
-Process Application Context
+Process Application Context
## Context Switch
diff --git a/docs/documentation/user-guide/process-applications/the-processes-xml-deployment-descriptor.md b/docs/documentation/user-guide/process-applications/the-processes-xml-deployment-descriptor.md
index cb0a7ba..b2556c3 100644
--- a/docs/documentation/user-guide/process-applications/the-processes-xml-deployment-descriptor.md
+++ b/docs/documentation/user-guide/process-applications/the-processes-xml-deployment-descriptor.md
@@ -138,7 +138,7 @@ Note that the processes.xml file can contain multiple process archives with diff
When deploying a set of BPMN 2.0 files to the process engine, a process deployment is created. The process deployment is performed to the process engine database so that when the process engine is stopped and restarted, the process definitions can be restored from the database and execution can continue. When a process application performs a deployment, in addition to the database deployment it will create a registration for this deployment with the process engine. This is illustrated in the following figure:
-Process Application Deployment
+Process Application Deployment
Deployment of the process application "invoice.war" is illustrated on the left hand side:
@@ -150,7 +150,7 @@ When the process application is undeployed, the registration for the deployment
The registration allows the process engine to load additional Java Classes and resources from the process application when executing the processes. In contrast to the database deployment, which can be restored whenever the process engine is restarted, the registration of the process application is kept as in-memory state. This in-memory state is local to an individual cluster node, allowing us to undeploy or redeploy a process application on a particular cluster node without affecting the other nodes and without having to restart the process engine. If the Job Executor is deployment aware, job execution will also stop for jobs created by this process application. However, as a consequence, the registration also needs to be re-created when the application server is restarted. This happens automatically if the process application takes part in the application server deployment lifecycle. For instance, ServletProcessApplications are deployed as ServletContextListeners and when the servlet context is started, it creates the deployment and registration with the process engine. The redeployment process is illustrated in the next figure:
-Process Application Redeployment
+Process Application Redeployment
(a) Left hand side: invoice.bpmn has not changed:
diff --git a/docs/documentation/user-guide/process-engine/bpmn/example1.bpmn b/docs/documentation/user-guide/process-engine/bpmn/example1.bpmn
deleted file mode 100644
index 229dd39..0000000
--- a/docs/documentation/user-guide/process-engine/bpmn/example1.bpmn
+++ /dev/null
@@ -1,211 +0,0 @@
-
-
-
-
- SequenceFlow_0zvqope
-
-
- SequenceFlow_0zvqope
- SequenceFlow_09aij5b
-
- SequenceFlow_1x1oryz
-
-
-
- SequenceFlow_1x1oryz
- SequenceFlow_1rdlg55
- SequenceFlow_1qctt74
-
-
-
-
- SequenceFlow_0z41ivp
-
-
- SequenceFlow_1rdlg55
- SequenceFlow_0sls8cr
-
-
- SequenceFlow_1qctt74
- SequenceFlow_0z41ivp
-
-
-
- SequenceFlow_0sls8cr
-
-
-
-
- SequenceFlow_08niqu9
-
-
- SequenceFlow_1f4n492
-
-
-
- SequenceFlow_1iozmrv
- SequenceFlow_1f4n492
-
-
- SequenceFlow_1taf0y5
- SequenceFlow_08niqu9
-
-
- SequenceFlow_09aij5b
- SequenceFlow_1iozmrv
- SequenceFlow_1taf0y5
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/documentation/user-guide/process-engine/bpmn/example2.bpmn b/docs/documentation/user-guide/process-engine/bpmn/example2.bpmn
deleted file mode 100644
index 7ae0ede..0000000
--- a/docs/documentation/user-guide/process-engine/bpmn/example2.bpmn
+++ /dev/null
@@ -1,239 +0,0 @@
-
-
-
-
- SequenceFlow_0zvqope
-
-
- SequenceFlow_0zvqope
- SequenceFlow_09aij5b
-
- SequenceFlow_1x1oryz
-
-
-
- SequenceFlow_1x1oryz
- SequenceFlow_1rdlg55
- SequenceFlow_1qctt74
-
-
-
-
- SequenceFlow_0z41ivp
-
-
- SequenceFlow_1rdlg55
- SequenceFlow_0sls8cr
-
-
- SequenceFlow_1qctt74
- SequenceFlow_0z41ivp
-
-
-
- SequenceFlow_0sls8cr
-
-
-
-
- SequenceFlow_08niqu9
-
-
- SequenceFlow_1f4n492
-
-
-
- SequenceFlow_1iozmrv
- SequenceFlow_1f4n492
-
-
- SequenceFlow_1taf0y5
- SequenceFlow_08niqu9
-
-
- SequenceFlow_09aij5b
- SequenceFlow_1iozmrv
- SequenceFlow_1taf0y5
-
-
-
-
-
-
-
- SequenceFlow_1
-
-
-
-
- SequenceFlow_1
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
\ No newline at end of file
diff --git a/docs/documentation/user-guide/process-engine/bpmn/example3.bpmn b/docs/documentation/user-guide/process-engine/bpmn/example3.bpmn
deleted file mode 100644
index aeb030f..0000000
--- a/docs/documentation/user-guide/process-engine/bpmn/example3.bpmn
+++ /dev/null
@@ -1,258 +0,0 @@
-
-
-
-
- SequenceFlow_0zvqope
- SequenceFlow_09aij5b
-
- SequenceFlow_1x1oryz
-
-
-
- SequenceFlow_1x1oryz
- SequenceFlow_1rdlg55
- SequenceFlow_1qctt74
-
-
-
-
- SequenceFlow_0z41ivp
-
-
- SequenceFlow_1rdlg55
- SequenceFlow_0sls8cr
-
-
- SequenceFlow_1qctt74
- SequenceFlow_0z41ivp
-
-
-
- SequenceFlow_0sls8cr
-
-
-
-
- SequenceFlow_1
- SequenceFlow_2
-
-
-
- SequenceFlow_2
-
-
- SequenceFlow_1
-
-
-
-
-
-
-
- SequenceFlow_0zvqope
-
-
-
- SequenceFlow_1iozmrv
- SequenceFlow_1f4n492
-
-
-
- SequenceFlow_09aij5b
- SequenceFlow_1iozmrv
- SequenceFlow_1taf0y5
-
-
-
-
- SequenceFlow_08niqu9
-
-
- SequenceFlow_1taf0y5
- SequenceFlow_08niqu9
-
-
-
- SequenceFlow_1f4n492
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
\ No newline at end of file
diff --git a/docs/documentation/user-guide/process-engine/bpmn/example4.bpmn b/docs/documentation/user-guide/process-engine/bpmn/example4.bpmn
deleted file mode 100644
index ad74447..0000000
--- a/docs/documentation/user-guide/process-engine/bpmn/example4.bpmn
+++ /dev/null
@@ -1,38 +0,0 @@
-
-
-
-
- SequenceFlow_1
-
-
-
-
-
-
-
- SequenceFlow_2
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/documentation/user-guide/process-engine/bpmn/example5.bpmn b/docs/documentation/user-guide/process-engine/bpmn/example5.bpmn
deleted file mode 100644
index a7d62f3..0000000
--- a/docs/documentation/user-guide/process-engine/bpmn/example5.bpmn
+++ /dev/null
@@ -1,223 +0,0 @@
-
-
-
-
- SequenceFlow_0zvqope
-
-
- SequenceFlow_0zvqope
- SequenceFlow_09aij5b
-
- SequenceFlow_1x1oryz
-
-
-
- SequenceFlow_1x1oryz
- SequenceFlow_1rdlg55
- SequenceFlow_1qctt74
-
-
-
-
- SequenceFlow_1rdlg55
- SequenceFlow_1ngkuxp
-
-
- SequenceFlow_1qctt74
- SequenceFlow_0vn6gu4
-
-
-
-
- SequenceFlow_0vn6gu4
- SequenceFlow_1ngkuxp
- SequenceFlow_03xsw30
-
-
- SequenceFlow_03xsw30
-
-
-
-
- SequenceFlow_08niqu9
-
-
- SequenceFlow_1f4n492
-
-
-
- SequenceFlow_1iozmrv
- SequenceFlow_1f4n492
-
-
- SequenceFlow_1taf0y5
- SequenceFlow_08niqu9
-
-
- SequenceFlow_09aij5b
- SequenceFlow_1iozmrv
- SequenceFlow_1taf0y5
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-boundary-timer1.bpmn b/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-boundary-timer1.bpmn
deleted file mode 100644
index 36df516..0000000
--- a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-boundary-timer1.bpmn
+++ /dev/null
@@ -1,93 +0,0 @@
-
-
-
-
- SequenceFlow_1f83m2a
-
-
-
- SequenceFlow_1bk1q1h
-
-
-
- SequenceFlow_1f83m2a
- SequenceFlow_1bk1q1h
-
-
-
- SequenceFlow_0o8cy1m
-
-
-
- SequenceFlow_141slcy
- SequenceFlow_0o8cy1m
-
-
- SequenceFlow_141slcy
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-boundary-timer2.bpmn b/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-boundary-timer2.bpmn
deleted file mode 100644
index 6b53865..0000000
--- a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-boundary-timer2.bpmn
+++ /dev/null
@@ -1,93 +0,0 @@
-
-
-
-
- SequenceFlow_1f83m2a
-
-
-
- SequenceFlow_1bk1q1h
-
-
-
- SequenceFlow_1f83m2a
- SequenceFlow_1bk1q1h
-
-
-
- SequenceFlow_0o8cy1m
-
-
-
- SequenceFlow_141slcy
- SequenceFlow_0o8cy1m
-
-
- SequenceFlow_141slcy
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-compensation1.bpmn b/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-compensation1.bpmn
deleted file mode 100644
index 8745234..0000000
--- a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-compensation1.bpmn
+++ /dev/null
@@ -1,65 +0,0 @@
-
-
-
-
- SequenceFlow_1f83m2a
-
-
-
- SequenceFlow_0lopnql
-
-
-
- SequenceFlow_1f83m2a
- SequenceFlow_1bk1q1h
-
-
-
- SequenceFlow_1bk1q1h
- SequenceFlow_0lopnql
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-compensation2.bpmn b/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-compensation2.bpmn
deleted file mode 100644
index 4ad6c85..0000000
--- a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-compensation2.bpmn
+++ /dev/null
@@ -1,123 +0,0 @@
-
-
-
-
- SequenceFlow_1f83m2a
-
-
-
- SequenceFlow_187k7y6
-
-
-
- SequenceFlow_1f83m2a
- SequenceFlow_1bk1q1h
-
-
-
- SequenceFlow_1bk1q1h
- SequenceFlow_0lopnql
-
-
- SequenceFlow_0lopnql
- SequenceFlow_187k7y6
- SequenceFlow_1n08vq7
-
-
-
-
- SequenceFlow_1n08vq7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-compensation3.bpmn b/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-compensation3.bpmn
deleted file mode 100644
index c5faecf..0000000
--- a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-compensation3.bpmn
+++ /dev/null
@@ -1,163 +0,0 @@
-
-
-
-
- SequenceFlow_1ubf35o
-
-
- SequenceFlow_1ubf35o
- SequenceFlow_0i8tlw1
-
- SequenceFlow_1b5n95l
-
-
-
- SequenceFlow_060tqrp
-
-
-
-
-
-
- SequenceFlow_1b5n95l
- SequenceFlow_060tqrp
-
-
-
-
-
- SequenceFlow_1ia8uwc
- SequenceFlow_0cazove
- SequenceFlow_03uajgw
-
-
-
- SequenceFlow_0cazove
-
-
-
-
- SequenceFlow_03uajgw
-
-
-
-
- SequenceFlow_0i8tlw1
- SequenceFlow_1ia8uwc
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-compensation4.bpmn b/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-compensation4.bpmn
deleted file mode 100644
index 4950ac2..0000000
--- a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-compensation4.bpmn
+++ /dev/null
@@ -1,164 +0,0 @@
-
-
-
-
- SequenceFlow_1ubf35o
-
-
- SequenceFlow_1ubf35o
- SequenceFlow_1yp8kjd
-
-
- SequenceFlow_1b5n95l
- SequenceFlow_0vb3t4n
-
-
-
-
-
- SequenceFlow_1b5n95l
-
-
-
- SequenceFlow_1ia8uwc
- SequenceFlow_0cazove
- SequenceFlow_03uajgw
-
-
- SequenceFlow_0cazove
-
-
- SequenceFlow_03uajgw
-
-
-
- SequenceFlow_0vb3t4n
- SequenceFlow_1ia8uwc
-
-
-
-
-
-
-
-
-
-
- SequenceFlow_1yp8kjd
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-compensation5.bpmn b/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-compensation5.bpmn
deleted file mode 100644
index ae27893..0000000
--- a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-compensation5.bpmn
+++ /dev/null
@@ -1,119 +0,0 @@
-
-
-
-
- SequenceFlow_06klblp
-
-
-
-
- SequenceFlow_182mudt
-
-
-
- SequenceFlow_06klblp
- SequenceFlow_0u3vpf5
-
-
- SequenceFlow_0u3vpf5
- SequenceFlow_0tcbzle
-
-
-
-
-
-
- SequenceFlow_0tcbzle
- SequenceFlow_182mudt
- SequenceFlow_02vmffa
-
-
-
-
- SequenceFlow_02vmffa
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-compensation6.bpmn b/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-compensation6.bpmn
deleted file mode 100644
index d808715..0000000
--- a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example-compensation6.bpmn
+++ /dev/null
@@ -1,134 +0,0 @@
-
-
-
-
- SequenceFlow_06klblp
-
-
-
-
- SequenceFlow_0adrcj0
-
-
-
- SequenceFlow_06klblp
- SequenceFlow_0u3vpf5
-
-
- SequenceFlow_1ysp3mc
- SequenceFlow_0tcbzle
-
-
-
-
-
-
-
- SequenceFlow_0u3vpf5
- SequenceFlow_1ysp3mc
-
-
- SequenceFlow_0tcbzle
- SequenceFlow_0adrcj0
- SequenceFlow_0pemlq1
-
-
-
-
- SequenceFlow_0pemlq1
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example1.bpmn b/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example1.bpmn
deleted file mode 100644
index 6dda0ab..0000000
--- a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example1.bpmn
+++ /dev/null
@@ -1,144 +0,0 @@
-
-
-
-
- SequenceFlow_1aptws8
-
-
-
- SequenceFlow_1r5s7mc
- SequenceFlow_0cgcojv
-
-
-
- SequenceFlow_1aptws8
- SequenceFlow_1r5s7mc
- SequenceFlow_0qtstds
-
-
- SequenceFlow_0qtstds
- SequenceFlow_0vpcxuw
-
- SequenceFlow_1p7995g
-
-
-
- SequenceFlow_1p7995g
- SequenceFlow_0ibybjd
-
-
- SequenceFlow_0ibybjd
-
-
-
-
-
- SequenceFlow_0cgcojv
-
-
-
- SequenceFlow_0vpcxuw
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example2.bpmn b/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example2.bpmn
deleted file mode 100644
index ad548e9..0000000
--- a/docs/documentation/user-guide/process-engine/bpmn/process-instance-migration/example2.bpmn
+++ /dev/null
@@ -1,217 +0,0 @@
-
-
-
-
- SequenceFlow_1aptws8
-
-
-
- SequenceFlow_1aptws8
- SequenceFlow_0qtstds
- SequenceFlow_1iqm7pw
-
-
- SequenceFlow_0qtstds
- SequenceFlow_1rsuqzk
-
- SequenceFlow_1p7995g
-
-
-
- SequenceFlow_1p7995g
- SequenceFlow_0ibybjd
-
-
- SequenceFlow_08azivn
-
-
-
-
- SequenceFlow_0ibybjd
- SequenceFlow_08azivn
-
-
-
-
- SequenceFlow_1iqm7pw
- SequenceFlow_1saocbd
-
- SequenceFlow_0w2lnzx
- SequenceFlow_12zu55u
-
-
- SequenceFlow_0w2lnzx
-
-
-
-
- SequenceFlow_10nijt8
-
-
-
- SequenceFlow_12zu55u
- SequenceFlow_10nijt8
-
-
-
-
- SequenceFlow_1saocbd
-
-
-
- SequenceFlow_1rsuqzk
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/documentation/user-guide/process-engine/bpmn/x_event-based-gateway.bpmn b/docs/documentation/user-guide/process-engine/bpmn/x_event-based-gateway.bpmn
deleted file mode 100644
index 61c3ecb..0000000
--- a/docs/documentation/user-guide/process-engine/bpmn/x_event-based-gateway.bpmn
+++ /dev/null
@@ -1,55 +0,0 @@
-
-
-
-
- SequenceFlow_2
- SequenceFlow_3
-
-
-
- SequenceFlow_2
-
-
-
-
- SequenceFlow_3
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
\ No newline at end of file
diff --git a/docs/documentation/user-guide/process-engine/database/database-schema.md b/docs/documentation/user-guide/process-engine/database/database-schema.md
index 8290660..f75226e 100644
--- a/docs/documentation/user-guide/process-engine/database/database-schema.md
+++ b/docs/documentation/user-guide/process-engine/database/database-schema.md
@@ -23,7 +23,7 @@ match the service API.
The main tables of the process engines are the entities of process definitions, executions, tasks, variables and
event subscriptions. Their relationship is shown in the following UML model.
-Database Schema
+Database Schema
## Process Definitions (`ACT_RE_PROCDEF`)
@@ -106,26 +106,26 @@ The following Entity Relationship Diagrams visualize the database tables and the
## Engine BPMN
-BPMN Tables
+BPMN Tables
## Engine DMN
-DMN Tables
+DMN Tables
## Engine CMMN
-CMMN Tables
+CMMN Tables
## History
To allow different configurations and to keep the tables more flexible, the history tables contain no foreign key constraints.
-History Tables
+History Tables
## Identity
-Identity Tables
\ No newline at end of file
+Identity Tables
\ No newline at end of file
diff --git a/docs/documentation/user-guide/process-engine/error-handling.md b/docs/documentation/user-guide/process-engine/error-handling.md
index 09e2af6..c7c5f17 100644
--- a/docs/documentation/user-guide/process-engine/error-handling.md
+++ b/docs/documentation/user-guide/process-engine/error-handling.md
@@ -41,7 +41,7 @@ In that case you model the error handling explicitly in the process model but yo
Example:
-Error Result XOR
+Error Result XOR
We trigger a "check data completeness" task. The Java Service might throw a "DataIncompleteException". However, if we check for completeness, incomplete data is not an exception, but an expected result, so we prefer to use an XOR-Gateway in the process flow which evaluates a process variable, e.g., ```"#{dataComplete==false}"```.
@@ -49,7 +49,7 @@ We trigger a "check data completeness" task. The Java Service might throw a "Dat
The BPMN 2.0 error event gives you the possibility to explicitly model errors, tackling the use case of business errors. The most prominent example is the "intermediate catching error event", which can be attached to the boundary of an activity. Defining a boundary error event makes most sense on an embedded subprocess, a call activity or a Service Task. An error will cause the alternative process flow to be triggered:
-Error Boundary Event
+Error Boundary Event
See the [Error Events](../../reference/bpmn20/events/error-events.md) section of the [BPMN 2.0 Implementation Reference](../../reference/bpmn20/index.md) and the [Throwing Errors from Delegation Code](../process-engine/delegation-code.md#throw-bpmn-errors-from-delegation-code) section of the [User Guide](../index.md) for more information.
@@ -86,7 +86,7 @@ for (Job failedJob : failedJobs) {
Of course you can always explicitly model a retry mechanism as pointed out in [Where is the retry in BPMN 2.0](http://www.bpm-guide.de/2012/06/15/where-is-the-retry-in-bpmn-2-0/):
-Retry Mechanism
+Retry Mechanism
We would recommend to limit it to cases where you want to see it in the process diagram for a good reason. We prefer asynchronous continuation, as it doesn't bloat your process diagram and basically can do the same thing with even less runtime overhead, as "walking" through the modeled loop involves additional action, e.g., writing an audit log.
@@ -94,7 +94,7 @@ We would recommend to limit it to cases where you want to see it in the process
We often see something like this in projects:
-User Task Error Handling
+User Task Error Handling
Actually this is a valid approach in which you assign errors to an operator as User Tasks and model what options he has to solve the problem. However, this is a strange mixture: We want to handle a technical error we but add it to our business process model. Where do we stop? Do we have to model it on every Service Task now?
diff --git a/docs/documentation/user-guide/process-engine/external-tasks.md b/docs/documentation/user-guide/process-engine/external-tasks.md
index 3336007..58f894f 100644
--- a/docs/documentation/user-guide/process-engine/external-tasks.md
+++ b/docs/documentation/user-guide/process-engine/external-tasks.md
@@ -23,7 +23,7 @@ Note that the above distinction does not say whether the actual "business logic"
The flow of executing external tasks can be conceptually separated into three steps, as depicted in the following image:
-External Task Pattern
+External Task Pattern
1. **Process Engine**: Creation of an external task instance
2. **External Worker**: Fetch and lock external tasks
@@ -97,7 +97,7 @@ Ordinary HTTP requests are immediately answered by the server, regardless of whe
is available or not. This inevitably leads to a situation where the client has to perform multiple recurring requests until
the information is available (polling). This approach can obviously be expensive in terms of resources.
-![Example img](./img/external-task-long-polling.png" alt="Long polling to fetch and lock external tasks
+
With the aid of long polling, a request is suspended by the server if no external tasks are available. As soon as new
external tasks occur, the request is reactivated and the response is performed. The suspension is limited to a
diff --git a/docs/documentation/user-guide/process-engine/history/custom-implementation.md b/docs/documentation/user-guide/process-engine/history/custom-implementation.md
index 0546f54..ed5a6ca 100644
--- a/docs/documentation/user-guide/process-engine/history/custom-implementation.md
+++ b/docs/documentation/user-guide/process-engine/history/custom-implementation.md
@@ -14,7 +14,7 @@ menu:
In order to understand how to provide a custom history backend, it is useful to first look at a more detailed view of the history architecture:
-History Architecture
+History Architecture
Whenever the state of a runtime entity is changed, the core execution component of the process engine fires History Events. In order to make this flexible, the actual creation of the History Events as well as populating the history events with data from the runtime structures is delegated to the History Event Producer. The producer is handed in the runtime data structures (such as an ExecutionEntity or a TaskEntity), creates a new History Event and populates it with data extracted from the runtime structures.
diff --git a/docs/documentation/user-guide/process-engine/history/history-cleanup.md b/docs/documentation/user-guide/process-engine/history/history-cleanup.md
index 6614526..e2ff2c6 100644
--- a/docs/documentation/user-guide/process-engine/history/history-cleanup.md
+++ b/docs/documentation/user-guide/process-engine/history/history-cleanup.md
@@ -78,7 +78,7 @@ The end time is persisted in the corresponding instance tables `ACT_HI_PROCINST`
For process and decision instances in a hierarchy (e.g. a process instance that is started by another process instance via a BPMN Call Activity), the removal time of all instances is always equal to the removal time of the root instance.
-History Cleanup
+History Cleanup
The removal time is persisted in *all* history tables. So in case of a process instance, the removal time is present in `ACT_HI_PROCINST` as well as the corresponding secondary entries in `ACT_HI_ACTINST`, `ACT_HI_TASKINST` etc.
diff --git a/docs/documentation/user-guide/process-engine/img/api.services.odg b/docs/documentation/user-guide/process-engine/img/api.services.odg
deleted file mode 100644
index e41c932..0000000
Binary files a/docs/documentation/user-guide/process-engine/img/api.services.odg and /dev/null differ
diff --git a/docs/documentation/user-guide/process-engine/img/process-engine-history.png b/docs/documentation/user-guide/process-engine/img/process-engine-history.png
deleted file mode 100644
index 03811a8..0000000
Binary files a/docs/documentation/user-guide/process-engine/img/process-engine-history.png and /dev/null differ
diff --git a/docs/documentation/user-guide/process-engine/multi-tenancy.md b/docs/documentation/user-guide/process-engine/multi-tenancy.md
index 383ad00..545f036 100644
--- a/docs/documentation/user-guide/process-engine/multi-tenancy.md
+++ b/docs/documentation/user-guide/process-engine/multi-tenancy.md
@@ -19,7 +19,7 @@ Multi-Tenancy can be achieved in two different ways. One way is to use [one proc
Multi-Tenancy can be achieved with one process engine which uses tenant identifiers (i.e., tenant-ids). The data of all tenants is stored in one table (same database and schema). Isolation is provided by the means of a tenant identifier that is stored in a column.
-One Process Engine with Tenant-Identifiers Architecture
+One Process Engine with Tenant-Identifiers Architecture
The tenant identifier is specified on the deployment and is propagated to all data that is created from the deployment (e.g., process definitions, process instances, tasks, etc.). To access the data for a specific tenant, the process engine allows to filter queries by a tenant identifier or specify a tenant identifier for a command (e.g., create a process instance). Additionally, the process engine provides transparent access restrictions in combination with the Identity Service that allows to omit the tenant identifier.
@@ -464,7 +464,7 @@ See also:
Multi-Tenancy can be achieved by providing one process engine per tenant. Each process engine is configured to use a different data source which connects the data of the tenant. The data of the tenants can be stored in different databases, in one database with different schemas or in one schema with different tables.
-One Process Engine per Tenant Architecture
+One Process Engine per Tenant Architecture
The process engines can run on the same server so that all share the same computational resources such as a data source (when isolating via schemas or tables) or a thread pool for asynchronous job execution.
diff --git a/docs/documentation/user-guide/process-engine/process-diagram-api.md b/docs/documentation/user-guide/process-engine/process-diagram-api.md
index 982d383..dd5cceb 100644
--- a/docs/documentation/user-guide/process-engine/process-diagram-api.md
+++ b/docs/documentation/user-guide/process-engine/process-diagram-api.md
@@ -17,7 +17,7 @@ In our web applications [Cockpit](../../webapps/cockpit/index.md) and [Tasklist]
The previous JavaScript BPMN renderer can still be found at [operaton-bpmn.js](https://github.com/operaton/operaton-bpmn.js), but it is not actively developed anymore.
-Process Diagram Rendering
+Process Diagram Rendering
## bpmn.io Diagram Renderer
diff --git a/docs/documentation/user-guide/process-engine/process-engine-api.md b/docs/documentation/user-guide/process-engine/process-engine-api.md
index e9c8ed2..4528d3b 100644
--- a/docs/documentation/user-guide/process-engine/process-engine-api.md
+++ b/docs/documentation/user-guide/process-engine/process-engine-api.md
@@ -15,7 +15,7 @@ menu:
The Java API is the most common way of interacting with the engine. The central starting point is the ProcessEngine, which can be created in several ways as described in the configuration section. From the ProcessEngine, you can obtain the various services that contain the workflow/BPM methods. ProcessEngine and the services objects are thread safe. So you can keep a reference to 1 of those for a whole server.
-API Services
+API Services
```java
ProcessEngine processEngine = ProcessEngines.getDefaultProcessEngine();
diff --git a/docs/documentation/user-guide/process-engine/process-engine-concepts.md b/docs/documentation/user-guide/process-engine/process-engine-concepts.md
index caadb8f..372510b 100644
--- a/docs/documentation/user-guide/process-engine/process-engine-concepts.md
+++ b/docs/documentation/user-guide/process-engine/process-engine-concepts.md
@@ -188,7 +188,7 @@ If you would like to suspend all process instances of a given process definition
If your process instance contains multiple execution paths (like for instance after a [parallel gateway](../../reference/bpmn20/gateways/parallel-gateway.md), you must be able to differentiate the currently active paths inside the process instance. In the following example, two user tasks *receive payment* and *ship order* can be active at the same time.
-Parallel Gateway
+Parallel Gateway
Internally, the process engine creates two concurrent executions inside the process instance, one for each concurrent path of execution. Executions are also created for scopes, for example if the process engine reaches a [Embedded Sub Process](../../reference/bpmn20/subprocesses/embedded-subprocess.md) or in case of [Multi Instance](../../reference/bpmn20/tasks/task-markers.md).
diff --git a/docs/documentation/user-guide/process-engine/process-instance-restart.md b/docs/documentation/user-guide/process-engine/process-instance-restart.md
index 4799f23..a3ce755 100644
--- a/docs/documentation/user-guide/process-engine/process-instance-restart.md
+++ b/docs/documentation/user-guide/process-engine/process-instance-restart.md
@@ -24,7 +24,7 @@ Note that these operations are also available via REST: restref page="restartPro
As an example, consider the following process model where the red dots mark active tasks:
-Running Process Instance
+Running Process Instance
Let us assume that the process instance has been canceled externally by a worker using the following code:
diff --git a/docs/documentation/user-guide/process-engine/process-versioning.md b/docs/documentation/user-guide/process-engine/process-versioning.md
index 0a23f11..6a07c18 100644
--- a/docs/documentation/user-guide/process-engine/process-versioning.md
+++ b/docs/documentation/user-guide/process-engine/process-versioning.md
@@ -24,7 +24,7 @@ This is supported by the process engine:
You can see different versions in the process definition table and the process instances are linked to this:
-Versioning
+Versioning
:::note[Multi-Tenancy]
If you are using [multi-tenancy with tenant identifiers](../process-engine/multi-tenancy.md#single-process-engine-with-tenant-identifiers) then each tenant has its own process definitions which have versions independent from other tenants. See the [multi-tenancy section](../process-engine/multi-tenancy.md#versioning-of-tenant-specific-definitions) for details.
diff --git a/docs/documentation/user-guide/process-engine/the-job-executor.md b/docs/documentation/user-guide/process-engine/the-job-executor.md
index fc05323..b446bc0 100644
--- a/docs/documentation/user-guide/process-engine/the-job-executor.md
+++ b/docs/documentation/user-guide/process-engine/the-job-executor.md
@@ -19,7 +19,7 @@ A job is an explicit representation of a task to trigger process execution. A jo
While jobs are created during process execution, job acquisition and execution are the job executor's responsibility. The following diagram illustrates these two steps:
-Basic Architecture
+Basic Architecture
## Job Executor Activation
@@ -222,7 +222,7 @@ From now on, all new jobs receive the priorities specified in the BPMN XML again
The following diagram sums up the precedence of priority sources when a job's priority is determined:
-^Priority Precedence
+^Priority Precedence
### Set Job Priorities via ManagementService API
@@ -556,7 +556,7 @@ You can configure an custom retry configuration by adding the `customPostBPMNPar
The Job Executor makes sure that **jobs from a single process instance are never executed concurrently**. Why is this? Consider the following process definition:
-Exclusive Jobs
+Exclusive Jobs
We have a parallel gateway followed by three service tasks which all perform an [asynchronous continuation](../process-engine/transactions-in-processes.md#asynchronous-continuations). As a result of this, three jobs are added to the database. Once such a job is present in the database it can be processed by the job executor. It acquires the jobs and delegates them to a thread pool of worker threads which actually process the jobs. This means that using an asynchronous continuation, you can distribute the work to this thread pool (and in a clustered scenario even across multiple thread pools in the cluster).
@@ -590,7 +590,7 @@ How does `exclusive` behave when a process contains hierarchies e.g. when multip
By default, the exclusive _acquisition_ & _execution_ is only guaranteed for the jobs that originate from the root process instance. In a multi-instance call activity setting, the subprocess instances that will be spawned can run in parallel despite selecting `exclusive` asynchronous continuation as depicted in the image below.
-Single Engine
+Single Engine
If there is a use case where the subprocess-jobs **should not be performed in parallel across each single process instance**, the following configuration can be used:
@@ -617,13 +617,13 @@ Use the feature in combination with awareness of your process model.
In the case of a single, application-embedded process engine, the job executor setup is the following:
-Single Engine
+Single Engine
There is a single job table that the engine adds jobs to and the acquisition consumes from. Creating a second embedded engine would therefore create another acquisition thread and execution thread-pool.
In larger deployments however, this quickly leads to a poorly manageable situation. When running Operaton on Tomcat or an application server, the platform allows to declare multiple process engines shared by multiple process applications. With respect to job execution, one job acquisition may serve multiple job tables (and thus process engines) and a single thread-pool for execution may be used.
-Multiple Engines
+Multiple Engines
**This setup enables centralized monitoring of job acquisition and execution**.
See the platform-specific information in the [Runtime Container Integration](../runtime-container-integration/index.md) section on how the thread pooling is implemented on the different platforms.
@@ -646,11 +646,11 @@ Job acquisitions have to be declared in Operaton's deployment descriptor, see [t
When running Operaton in a cluster, there is a distinction between *homogeneous* and *heterogeneous* setups. We define a cluster as a set of network nodes that all run Operaton against the same database (at least for one engine on each node). In the *homogeneous* case, the same process applications (and thus custom classes like JavaDelegates) are deployed to all of the nodes, as depicted below.
-Homogeneous Cluster
+Homogeneous Cluster
In the *heterogeneous* case, this is not given, meaning that some process applications are only deployed to a part of the nodes.
-Heterogenous Cluster
+Heterogenous Cluster
### Job Execution in Heterogeneous Clusters
diff --git a/docs/documentation/user-guide/process-engine/transactions-in-processes.md b/docs/documentation/user-guide/process-engine/transactions-in-processes.md
index b9622b5..2242676 100644
--- a/docs/documentation/user-guide/process-engine/transactions-in-processes.md
+++ b/docs/documentation/user-guide/process-engine/transactions-in-processes.md
@@ -15,15 +15,15 @@ On any such *external* trigger (i.e., start a process, complete a task, signal a
We talked about wait states as transaction boundaries where the process state is stored to the database, the thread returns to the client and the transaction is committed. The following BPMN elements are always wait states:
-[](../../reference/bpmn20/tasks/receive-task.md)
-[](../../reference/bpmn20/tasks/user-task.md)
-[ Message Event](../../reference/bpmn20/events/message-events.md)
-[ Timer Event](../../reference/bpmn20/events/timer-events.md)
-[ Signal Event](../../reference/bpmn20/events/signal-events.md)
+[](../../reference/bpmn20/tasks/receive-task.md)
+[](../../reference/bpmn20/tasks/user-task.md)
+[ Message Event](../../reference/bpmn20/events/message-events.md)
+[ Timer Event](../../reference/bpmn20/events/timer-events.md)
+[ Signal Event](../../reference/bpmn20/events/signal-events.md)
The [Event Based Gateway](../../reference/bpmn20/gateways/event-based-gateway.md):
-
+
@@ -38,7 +38,7 @@ Keep in mind that [Asynchronous Continuations](#asynchronous-continuations) can
The transition from one such stable state to another stable state is always part of a single transaction, meaning that it succeeds as a whole or is rolled back on any kind of exception occuring during its execution. This is illustrated in the following example:
-Transaction Boundaries
+Transaction Boundaries
We see a segment of a BPMN process with a user task, a service task and a timer event. The timer event marks the next wait state. Completing the user task and validating the address is therefore part of the same unit of work, so it should succeed or fail atomically. That means that if the service task throws an exception we want to roll back the current transaction, so that the execution tracks back to the user task and the user task is still present in the database. This is also the default behavior of the process engine.
@@ -52,7 +52,7 @@ In **1**, an application or client thread completes the task. In that same threa
In some cases the synchronous behavior is not desired. Sometimes it is useful to have custom control over transaction boundaries in a process.
The most common motivation is the requirement to scope *logical units of work*. Consider the following process fragment:
-Asynchronous Continuations
+Asynchronous Continuations
We are completing the user task, generating an invoice and then sending that invoice to the customer. It can be argued that the generation of the invoice is not part of the same unit of work: we do not want to roll back the completion of the usertask if generating an invoice fails.
Ideally, the process engine would complete the user task (**1**), commit the transaction and return
@@ -114,7 +114,7 @@ Declaring asynchronous continuation of the inner activity makes each instance of
To understand how asynchronous continuations work, we first need to understand how an activity is
executed:
-Asynchronous Continuations
+Asynchronous Continuations
The above illustration shows how a regular activity which is entered and left by a sequence flow is
executed:
@@ -129,7 +129,7 @@ executed:
Asynchronous Continuations allow putting break points between the execution of the sequence flows
and the execution of the activity:
-
+
The above illustration shows where the different types of asynchronous continuations break the
execution flow:
@@ -143,7 +143,7 @@ listeners.
Asynchronous continuations directly relate to transaction boundaries: putting an asynchronous
continuation before or after an activity creates a transaction boundary before or after the activity:
-
+
What's more, asynchronous continuations are always executed by the [Job
Executor](../process-engine/the-job-executor.md).
@@ -153,7 +153,7 @@ Executor](../process-engine/the-job-executor.md).
We want to emphasize that in case of a non handled exception, the current transaction gets rolled back and the process instance is in the last wait state (save point). The following image visualizes that.
-Rollback
+Rollback
If an exception occurs when calling `startProcessInstanceByKey` the process instance will not be saved to the database at all.
@@ -173,7 +173,7 @@ However, there are consequences which you should keep in mind:
* Parallel process paths are not executed in parallel in terms of Java Threads, the different paths are executed sequentially, since we only have and use one Thread.
* Timers cannot fire before the transaction is committed to the database. Timers are explained in more detail later, but they are triggered by the only active part of the Process Engine where we use own Threads: The Job Executor. Hence they run in an own thread which receives the due timers from the database. However, in the database the timers are not visible before the current transaction is visible. So the following timer will never fire:
-Not Working Timeout
+Not Working Timeout
## Transaction Integration
@@ -322,7 +322,7 @@ The above table shows a single row holding user data. The user has a unique Id (
We now construct a situation in which 2 transactions attempt to update this entry, one attempting to change the address, the other one attempting to delete the user. The intended behavior is that once of the transactions succeeds and the other is aborted with an error indicating that a concurrency conflict was detected. The user can then decide to retry the transaction based on the latest state of the data:
-Transactions with Optimistic Locking
+Transactions with Optimistic Locking
As you can see in the picture above, `Transaction 1` reads the user data, does something with the data, deletes the user and then commits.
`Transaction 2` starts at the same time and reads the same user data, and also works on the data. When `Transaction 2` attempts to update the user address a conflict is detected (since `Transaction 1` has already deleted the user).
@@ -384,7 +384,7 @@ For example
The following model shows a parallel gateway, on which the `OptimisticLockingException` can occur.
-Optimistic Locking in parallel gateway
+Optimistic Locking in parallel gateway
There are two user tasks after the opening parallel gateway. The closing parallel gateway, after the user tasks, merges the executions to one.
In most cases, one of the user tasks will be completed first. Execution then waits on the closing parallel gateway until the second user task is completed.
diff --git a/docs/documentation/user-guide/process-engine/variables.md b/docs/documentation/user-guide/process-engine/variables.md
index 5bf19f8..14d2397 100644
--- a/docs/documentation/user-guide/process-engine/variables.md
+++ b/docs/documentation/user-guide/process-engine/variables.md
@@ -18,15 +18,15 @@ This section describes the concepts of variables in processes. Variables can be
All entities that can have variables are called *variable scopes*. These are executions (which include process instances) and tasks. As described in the [Concepts section](../process-engine/process-engine-concepts.md#executions), the runtime state of a process instance is represented by a tree of executions. Consider the following process model where the red dots mark active tasks:
-Variables
+Variables
The runtime structure of this process is as follows:
-Variables
+Variables
There is a process instance with two child executions, each of which has created a task. All these five entities are variable scopes and the arrows mark a parent-child relationship. A variable that is defined on a parent scope is accessible in every child scope unless a child scope defines a variable of the same name. The other way around, child variables are not accessible from a parent scope. Variables that are directly attached to the scope in question are called *local* variables. Consider the following assignment of variables to scopes:
-Variables
+Variables
In this case, when working on *Task 1* the variables *worker* and *customer* are accessible. Note that due to the structure of scopes, the variable *worker* can be defined twice, so that *Task 1* accesses a different *worker* variable than *Task 2*. However, both share the variable *customer* which means that if that variable is updated by one of the tasks, this change is also visible to the other.
@@ -34,7 +34,7 @@ Both tasks can access two variables each while none of these is a local variable
Now let's say, we set a local variable *customer* on *Task 1*:
-Variables
+Variables
While two variables named *customer* and *worker* can still be accessed from *Task 1*, the *customer* variable on *Execution 1* is hidden, so the accessible *customer* variable is the local variable of *Task 1*.
@@ -109,7 +109,7 @@ here variable will be set locally in "aSubProcess" and not propagated to the par
The process engine supports the following variable value types:
-Variables
+Variables
Depending on the actual value of a variable, a different type is assigned. Out of the available types, there are nine *primitive* value types, meaning that they store values of simple standard JDK classes without additional metadata:
diff --git a/docs/documentation/user-guide/runtime-container-integration/jboss.md b/docs/documentation/user-guide/runtime-container-integration/jboss.md
index bf57e60..b45b0f7 100644
--- a/docs/documentation/user-guide/runtime-container-integration/jboss.md
+++ b/docs/documentation/user-guide/runtime-container-integration/jboss.md
@@ -296,7 +296,7 @@ One of the nice features of the Wildfly Management System is that it will
In some cases, you may find it more convenient to use WildFly's JConsole extension for starting a process engine.
-JConsole
+JConsole
The JConsole plugin allows you to inspect the management model graphically and build operations using a wizard. To start the JBoss JConsole plugin, start the jconsole.bat/sh file provided in the WildFly distribution. [More Information in the WildFly Docs](https://docs.wildfly.org/23/Admin_Guide.html#JMX).
@@ -353,7 +353,7 @@ As a result, the Application Service will add the process engine module to the c
The Operaton Wildfly subsystem manages process engines as JBoss Services in the JBoss Module Service Container. For the Module Service Container to provide the process engine service(s) to the deployed applications, it is important that the dependencies are known. Consider the following example:
-JBoss Service Dependencies
+JBoss Service Dependencies
There are three applications deployed and two process engine services exist. Application 1 and Application 2 are using Process Engine 1 and Application 3 is using Process Engine 2.
diff --git a/docs/documentation/user-guide/task-forms/index.md b/docs/documentation/user-guide/task-forms/index.md
index 3abdd12..bce6217 100644
--- a/docs/documentation/user-guide/task-forms/index.md
+++ b/docs/documentation/user-guide/task-forms/index.md
@@ -124,7 +124,7 @@ The attributes `operaton:formRef` and `operaton:formRefVersion` can be specified
```
-Provide Form Key for Operaton Forms
+Provide Form Key for Operaton Forms
### Form Key
@@ -141,7 +141,7 @@ From the form developers point of view, `formRef` offers more flexibility than `
To define a default value for a form field, a process variable with the same name as the form field key needs to be defined. Local variables (e.g. created by defining an [Input Parameter](../process-engine/variables/#inputoutput-variable-mapping) for the User Task) take precedence over process variables.
-User Input/Output Mappings for default values for form fields
+User Input/Output Mappings for default values for form fields
The submitted values of a form are returned as variables to the process engine:
@@ -195,7 +195,7 @@ Using [Operaton Run](../../user-guide/operaton-bpm-run.md#starting-with-operaton
placed inside the `configuration/resources/` directory are automatically deployed.
:::
-Deploy your Operaton Form file
+Deploy your Operaton Form file
You can also include Operaton Forms from other deployments by using [form references](#form-reference).
@@ -232,7 +232,7 @@ These Task forms do not use the form-key attribute to be referenced. They are no
The generic form will be used whenever you have not added a dedicated form for a [UserTask][user-tasks] or a [StartEvent][start-event].
-Generic Start Form
+Generic Start Form
Hit the *Add a variable* button to add a variable that will be passed to the process instance upon task completion. State a variable name, select the type and enter the desired value. Enter as many variables as you need.
@@ -283,7 +283,7 @@ Form metadata can be graphically edited using the [Camunda Modeler](https://camu
This form would look like this in Tasklist:
-Generated Form
+Generated Form
As you can see, the `` element is provided as a child element of the BPMN `` element. Form metadata consists of multiple form fields which represent individual input fields where a user has to provide some value or selection.
diff --git a/docs/documentation/user-guide/task-forms/jsf-task-forms.md b/docs/documentation/user-guide/task-forms/jsf-task-forms.md
index 3c96b5c..dc2136a 100644
--- a/docs/documentation/user-guide/task-forms/jsf-task-forms.md
+++ b/docs/documentation/user-guide/task-forms/jsf-task-forms.md
@@ -23,7 +23,7 @@ A working example can be found in the [examples repository](https://github.com/o
The BPMN process used for this example is shown in the image below:
-Task Form Process
+Task Form Process
In this process model we added so called form keys to
@@ -87,7 +87,7 @@ Note that you need `operaton-engine-cdi` in order to have the `camundaTaskForm`
## How does this work?
-If the user clicks on "Start to work on task" Start Task Button in the tasklist, he will follow a link to this form, including the taskId and the callback URL (the URL to access the central tasklist) as GET-Parameters. Accessing this form will trigger the special CDI bean `camundaTaskForm` which
+If the user clicks on "Start to work on task" Start Task Button in the tasklist, he will follow a link to this form, including the taskId and the callback URL (the URL to access the central tasklist) as GET-Parameters. Accessing this form will trigger the special CDI bean `camundaTaskForm` which
* starts a conversation,
* remembers the callback URL
@@ -151,7 +151,7 @@ In the forms you can access your own CDI beans as usual and also access the Oper
This is rendered to a simple form:
-Varibales Task Form Example
+Varibales Task Form Example
The same mechanism can be used to start a new process instance:
@@ -202,9 +202,9 @@ The same mechanism can be used to start a new process instance:
+
@@ -38,7 +38,7 @@ Keep in mind that [Asynchronous Continuations](#asynchronous-continuations) can
The transition from one such stable state to another stable state is always part of a single transaction, meaning that it succeeds as a whole or is rolled back on any kind of exception occuring during its execution. This is illustrated in the following example:
-Transaction Boundaries
+Transaction Boundaries
We see a segment of a BPMN process with a user task, a service task and a timer event. The timer event marks the next wait state. Completing the user task and validating the address is therefore part of the same unit of work, so it should succeed or fail atomically. That means that if the service task throws an exception we want to roll back the current transaction, so that the execution tracks back to the user task and the user task is still present in the database. This is also the default behavior of the process engine.
@@ -52,7 +52,7 @@ In **1**, an application or client thread completes the task. In that same threa
In some cases the synchronous behavior is not desired. Sometimes it is useful to have custom control over transaction boundaries in a process.
The most common motivation is the requirement to scope *logical units of work*. Consider the following process fragment:
-Asynchronous Continuations
+Asynchronous Continuations
We are completing the user task, generating an invoice and then sending that invoice to the customer. It can be argued that the generation of the invoice is not part of the same unit of work: we do not want to roll back the completion of the usertask if generating an invoice fails.
Ideally, the process engine would complete the user task (**1**), commit the transaction and return
@@ -114,7 +114,7 @@ Declaring asynchronous continuation of the inner activity makes each instance of
To understand how asynchronous continuations work, we first need to understand how an activity is
executed:
-Asynchronous Continuations
+Asynchronous Continuations
The above illustration shows how a regular activity which is entered and left by a sequence flow is
executed:
@@ -129,7 +129,7 @@ executed:
Asynchronous Continuations allow putting break points between the execution of the sequence flows
and the execution of the activity:
-
+
The above illustration shows where the different types of asynchronous continuations break the
execution flow:
@@ -143,7 +143,7 @@ listeners.
Asynchronous continuations directly relate to transaction boundaries: putting an asynchronous
continuation before or after an activity creates a transaction boundary before or after the activity:
-
+
What's more, asynchronous continuations are always executed by the [Job
Executor](../process-engine/the-job-executor.md).
@@ -153,7 +153,7 @@ Executor](../process-engine/the-job-executor.md).
We want to emphasize that in case of a non handled exception, the current transaction gets rolled back and the process instance is in the last wait state (save point). The following image visualizes that.
-Rollback
+Rollback
If an exception occurs when calling `startProcessInstanceByKey` the process instance will not be saved to the database at all.
@@ -173,7 +173,7 @@ However, there are consequences which you should keep in mind:
* Parallel process paths are not executed in parallel in terms of Java Threads, the different paths are executed sequentially, since we only have and use one Thread.
* Timers cannot fire before the transaction is committed to the database. Timers are explained in more detail later, but they are triggered by the only active part of the Process Engine where we use own Threads: The Job Executor. Hence they run in an own thread which receives the due timers from the database. However, in the database the timers are not visible before the current transaction is visible. So the following timer will never fire:
-Not Working Timeout
+Not Working Timeout
## Transaction Integration
@@ -322,7 +322,7 @@ The above table shows a single row holding user data. The user has a unique Id (
We now construct a situation in which 2 transactions attempt to update this entry, one attempting to change the address, the other one attempting to delete the user. The intended behavior is that once of the transactions succeeds and the other is aborted with an error indicating that a concurrency conflict was detected. The user can then decide to retry the transaction based on the latest state of the data:
-Transactions with Optimistic Locking
+Transactions with Optimistic Locking
As you can see in the picture above, `Transaction 1` reads the user data, does something with the data, deletes the user and then commits.
`Transaction 2` starts at the same time and reads the same user data, and also works on the data. When `Transaction 2` attempts to update the user address a conflict is detected (since `Transaction 1` has already deleted the user).
@@ -384,7 +384,7 @@ For example
The following model shows a parallel gateway, on which the `OptimisticLockingException` can occur.
-Optimistic Locking in parallel gateway
+Optimistic Locking in parallel gateway
There are two user tasks after the opening parallel gateway. The closing parallel gateway, after the user tasks, merges the executions to one.
In most cases, one of the user tasks will be completed first. Execution then waits on the closing parallel gateway until the second user task is completed.
diff --git a/docs/documentation/user-guide/process-engine/variables.md b/docs/documentation/user-guide/process-engine/variables.md
index 5bf19f8..14d2397 100644
--- a/docs/documentation/user-guide/process-engine/variables.md
+++ b/docs/documentation/user-guide/process-engine/variables.md
@@ -18,15 +18,15 @@ This section describes the concepts of variables in processes. Variables can be
All entities that can have variables are called *variable scopes*. These are executions (which include process instances) and tasks. As described in the [Concepts section](../process-engine/process-engine-concepts.md#executions), the runtime state of a process instance is represented by a tree of executions. Consider the following process model where the red dots mark active tasks:
-Variables
+Variables
The runtime structure of this process is as follows:
-Variables
+Variables
There is a process instance with two child executions, each of which has created a task. All these five entities are variable scopes and the arrows mark a parent-child relationship. A variable that is defined on a parent scope is accessible in every child scope unless a child scope defines a variable of the same name. The other way around, child variables are not accessible from a parent scope. Variables that are directly attached to the scope in question are called *local* variables. Consider the following assignment of variables to scopes:
-Variables
+Variables
In this case, when working on *Task 1* the variables *worker* and *customer* are accessible. Note that due to the structure of scopes, the variable *worker* can be defined twice, so that *Task 1* accesses a different *worker* variable than *Task 2*. However, both share the variable *customer* which means that if that variable is updated by one of the tasks, this change is also visible to the other.
@@ -34,7 +34,7 @@ Both tasks can access two variables each while none of these is a local variable
Now let's say, we set a local variable *customer* on *Task 1*:
-Variables
+Variables
While two variables named *customer* and *worker* can still be accessed from *Task 1*, the *customer* variable on *Execution 1* is hidden, so the accessible *customer* variable is the local variable of *Task 1*.
@@ -109,7 +109,7 @@ here variable will be set locally in "aSubProcess" and not propagated to the par
The process engine supports the following variable value types:
-Variables
+Variables
Depending on the actual value of a variable, a different type is assigned. Out of the available types, there are nine *primitive* value types, meaning that they store values of simple standard JDK classes without additional metadata:
diff --git a/docs/documentation/user-guide/runtime-container-integration/jboss.md b/docs/documentation/user-guide/runtime-container-integration/jboss.md
index bf57e60..b45b0f7 100644
--- a/docs/documentation/user-guide/runtime-container-integration/jboss.md
+++ b/docs/documentation/user-guide/runtime-container-integration/jboss.md
@@ -296,7 +296,7 @@ One of the nice features of the Wildfly Management System is that it will
In some cases, you may find it more convenient to use WildFly's JConsole extension for starting a process engine.
-JConsole
+JConsole
The JConsole plugin allows you to inspect the management model graphically and build operations using a wizard. To start the JBoss JConsole plugin, start the jconsole.bat/sh file provided in the WildFly distribution. [More Information in the WildFly Docs](https://docs.wildfly.org/23/Admin_Guide.html#JMX).
@@ -353,7 +353,7 @@ As a result, the Application Service will add the process engine module to the c
The Operaton Wildfly subsystem manages process engines as JBoss Services in the JBoss Module Service Container. For the Module Service Container to provide the process engine service(s) to the deployed applications, it is important that the dependencies are known. Consider the following example:
-JBoss Service Dependencies
+JBoss Service Dependencies
There are three applications deployed and two process engine services exist. Application 1 and Application 2 are using Process Engine 1 and Application 3 is using Process Engine 2.
diff --git a/docs/documentation/user-guide/task-forms/index.md b/docs/documentation/user-guide/task-forms/index.md
index 3abdd12..bce6217 100644
--- a/docs/documentation/user-guide/task-forms/index.md
+++ b/docs/documentation/user-guide/task-forms/index.md
@@ -124,7 +124,7 @@ The attributes `operaton:formRef` and `operaton:formRefVersion` can be specified
```
-Provide Form Key for Operaton Forms
+Provide Form Key for Operaton Forms
### Form Key
@@ -141,7 +141,7 @@ From the form developers point of view, `formRef` offers more flexibility than `
To define a default value for a form field, a process variable with the same name as the form field key needs to be defined. Local variables (e.g. created by defining an [Input Parameter](../process-engine/variables/#inputoutput-variable-mapping) for the User Task) take precedence over process variables.
-User Input/Output Mappings for default values for form fields
+User Input/Output Mappings for default values for form fields
The submitted values of a form are returned as variables to the process engine:
@@ -195,7 +195,7 @@ Using [Operaton Run](../../user-guide/operaton-bpm-run.md#starting-with-operaton
placed inside the `configuration/resources/` directory are automatically deployed.
:::
-Deploy your Operaton Form file
+Deploy your Operaton Form file
You can also include Operaton Forms from other deployments by using [form references](#form-reference).
@@ -232,7 +232,7 @@ These Task forms do not use the form-key attribute to be referenced. They are no
The generic form will be used whenever you have not added a dedicated form for a [UserTask][user-tasks] or a [StartEvent][start-event].
-Generic Start Form
+Generic Start Form
Hit the *Add a variable* button to add a variable that will be passed to the process instance upon task completion. State a variable name, select the type and enter the desired value. Enter as many variables as you need.
@@ -283,7 +283,7 @@ Form metadata can be graphically edited using the [Camunda Modeler](https://camu
This form would look like this in Tasklist:
-Generated Form
+Generated Form
As you can see, the `