Synchronous routing
This microlearning will explain the basics of synchronous routing within the messaging pattern. We will cover the essentials of how synchronous routing operates in the five-layer messaging model, focusing on how it handles messages in real-time and ensures they reach the correct destination.
Should you have any questions, please get in touch with academy@emagiz.com.
1. Prerequisites
- Basic knowledge of the eMagiz platform
2. Key concepts
This microlearning centers around synchronous routing for messaging flows in eMagiz.
- By synchronous routing we mean: The process that routes messages that it receives to the correct outbound queue based on some metadata and waits for a response that needs to be sent back to the original process that delivered the message.
3. Synchronous routing
Synchronous routing plays a crucial role in distributing messages from one onramp to a specific offramp and waiting for the result to be passed back to the onramp again.
The asynchronous routing has four relevant parts:
- All synchronous onramps send their data to the routing
- Based on a decision made within the routing, the message is routed to one of the available offramp queues
- You need to deploy the complete five layers at once to prevent timeouts while deploying half of your solution
- In contrast with asynchronous routing the synchronous routing only has one output tied to an input (instead of a possible one towards many)
If you want to learn more about asynchronous routing instead of synchronous routing, please check out this microlearning. In synchronous routing, you not only route messages towards a certain offramp. On top of that, the routing waits for a response. Subsequently, it will route the message back to the correct onramp from which the message originated. This process happens based on a header value that is automatically determined and set by eMagiz.
3.1 Make a decision
In synchronous routing, you can build your decision model on which the routing needs to decide.
The best practice for setting up your synchronous routing process is to use the value of one of the two standard headers automatically generated in each onramp in eMagiz within the messaging pattern. The header in question is called {technicalnameofproject}\_messageType. You can use this header for your routing decision. This logic means you will need a header value router as the decision point of your synchronous routing.
In the header value router component this will look as follows:
In this simple case, we only have one channel as a result because all routings start simple.
The moment you add new offramps to your project, you need to add the latest entry to this list.
Doing so is easy when you are in Start Editing Mode. Open the router component and select the button New Mapping.
Here, you fill in the correct message type and select the channel you want to route the message.
When you are satisfied, you can press Save, and eMagiz will register the new entry.
Don't forget to make a new version and deploy it to actualize your changes.
3.2 Control output
In contrast to asynchronous routing, you cannot deploy half your solution beforehand, leading to timeouts within the process. To control the output of synchronous routing flows, you should temporarily halt traffic by stopping your flows and communicating a moment of downtime. Afterward, you deploy the last part of your solution (i.e., the exit) first and from there work your way back to the entry. When you deploy your solution like this, you will ensure that the chances of timeouts resulting from deployments are significantly reduced.
3.4 Step by step guide
Furthermore, as a best practice, we give you a short guide to add to your synchronous routing as annotations to ensure that you always know what you need to do to make this a reality.
Steps to follow when adding an integration to the routing:
- In the routing, a header value router should be used as the first building block after receiving the input.
- In this header value router, a header name has to be defined once. The correct notation is {technicalnameofproject}\_messageType
- For every unique value, there is a channel to which the messages need to be sent to
- eMagiz will deliver the response of your message on the correct queue
3.5 The result
The result of setting up your synchronous routing in this manner is that you have one single point of entry, one single piece of decision logic, and a way to control the output per specific output channel.
4. Key takeaways
- Use one component (e.g., a single header value router) that decides the message routing to a specific channel based on metadata.
- Deploy your solution in a smart way by deploying the output channels first and then work backward to prevent timeouts.
- Annotate your routing setup with a step-by-step guide for consistency and easier troubleshooting.
5. Suggested Additional Readings
If you are interested in this topic and want more information, please read the help text provided by eMagiz and see the following links: