Question

Error handling with subflows and continue without rollback

1

Hi All, I created a logging entity where we capture logs of specific flows that go into error handling. However it seems that if you put error handling on subflows and return a error handler to the main flow, the log object that is created in the subflow is rolled back. Even if I selected continue without rollback. You can replace the error handler with end events but then you lose the purpose of the error handler. This is not wanted. I tried created the log object in the mainflow after the last error handler and that works fine, however I do not have all params for the error log in that flow so I really want to do it in the subflow. Working with start and end transaction after the commit of that object in the subflow doesn’t help either. Has anybody found a neat way to achieve this? Kind regards Kevin

asked 2022-06-21

Kevin Narmon

7 answers

Ruud Fleskens · Answer 1 · 2022-06-21

Hi Kevin,

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?

Kevin Narmon · Answer 2 · 2022-06-21

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 …

Kevin Narmon · Answer 3 · 2022-06-21

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.

Ruud Fleskens · Answer 4 · 2022-06-21

Have a look at the example below:

Kevin Narmon · Answer 5 · 2022-06-22

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 ...

Robert Price · Answer 6 · 2022-06-22

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.

Kevin Narmon · Answer 7 · 2022-06-23

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 ...