For Dynamic Processes we recognize the following markers:
- Repeatable: controls whether a stage, activity or milestone is repeatable.
- Auto Complete: controls the completion of a stage instance.
- Manually Activated: controls the activation of a stage or activity instance.
- Required: controls whether a stage, activity or milestone is required.
Next we have the following conditions:
- Activation: additional entry criteria for a stage.
- Enablement: additional entry criteria for a activity.
- Termination: additional exit criteria for a stage or activity.
- Completion: addition exit criteria for a milestone.
Markers
Below is some additional information about these markers. This text comes directly from the Oracle documentation.Repeatable
The behavior of the repetition relies on the presence of entry criteria. If there is no entry criterion defined, then the repetition rule is evaluated by default in the transition into the COMPLETED state. Otherwise the repetition rule is only evaluated, when an entry criterion is satisfied and the task/stage transitions away from the state AVAILABLE into the next state.Repetition on completion
To repeat a task or stage when it gets completed a repetition rule must be defined and the task or stage must not have any entry criteria. Whenever a task or stage instance transitions into the COMPLETED state, the repetition rule is evaluated and if it evaluates to true a new instance of the task or stage is created. The new instance transitions into the AVAILABLE state.Repetition triggered by entry criteria
A trigger for a repetition of a milestone, stage or task is a satisfied sentry, that is referenced as entry criterion. Whenever an entry criterion is satisfied, the repetition rule is evaluated and if it evaluates to true, a new instance of the milestone, stage or task is created. The new instance transitions into the AVAILABLE state. The previous instance, in case of a milestone instance, transitions in state COMPLETED and, in case of a stage or task instance, into the ACTIVE or ENABLED state (depending on the manual activation rule) because the entry criterion is satisfied.Auto Complete
The attribute autoComplete controls the completion of a stage instance. The stage will be auto-completed if:- Auto-complete is true and there are no children in the ACTIVE state, and all required children are COMPLETED, DISABLED or TERMINATED.
- Auto-complete is false and there are no children in the ACTIVE state and
- all children are COMPLETED, DISABLED or TERMINATED, or
- on manual completion, all required children are COMPLETED, DISABLED or TERMINATED.
Manually Activated
Whether the actual work of a task or stage can be performed depends on its entry criteria. Given that an entry criterion is fulfilled, there are two ways to activate a task:- By manual activation
- By automatic activation
Manual activation is the default behavior in which it is required that a user manually activates a task. By specifying a manual activation rule, it is possible to omit this step or make it depend on case variable payload. With manual activation, a user can decide to activate a task or instead disable it. A task that is automatically activated must be carried out.
In terms of the task/stage lifecycle, manual activation corresponds to the transition from AVAILABLE to ENABLED when an entry criterion occurs, and from ENABLED to ACTIVE when the task is manually activated. In contrast, automatic activation corresponds to the direct transition from AVAILABLE to ACTIVE that fires immediately when an entry criterion occurs.
Required
A plan item may be required, meaning that it has to reach an end-like state before the containing stage can complete. Whether a plan item is required can be specified by a required rule.This rule is evaluated when the milestone, stage or task is instantiated and transitions to the state AVAILABLE, and its result value of type boolean is maintained throughout the remainder of the process instance. If this rule evaluates to true, the element's parent stage instance must not transition to COMPLETED state unless the element is in the COMPLETED, TERMINATED or DISABLED state. For example, a task that has not yet been worked on, i.e., is in state ENABLED, prevents its containing stage to complete. If the rule is not present, then it is considered to be false.
Conditions
Below is some additional information about the conditions.Enabled
A task or stage becomes enabled as soon as any of its entry criteria is fulfilled. If this is given when the task/stage becomes available, it immediately becomes enabled or, depending on its manual activation rule, active.Terminated
The exit transition triggers when the task's/stage's exit criteria are met.Our specification
The following image shows our current implementation.
Let's get into the details of this implementation.
A new instance of the Jarvis Pizzeria Dynamic Process is started by the Order Entry WebForm.
The Ordering stage has no entry condition, so this is activated immediately after the order has been given. This stage only contains a mandatory structured process that is started automatically. This structured process registers the order in a back-end system and is almost immediately completed. The completion of the activity also completes the Ordering stage (the ‘Auto Complete’ markers is set and there is no additional ‘Termination’ condition set).
The preparation stage has an access condition, namely: that the Ordering stage must be completed. That is the case, so the preparation stage is also activated immediately. This also causes that the structured process Prepare Pizza is enabled. Because it has to be activated manually, it is available but not yet started.
And finally also the Process Payment activity, that is not part of any stage, is enabled.
The following image shows this situation
We have now come to the point that the ordering is completed and that the order can be prepared. For this we have the structured process Prepare Pizza. For every ordered pizza in the order, an instance must be started manually. Let's start up an instance and see what happens.
We started the Prepare Pizza process. It has been completed at a certain moment. This also completes the Prepared milestone. This in turn results in the Compose Order activity to becoming available. The repeatable activity Prepare Pizza will also be available again.
It seemed to be so good, but this is not quite what we had in mind. It is not entirely logical that the milestone Prepared is set but also the Prepare Pizza activity is still available. The milestone can only be set as all pizza's has been prepared.
We have to adjust this. But now let's go on first. In order to complete the Preparation Stage, we must indicate that no more Pizzas needs to be prepared (DISABLE the Prepare Pizza activity) and that the order can be prepared (by executing the Compose Order activity).
After doing this we have the following situation
The Delivered milestone also appears to have no condition. So once the Delivery Stage is activated, the milestone is set, while the intention is that this only happens once the Deliver and Payment Activity has been completed. So there are some more adjustments needed.
We will implement the following adjustments:
- the Delivered milestone may only be set when both the Delivered activity and the Payment activity have been performed.
- the Prepared milestone may only be set if there is no Prepare Pizza activity available, but has been performed at least once.
Our implementation
1. For this change an entry condition for the Deliver milestone is needed. Initially, we decided that the milestone should be set as soon as the Delivered Activity is completed and the Paid milestone is set. However, the condition can only be based on milestones and activities in the own stage. The Paid milestone is therefore not available. Because it is possible to base the condition on Dynamic Process data, a good alternative is available. Payment is made in the Payment process. The condition can thus be provided with the check: amountPaid> 0.
2. This second condition does not seem to be that simple yet. The part that no Prepare Pizza activity may be available is simple. The activation criteria of the Prepared milestone must match 'Prepare Pizza' is DISABLED. But the other part is a bit harder. We have said that the activity must be performed at least once. But actually the activity has to be done exactly as often as the number of pizza in the order. Data objects are needed for the total number of instances (pizzas) and the number of instances executed. Once the value in these data objects is equal to each other, the criteria are met. This ensures that the Prepared milestone is available at the right moment.
But this does not prevent the Prepare Pizza activity from being started again (because it is still available) and the values in the data objects no longer match each other. At this moment we do not have a good solution for this. In this way it is also not possible to prepare pizzas simultaneously (in parallel). This is also an issue we had with structured processes (26 Third step in Implementing the Order Processing, Correlation). It is our expectation that Oracle will come up with a solution to be able to execute business in parallel.
The Prepare Pizza activity is a manually starting activity. This is done with a reason. Now we could say: because the Pizza preparer starts the activity itself. But that is not the reason. The real reason is that the combination of automatic start and repeatable is quite an unfortunate one. As soon as an instance has been completed, the next one is started immediately. Because of this, it can not be DISABLED, so we can not meet the milestone condition.
After implementing these conditions we can rerun an instance and get in completed as expected.
Without going into the details of all the rather complex situations that can occur, we hope to have made clear with a few examples that the use of markers and conditions is not as simple as it seems. From a functional point of view, things can get complex fairly quick.
No comments:
Post a Comment