“An error has occurred, please contact your system administrator”.
When a user sees this standard Mendix error message, our experience is that the notification is ignored, or contacted that something was wrong. The user just has no idea anymore when exactly or why. Helping becomes difficult.
To improve the feedback that the system gives to the user and achieve more informative logging for the developer, we use a fixed pattern for each action from a page. This looks as follows: It starts with an action nanoflow to handle all customer actions. Think of opening a new page, refreshing an object or showing the user a message. Next, we call an action microflow that executes the logical subflow and handles the result including error handling and logging. The result is returned in a specific FlowResult entity to the nanoflow (see Figure 1).
Figure 1
The pattern for each step looks as follows:
Calling action nanoflow from a page
The action nanoflow is called from a page and is given the prefix “Nanoflow Action Call” (NAC). If validation of fields is required, this nanoflow first calls a microflow for validation. We use a microflow for this, so we can unit test the validation. If you don’t work with unit tests, then a sub-nanoflow will also do, of course. A validation flow returns a result that lets you know whether you can perform the follow-up action or not.
Calling action microflow from nanoflow
The action microflow (with the prefix ACT) is given the same rights as the action nanoflow. This microflow creates a FlowResult object and calls the sub microflow with the logic in it (see Figure 2). On this sub microflow the error handling is captured, so that in case of errors we can log and set the FlowResult to unsuccessful. The error message is also put in the FlowResult. Depending on the result, you can then perform the desired follow-up action in the microflow itself or in the action nanoflow.
Sub microflow from action microflow
The sub microflow handles all logic. Objects are modified here, created and deleted, calculations performed, etc. If an unexpected situation arises, we take care of raising an exception ourselves. This is because it is not the desired and expected behaviour of the logic and thus an execption. This way, the action microflow can catch what went wrong and perform the appropriate handling (including logging).
Figure 2
Considerations for the pattern
Contact