Preventive actions based on error message
In a previous microlearning, we explored how to identify the cause of a single error message. This time, we will shift our focus to handling multiple error messages. When errors accumulate, addressing them individually may not be sufficient. Instead, it is crucial to look at preventive measures to tackle recurring issues. For example, if only part of an integrated solution is deployed, it can lead to numerous errors due to a common, preventable mistake. In this microlearning, we will discuss strategies for identifying and addressing the root causes of multiple errors to enhance your eMagiz solution.
Should you have any questions, please get in touch with academy@emagiz.com.
1. Prerequisites
- Advanced knowledge of the eMagiz platform
- Errors in the log that can be analyzed
2. Key concepts
This microlearning centers around preventive action based on error message
- By preventative measure, we mean: Figuring out what was responsible for generating all those errors and determining what could solve that problem.
3. Preventive action based on error message
In an earlier microlearning, we discussed determining the cause of a single error message. In that microlearning, we focused on the RCA of one single error message. However, there might be situations in which there is not one message that goes wrong but many error messages. Only solving them on an individual basis might not be enough. In those cases, you want to think about specific preventive actions that could be taken to prevent those mistakes from happening again. One example is that a complete integration has undergone changes, but only part of the solution is deployed in a specific environment. This will undoubtedly lead to loads of errors in which one common, preventable mistake is the cause.
- Search for a common denominator that explains (all) errors
- Determine whether the fix is platform or process-related
- Implement the fix to improve your eMagiz solution further
In the example described above, the fault most likely lies within the process itself. Several individuals worked on the integration within the team but failed to communicate correctly, resulting in half a solution in that particular environment. As a result, there was a mismatch between both parts of the integration in eMagiz. This led to errors in the platform. If you would perform a retest based on one error message, you would probably conclude that in Create, the solution works as expected when running a flow test.
That realization should lead you to conclude that Create is not the same as what is currently running in that environment. That, in turn, should be a trigger to start asking questions, to yourself and others, of what went wrong leading up to this mismatch.
In other cases, the deployment resulted in deploying the correct version of everything within the integration. However, as a result, there are still errors that are being thrown on the environment. Once again, the event that leads to the problems is a deployment. However, the cause of the errors is most likely quite different. By first checking the Manage>Dashboard, you can quickly see whether all (or at least most) errors are raised within a single flow (or comparable flows). You can already learn a lot about the underlying cause of the problem, especially if you start to zoom in to verify if the same component within that flow raises all the errors. Having that information is critical in determining whether multiple mistakes have the same cause or not.
The underlying cause could be that two individuals have tested their solution to a tee, determining that their solution works. However, they failed to test whether the changed process A still works against the changed process B. As a result, one of the processes needs a change in Create to align it with the other process to make the complete integration work again. After executing that change, a second deployment is necessary to test if this resolves the previously raised errors.
As you can see, due to the dependencies between several flows and even parts of flows that ultimately ensure that data is sent from A to B, finding the root cause of your error messages can be challenging. However, doing nothing about these errors is no option as that would hurt the quality of the solution you deliver.
Hopefully, this microlearning has made the thought process you can follow to analyze large volumes of error messages somewhat more clear to you.
4. Key takeaways
- Look for patterns or common denominators among multiple error messages to determine the root cause.
- Assess whether the solution requires adjustments to the platform or the processes involved.
- Apply targeted fixes to address the underlying issues and enhance the overall quality of your eMagiz solution.
5. Suggested Additional Readings
If you are interested in this topic please read the help text eMagiz provides you and see the following link: