Entry, not a queue
In this microlearning, we will explore the role of the "entry" in the eMagiz message engine. You will learn why there is no entry queue and how eMagiz facilitates connectivity between external systems and internal queues. By the end, you will gain a deeper understanding of how entries initiate the integration process and ensure smooth data flow.
Should you have any questions, please get in touch with academy@emagiz.com.
1. Prerequisites
- Intermediate knowledge of the eMagiz platform
2. Key concepts
This microlearning centers on the concept of entry, not a queue. The key aspects of entry flows are:
- Entry is the starting point of the integration process in messaging
- Queues are an internal resource of eMagiz
- Outside parties are not allowed to write on eMagiz queues directly
- eMagiz facilitates various connectivity methods (i.e., REST, SOAP, Database, File)
3. Entry, not a queue
As you learned from the introductory course on messaging, we use a five-layer approach to handle data within the messaging engine. The first layer the data encounters is the entry. The goal of the entry is twofold. One is to establish a connection with an external system. The other is to place data on a queue. There are two ways to establish connectivity. The first method is via a pull mechanism. This pull mechanism means that eMagiz will initiate the communication to retrieve data. The second method is a push mechanism. This push mechanism means that eMagiz will patiently wait till the external system offers data to eMagiz. The push mechanism will typically be realized with the help of a hosted web service (REST or SOAP) within your eMagiz solution.
Since the goal of the entry is connectivity between the external system and eMagiz, you could argue that it would be easy to let them place the data on the queue. However, things are not that easy. There are several reasons why this is not a best practice:
- This would mean that the external system directly needs to connect to the infra layer (the JMS) and will have the option to read and write on other queues as well
- This would mean that the external system can only push data to eMagiz (so no polling of data)
- This would mean that the external system can directly place data on a queue
- This would create a tightly coupled dependency between the external system and eMagiz
The above arguments concluded that the connectivity between eMagiz and the external system and the internal queue mechanism of eMagiz should be considered two separate things. This conclusion did raise a question on how eMagiz can guarantee message delivery. The messaging engine uses queues to ensure message delivery. But what if the first queue (the onramp queue) cannot be reached? What happens then.
The H2 database is introduced to safeguard against any problems within the entry. This component is generated in every entry in eMagiz. This H2 database will temporarily store data and act as a bridge between the entry and the onramp queue. This way, eMagiz can guarantee message delivery. If you want to learn more about the function of the H2 database, please check out this microlearning.
To summarize:
- Entry is the starting point of the integration process in messaging
- Queues are an internal resource of eMagiz
- Outside parties are not allowed to write on eMagiz queues directly
- eMagiz facilitates various connectivity methods (i.e., REST, SOAP, Database, File)
4. Key takeaways
- Entry is the initial step of the integration process in eMagiz messaging, establishing a connection between external systems and the platform.
- Queues are an internal resource within eMagiz and are used to manage the flow and delivery of messages reliably.
- External systems are not allowed direct access to eMagiz queues, ensuring separation between external connectivity and internal processing for security and flexibility.
- eMagiz offers multiple connectivity options (e.g., REST, SOAP, Database, File) to interact with external systems, while maintaining control over data flow within the platform.
- The H2 database acts as a safeguard within the entry, temporarily storing data to guarantee message delivery if the onramp queue is unavailable.
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 links: