Error Handling in Messaging Synchronous
In this microlearning, we will take a look at how error handling works for synchronous messaging flows, a topic we have touched on before with asynchronous error handling. We will explore how synchronous error handling mirrors that of API Gateway flows, and what you need to know about migrating old synchronous flows.
Should you have any questions, please contact academy@emagiz.com.
1. Prerequisites
- Intermediate knowledge of the eMagiz platform
2. Key concepts
This microlearning centers on error handling for synchronous messaging.
Please refer to this microlearning for the basics and key characteristics of synchronous messaging.
3. Messaging Synchronous
In previous microlearnings, we have already explained some things about asynchronous error handling. In this microlearning, we will take a look at how error handling works for synchronous messaging flows. Note that the error handling for synchronous flows mimics the error handling for API Gateway flows as both are synchronous.
- The key aspects are:
- The error handling behaves the same way as for API Gateway
- For old synchronous flows the error handling behaves differently, please migrate
- The client will become responsible for handling the error correctly
- eMagiz will log the exception to provide support
When looking at synchronous messaging flows you will see that the error handling (the lower part of your flow) differs from when you look at the asynchronous error handling. The synchronous error handling is shown below.
What you can see here is that when an error is raised it is given back to the original part of our messaging integration that was calling this part of the messaging integration. As you know messaging is always conducted over five layers (entry, onramp, routing, offramp, exit). This means that when the offramp throws an error (i.e. validation error) he gives the error back to the routing. That flow will in turn give back the error to the onramp. This process continues to the entry. At that point, you should send the error back to the client so they can properly handle the error.
Apart from giving back the error to the previous step eMagiz will also log the exception so it can be used to analyze further. This is done via the following setting on the error to the XML component. This way the client can be supported by someone who has access to eMagiz to figure out what went wrong.
As you can imagine there is another part of the flow needed to ensure that an error does not cause another error when it arrives in the previous step. To prevent this from happening an additional check is introduced that filters error messages. In case the message is an error message it will bypass the functional part of the flow and will be directly sent back to the previous step. This is to prevent an error on an error.
Please note that we have changed the way the error handling works for synchronous flows in 2020. This means that probably not all synchronous flows have been migrated to make use of this new functionality. In case you are interested in migrating please check out this migration path.
Hopefully, this microlearning has made it somewhat clearer how to handle errors when dealing with synchronous messaging flows.
4. Key takeaways
- Error handling for synchronous messaging flows is similar to that for API Gateway flows.
- Legacy synchronous flows may have different error handling mechanisms. Migration to the updated approach is recommended.
- The client is responsible for managing and responding to errors correctly.
- eMagiz will log exceptions to assist in troubleshooting and support.
5. Suggested Additional Readings
If you are interested in this topic and want more information on it please read the help text provided by eMagiz and read the following link: