Microflow cant pause/wait

This is a very nice idea that’s built into some other visual languages. But others are right, you can express it in Mendix without needing built-in primitives for that.

On itself Introduction of pause/resume functionality is not as straightforward as you might think.

1. First of all it would make Mendix server stateful, since the information about paused microflows, their state (think variables, session information, etc) has to be stored somewhere, alongside the resume point.
2. What happens if the error occurred later on in the data flow and we need to rollback your changes, how do we orchestrate those transactions over time?
3. What happens if the state of variables/objects/access rights got changes in between?
4. What happens if you deployed a new version of your application and we detect paused microflows from the previous version? Should we introduce versioning of “business processes” here and call the previous version, since the new one might not be compatible.

That’s just couple of points I thought of in the last 3 minutes, but you can imagine there are probably hundreds more that has to be considered.

This is a great idea! This is a process well known in java showInputDialog() and would make the microflow simpler and easier compared to the suggested Microflow->inputpage->NextMicroflow. The big advantage is that this idea will enable developers to design a microflow with a DialogBoxAnswer in a way that comes naturally to people.

For instance, this can be done by adding another type of split: the “DialogAnswerSplit”. Any microflow containing such a split, the microflow has a hidden DialogBoxAnswer-parameter. At first call of the microflow, this parameter is empty and the first part will get executed ending in the dialog page getting called. Probably the state will need to get passed along to the page, clientside. The dialog page, upon the user having answered, would call the same microflow, but with the DialogBoxAnswer-parameter containing the user’s answer.  This time the microflow would go directly to the DialogAnswerSplit. 

Totally stateless serverside and nothing more needed in the modeler than an addition of a DialogAnswerSplit. The building process would take care of the rest including the dialog page.

That would go directly against the philosophy of a stateless server Mendix is moving to with Mendix 7.

Also this functionality is easy to implement as is in Mendix. Just create a popup page of whatever you need the user to input and open this at the end of your microflow, then pass the input to another microflow that runs as soon as the user is done. No need for a single microflow to wait for the user.

You can already model this with seperate microflow transactions with in between windows that you fill with an extra entity that tracks the input state and you just connect it to current session and whichever entities you're using in your microflows. And you can do the final commit after that object has reached a final state. You don't want microflows to pause for indeed the reason Nikel Kruizinga mentioned scoping / locking of objects but also server threading.

Hi Jim,

until this idea is implemented in the business modeler, have you already checked out the 'Confirm Button' widget in the appstore?

https://appstore.home.mendix.com/link/app/33464/Mendix/Confirm-Button

I have not used it myself, but based on its description it looks like it could solve your issues..

This is one of the things I often miss in Mendix. I am also sure this exact idea had been suggested (multiple times) before.

In executing this idea there would be some fundamental issues you would need to resolve. If I were a Mendix runtime developer I would not be able to implement this based on this idea as posted alone.

How would you handle transaction scope and variable scope? How would you measure performance for the microflow as a whole (you can't really)? I am sure there are more issues.

Maybe what we actually need are macroflows, which would visualize the user's journey, inclusing decisions made in a dialog like these.

Indeed! Would be great if Mendix could have a Dialogbox Action, which would wait for user Input, and continue its flow, based on the user input. I can imagine it would work something like this in a microflow: