rallen2010
commented
3 years ago I have the basics of this running in the engine now (on feature-variable-expressions). I need some input / opinion on where these are triggered. Adding triggering points in the engine is relatively simple coding, and so the issue here is to get the triggering points that allow users to build powerful process models.
Recap: The idea is that you can have a set of variable expressions called at various places on the model. Each set is a group of 1 or more variable expressions (such as setting a process variable to a static, to another process variable, to a SQL statement, function body, etc.). Each entry in a set of variable expressions has a sequence number, and so the expressions in a set run in sequence order.
Initially, i thought that each object in a process model could have an expression set that executes before the object ('PRE'), and a set that executes after the object ("POST") - but now realise that, for example, POST would cause problems after an opening parallel or inclusive gateway with auto-executed steps like scriptTasks that follow the gateway executing before the gateway has completed.
So the semantics I'm proposing would work like this:
- For Task objects (task, scriptTask, userTask, manualTask, decisionTask): a 'pre' set and a 'post' set. {Q: are 'pre' and 'post' the best names here, or would his be better described as 'before task' and 'after task'?
- For Gateway objects.
- For Opening Gateways, only a 'pre' set that executes before the split occurs
- For Closing Gateways, only a 'post' set that executes once the gateway is ready to proceed (after the merge)
- For Close & re-Opening Parallel Gateways, they would execute the 'post' set after the merge phase and then execute the 'pre' set before re-splitting. {Q: this means that 'post' executes before 'pre' in this case, which could be confusing & so should we rename these sets 'before split' and 'after merge' for all gateway sets?)
-
For Event types, 2 triggering points could be useful:
- an 'on event' set that would occur when the event is triggered.
- for timers, this would be when the timer fires
- for error or escalation boundary events, once the error / escalation is thrown / caught
- for messages & signals (when we do them), once the message or signal is thrown / caught, as appropriate
- a 'pre' set that would occur when the object becomes the current task. For most events, this would be at the same point as the 'on event' set; however, for a timer events such as a timer StartEvent, a timer intermediateCatchEvent, or a non-interrupting timer Boundary Event, the event becomes the current object before the timer starts running & continues as the current event until the timer fires. There would be some value to having a 'pre' set execute before the timer starts, then an 'on-event' set firing once the timer fires. For example, the 'pre' set could contain an expression for when the timer should fire as a PL/SQL function, which is then evaluated to set a process variable which is then used as a substitution variable to set the timer execution date. A process that starts with a timer start would also want to set any process variables that are set as part of process initialisation (such as setting the process originator, security level, whatever...) before the timer starts so that all processes running in the system have those common variables set.
Questions:
- an 'on event' set that would occur when the event is triggered.
- Naming for Task sets: 'pre' and 'post' or 'before task' and 'after task'?
- Naming for Gateway Sets: 'pre' and 'post' or 'before split' and 'after merge'?
- Naming for Event Sets: 'pre' or 'before event' and 'on event' ?
- Any other triggering points that would be useful?
- Any problems or issues here on triggering?
Once we get consensus here, we can spec out the UI and parsing requirements. Happy to give a quick demo of what I have working at our Thursday meeting...
LouisMoreaux
The process variable system introduced in v5.0 provides an enabling capability that creates persistent storage of process stage for the life of a process. We introduced methods for these variables to be substituted into userTasks calling APEX pages, to control bpmn gateways, to be accessed in pl/sql in a scriptTask or serviceTask, and to be used in a timer definition. This created an enabling capability for an APEX developer to use PL/QL to persist and access variables throughout a process.
However, the v5.0 process variables require programming rather than being declarative, frequently require additional non-business scriptTask activities to be added into a business process, and are generally not very declarative or low-code.
This feature builds on the existing v5 process variables by allowing any object in the bpmn model to have variable actions declared with it as part of the object properties. Each object definition would have an associated list of variables that are set before the task is executed and after the task is executed. A variable could be set to an expression, which would be:
See attached PPT for further detail, including some use cases and issues. 2201Declarative Process Variables.pptx