Changes for page Messaging Synchronous

Summary

• Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Title

...	...	@@ -1,1 +1,1 @@
1		-Messaging Synchronous
	1	+intermediate-key-concepts-emagiz-messaging-messaging-synchronous

Content

...	...	@@ -1,7 +1,7 @@
1	1	{{container}}
2	2	{{container layoutStyle="columns"}}
3	3	(((
4		-In this microlearning, we will explain the basics of the synchronous messaging pattern.
	4	+In this microlearning, we will explore what the function of the entry is within the message engine. Furthermore, we will explain why there is no entry queue.
5	5
6	6	Should you have any questions, please get in touch with [[academy@emagiz.com>>mailto:academy@emagiz.com]].
7	7
...	...	@@ -14,37 +14,46 @@
14	14
15	15	== 2. Key concepts ==
16	16
17		-This microlearning centers around the synchronous messaging pattern in eMagiz.
18		-By synchronous, we mean The process that processes data and subsequently informs the caller what the status is.
	17	+This microlearning centers on the concept of entry, not a queue.
19	19
20		-Key characteristics of synchronous messaging are:
	19	+* The key aspects are:
	20	+ * Entry is the starting point of the integration process in messaging
	21	+ * Queues are an internal resource of eMagiz
	22	+ * Outside parties are not allowed to write on eMagiz queues directly
	23	+ * eMagiz facilitates various connectivity methods (i.e., REST, SOAP, Database, File)
21	21
22		-* Blocking. The sender initiates the process and waits for a response before continuing with the following message
23		-* Systems depend on the responses of other systems for their function
24		-* Messages have a time limit. The response needs to be back within 25 seconds (eMagiz default)
25		-* Uses a request-response structure that talks to one system at a time
26	26
27		-== 3. Messaging Synchronous ==
28	28
29		-Synchronous messaging is the less used, the less advised option when implementing a messaging integration via eMagiz. In case you want to learn more about asynchronous messaging, please check out this [microlearning](crashcourse-messaging-messaging-asynchronous.md)
	27	+== 3. Entry, not a queue ==
30	30
31		-Key characteristics of synchronous messaging are:
	29	+In this microlearning, we will explore what the function of the entry is within the message engine. Furthermore, we will explain why there is no entry queue.
32	32
33		-- Blocking. The sender initiates the process and waits for a response before continuing with the following message
34		-- Systems depend on the responses of other systems for their function
35		-- Messages have a time limit. The response needs to be back within 25 seconds (eMagiz default)
36		-- Uses a request-response structure that talks to one system at a time
	31	+* The key aspects are:
	32	+ * Entry is the starting point of the integration process in messaging
	33	+ * Queues are an internal resource of eMagiz
	34	+ * Outside parties are not allowed to write on eMagiz queues directly
	35	+ * eMagiz facilitates various connectivity methods (i.e., REST, SOAP, Database, File)
37	37
38		-With this method, the sending party supplies the data to eMagiz via a push mechanism. eMagiz, in turn, places the data on a queue (in most cases an onramp queue). The subsequent process (the onramp) will process the message and will put the message on the next queue (the synchronous routing). That process will route each message to the correct offramp. This process continues until the message eMagiz delivers to the external system. At that point, eMagiz will wait for a response. If that response is received, the message will travel back to the starting point to deliver the reaction to the caller. If something goes wrong, for example, a timeout, the error message is also given back to the caller, and eMagiz will log the exception. If you want to learn more on that, please check out this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Understanding Error Handling.intermediate-understanding-error-handling-in-emagiz-messaging-synchronous.WebHome||target="blank"]]
	37	+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.
39	39
40		-[[image:Main.Images.Microlearning.WebHome@intermediate-key-concepts-emagiz-messaging-messaging-synchronous--concept.png]]
	39	+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:
41	41
42		-Note that this means that when one message is currently being processed, all other messages have to patiently wait until the message is processed as we speak delivered back to the caller. As there is a time constraint on the messages (25 seconds as eMagiz default), you can see why this option is less suitable within the messaging engine. The most pain is felt in the routing. Just as with asynchronous routing, the synchronous routing processes all synchronous messages that pass through your messaging engine. As a result, this means that when one synchronous process is busy, it can even hold up other synchronous processes. The API Gateway pattern is a more suitable alternative for handling the request-response pattern via an integration platform such as eMagiz. If you want to learn more on that, please check out the [[crashcourse>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.WebHome||target="blank"]].
	41	+* 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
	42	+* This would mean that the external system can only push data to eMagiz (so no polling of data)
	43	+* This would mean that the external system can directly place data on a queue
	44	+* This would create a tightly coupled dependency between the external system and eMagiz
43	43
44		-Another aspect of the synchronous messaging pattern to consider is that the system from which you want to retrieve data (or push data to) based on the request made by the caller needs to be online. If it is not online, eMagiz won't receive a response, and the caller cannot continue their work. This fact creates a dependency between systems that could reduce the perceived reliability of your integration solution. With asynchronous messaging, you could take measures to mitigate these risks, such as a retry mechanism.
	46	+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.
45	45
46		-A third aspect to consider is whether you can set a generic point of entry through which all clients can communicate via eMagiz to many other systems. In those cases, you could look at the API Gateway solution as an alternative to synchronous messaging, as it comes with several benefits. More on the basics of the API Gateway can be found in this [[crashcourse>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.WebHome||target="blank"]].
	48	+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](intermediate-solution-architecture-function-of-h2-database.md).
47	47
	50	+To summarize:
	51	+
	52	+* Entry is the starting point of the integration process in messaging
	53	+* Queues are an internal resource of eMagiz
	54	+* Outside parties are not allowed to write on eMagiz queues directly
	55	+* eMagiz facilitates various connectivity methods (i.e., REST, SOAP, Database, File)
	56	+
48	48	== 4. Assignment ==
49	49
50	50	No assignment accompanies this microlearning.