I think the pattern is wrong. Objects within microflows that end in error events are always rolled back unless using an error handler. When you return to the main flow with an error event, you will have all error variables available within your main flow. Try to create the log object there using these variables within a custom error handler. What other specific params do you need that you don't have available in the main flow?
If we do for example an odata call or rest call, we make a subflow to check the environment and the needed URL. We want to log the URL that is called for the call. So I will not have this available in the mainflow unless I extract this part of the subflow into the mainflow …
Well that’s not really desired behaviour, because if my ODATA call fails and I do not throw an error then my mainflow will continu regardless of the fact if I have a ResultObject. Because if I end up with an error and put as end param a resultobject which I then manually need to set to empty, then I do not know whether the call has succeeded and has not returned an object or whether the call has failed.
Have a look at the example below:
This works for simple flows but what if you have more complex flows. Asumme the scenario you had, but before the creation of the ‘newdossier’ you have 3 subflows in which objects are changed and comitted. How will you handle the rollback of these items in the mainflow then? Is this something which is done when you raise an error and handle it with custom with rollback or not? Because if the error handler takes care of that, then this solution is not feasable i guess.
Is there no workaround to throw an error in the subflow and work with ‘start transaction’ and ‘end transaction’. I tested this but even that seems to be rollbacked. I really think Mendix should allow users to commit an object in error handling without rollbacking that object defined in the custom flow ...
If you want to handle an error in your submicroflow to perform some task, but you then want to propogate the error on and also use error handling in the calling microflow, then one approach would be to rethrow an error in the error handler of the submicroflow. You can do this using the ThrowException Java Action from the Community Commons module that’s available in the Marketplace.
If I rethrow the error with the ThrowException Java Action, then my commit on my log object is rolled back. Unless I am doing something wrong, this will not work for my case.
I end my submicroflow with commit of a log object and an end event. Then I throw that java action in the higher level sub mf for which I then enable error handling. I then comes to my mainflow and continues the flow properly, but at the end my log object is not in the database ...