Question

How does Mendix process a microflow if a form is opened within the microflow but is not the final action?

3

I have a microflow which creates several objects and then opens a data view form to edit one of the objects. Whan the form is closed I want to perform some further processing within the microflow depending on whether the form has been 'Closed' or 'Saved'. It is not working as I expected & when I run the application using the microflow debugger it appears to be processing the actions which are placed AFTER the 'Show form' action BEFORE the form is actually displayed on the screen ... can someone explain what is actually happening here, and what the actual processing sequence is for actions in a microflow. Thanks. * UPDATE * Re. the answers below - I think the way to handle this situation would be to have a microflow which calls a sub-microflow to create the objects and open the form. This is then followed by a second sub-microflow which will process subsequent actions depending on how the form was closed. Thanks. * FURTHER UPDATE * Calling sub-microflows does not have the desired effect, as the calling microflow behaves in the same way as a single microflow. So I think it will have to be done as separate microflows.

asked 2010-02-19

Andrew Whiteley

2 answers

2

As the name says, the Open Form action only opens the form. Assuming it opens correctly, the microflow will continue with the other actions. If you want to continue only after the opened form has been saved I suggest you use a custom save button to continue with the object. If this is all the same object, you won't even need to commit it as the cached object gets passed to the form and with the save button back to the CustomSave microflow and so on.

answered 2010-02-19

Robert van 't Hof

Alexander Willemsen · Accepted Answer · 2010-02-19

This is my understanding of how Mendix handles situations like this:

All the client actions that are executed by a microflow (opening a form, refreshing an object, displaying a text message, etc) are not send directly to the client, but are 'queued' and send to the client when the full microflow successfully completes. This way, when an error occurs and the microflow (transaction) is rolled back, the client actions can also be 'rolled back' by removing them from the queue. If the client actions would be send to the client directly, it wouldn't be possible to perform correct rollbacks of microflows, causing all kinds of problems.

So, to answer your question, all actions of a microflow are executed in the correct sequence (the sequence indicated by the arrows of the flow), but the (external) effects are only visible after the full microflow is finished.