Rollback in Business Modeler 5.9.1?

0
Hello Mendix Community: I have been using the Calendar Widget as a means of tracking equipment reservations. On change of a reservation event, I call a microflow that checks for overlap of existing reservations on that same piece of equipment, calls "Rollback" if there is an overlap and calls "Commit" if the altered reservation does not overlap an existing operations. For example, if this were rental cars, only one person can reserve a specific car at any one time so, for a specific car, reservations should be non-overlapping. I recently upgraded to both Business Modeler 5.9.1 and to the latest version of the Calendar Widget (released on 10/29/2014). While the detection of overlap seems to be working properly as evidenced by a popup window that I call that says: "Sorry, this reservation overlaps another reservation. This will be rolled back." The actual "Rollback" doesn't seem to be doing anything. I can check the debugger and find that the Start and End properties of the calendar event are the same before and after the rollback step. To the best of my knowledge, there is not another commit that is called other than the one that happens if no overlap is detected. Has anyone else observed a problem with a "Rollback" in Business Modeler 5.9.1? Other than looking at the start and end attributes of the calendar entity in the debugger, are there other diagnostic tools that would help me to resolve this situation? I am pretty certain that the Rollback was working properly with Business Modeler 5.7 and 5.8 with the previous Calendar Widget but I'm having a hard time determining whether this may be a problem with 5.9.1 or possibly an interaction between 5.9.1 and the newest Calendar Widget. Thanks for your consideration, John
asked
1 answers
3

Mendix Community:

Sigh ... I found the source of my problem and it was one of my own making and not a problem with rollback. But, I will share the details here in hopes that someone else my encounter a similar problem and that this may help them to find a mistake.

I had thought that I was making a change to the Start and End of a calendar event, checking to make sure that change was legal (in this case, checking to see that it did not overlap other events) and then either rolling back if it did overlap or commit if it did not.

What I failed to realize was that I was also calculating and storing the new duration of the event (the difference between End and Start expressed in hours). In that Change Object I had accidentally selected the Commit "Yes" rather than the "No" option. As a result, when I later decided that I had an overlap for the new calendar Start and End times, rather than rolling back to the original Start and End times .... which is what I wanted to do ... I was only rolling back the calculated duration amount.

In short, the Rollback was working properly, but that extra "Commit" during the Change Object caused me to roll back only to that last commit rather than to the original Start and End timestamps my entity possessed when I started the Microflow.

So, my bad, mea culpa, stupid me ...

At the very least, I hope that someone else will see this at some point and either avoid creating this problem or at least be able to more quickly identify it.

Thank you,

John

answered