Why to add a brand new designer for workflows? Mendix can just reuse microflow designer for making workflows. That way we makers can use the same colorful syntax to make workflow as we do to make nanoflow, rule, microflow.
The behind the scene workflow engine can remain the same as it is today, just its designer page is back to microflow. A new stateful microflow (macroflow?).
Here is an approach:
1) In the microflow properties add a new boolean property: Is it stateful/workflow: Yes / No
2) If the maker selects No (default) then it is a regular stateless microflow.
3) If the maker selects Yes then it is stateful microflow. That means it will track the progress using key as the map of persistent entities. And the state is the internal identifier of the boxes it has completed.
4) So for a given key of GUID (single or composite) a stateful microflow should store & remember the outcomes of each box/activity it ever executed and its datetimes. So when it reenters it can resume just like a microflow. If a submicroflow call inside this has returned a persistent entity then its GUID would be stored alongwith the activity call-microflow. So when we reenter this stateful microflow those GUID will fetch the latest data from database. The non-persistent variables from any previous step/activity can be stored as a snapshot.
5) Whenever a Page or a microflow wishes to resume the workflow they just call that stateful microflow with its parameters. May be Mendix can add a new option here into the call-microflow action – that if the called microflow is stateful then select one of 3 options – Resume; Reevaluate; Restart. Default is empty that reexecutes the waiting action. Resume completes the waiting action then continues. If Reevaluate is selected then it reruns the same microflow and recreates its new state and all any old waiting actions will auto-cancel if they dont apply during the reevalution; but the completed waitable actions wont revert if they were already done. Whereas the Restart will autocancel all waitable actions and restart the stateful microflow.
6) Any submicroflow called by this stateful microflow could be either stateless or stateful. If a stateful is called then the caller parent microflow waits forever for the submicroflow to end.
7) A show page action or show message action or close page action or synchronize (i.e. all actions in the group ‘Client’), should have a new option to Wait or Continue. The default option is ‘Continue’. If this action is in a stateful microflow then it can be selected to Wait so that caller stateful microflow can wait forever to resume when called with same key.
8) If the caller stateful microflow is waiting at two actions – say both are show-page actions, then reentry into the parent can check the role of the currentuser to resolve which actions can resume. If multiple actions get to resume at the same time, then use a new property in show-page action if Wait was selected. This new property can be an integer ‘Priority’. Amongst all waiting actions the highest priority ones will get to resume together off-course based on roles.
9) Decision box can be enhanced by choosing it to be exclusive or inclusive (parallel). If exclusive (default) then it works like today i.e. one expression is allowed. But if inclusive is selected then the decision box is allowed to add multiple expressions. Each expression can return boolean or enum just like it does today. It executes all expressions and determines which all enum values were returned and it takes all those paths in parallel.
10) For a jump action you can enhance the green Start event by adding a String label to it. That way there are multiple entry points to this stateful microflow as well as jump points. If this is implemented then the action of ‘call microflow’ should identify whether the called miroflow is a stateful or not and if stateful then it should give an option to select a Label from amongst all its Start events. May be you can throw in a new action ‘Wait’ in the microflow actions under the group ‘Client’.
I am sure I must have left out writing of some important features thinking it could be same as that in stateless microflows (except may be transaction boundaries wont work and error handling might need to include timeouts etc), but to me the impendence difference between workflow and microflow designers is quite stark.
An example of stateful microflow with the above approach:
To create a workflow Authorize Loan:
a) make a microflow “AuthorizeCurrentLoan” and in its property ‘Is it stateful’ select Yes.
b) its argument is a Customer entity (its GUID is the key. If there were multiple persistent arguments then the key is composite of all GUIDs. If there are non-persistent args then those would be needed to invoke it but would not be part of the key of this stateful microflow running instance)
c) it has actions such as: check if multiple loan requests; if multiple found then show the list to specialist; he selects one; show page to approver; decision boxes; show page to manager; et al. you get the picture !
d) So all steps of the workflow in one same colorful stateful microflow syntax.
...pphllleeease grant this maker’s wish...