Skip to Content

Changes for page Messaging Synchronous

Last modified by Danniar Firdausy on 2024/09/16 13:37
From version 13.12
edited by Danniar Firdausy
on 2024/09/16 13:34
Change comment: There is no comment for this version
To version 13.5
edited by Danniar Firdausy
on 2024/09/16 13:28
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -1,7 +1,7 @@
1 1  {{container}}
2 2  {{container layoutStyle="columns"}}
3 3  (((
4 -In this microlearning, we will introduce you to the basics of the synchronous messaging pattern within the eMagiz platform. You will gain an understanding of how this pattern operates, its key characteristics, and when it may or may not be the best choice for your integrations.
4 +In this microlearning, we will explain the basics of the synchronous messaging pattern.
5 5  
6 6  Should you have any questions, please get in touch with [[academy@emagiz.com>>mailto:academy@emagiz.com]].
7 7  
... ... @@ -36,11 +36,11 @@
36 36  
37 37  [[image:Main.Images.Microlearning.WebHome@intermediate-key-concepts-emagiz-messaging-messaging-synchronous--concept.png]]
38 38  
39 -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 [[crash course>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.WebHome||target="blank"]].
39 +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"]].
40 40  
41 41  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.
42 42  
43 -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 [[crash course>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.WebHome||target="blank"]].
43 +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"]].
44 44  
45 45  === 3.1 Practical use case ===
46 46  
... ... @@ -53,7 +53,6 @@
53 53  === 3.2 Asynchronous vs Synchronous ===
54 54  
55 55  The decision to handle an integration process in a specific manner depends on various relevant business and technical checks and balances that should be answered before choosing which integration pattern to choose and then subsequently which alternative method within an integration pattern to choose. If you want more information on how to decide this correctly, please check out this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Discover your integration landscape.intermediate-discover-your-integration-landscape-determining-integration-pattern||target="blank"]].
56 -
57 57  {{html}}
58 58  <!--
59 59  
... ... @@ -64,15 +64,15 @@
64 64  
65 65  -->
66 66  {{/html}}
67 -
68 68  == 4. Key takeaways ==
69 69  
70 -* Key characteristics of synchronous messaging include:
71 -** Blocking: The sender must wait for a response before proceeding with the next message.
72 -** System dependency: Systems rely on timely responses from others to function effectively.
73 -** Time constraints: Messages have a time limit (25 seconds by default in eMagiz) for receiving a response.
74 -** Request-response structure: Each request is handled by one system at a time.
75 -* The API Gateway pattern is often a better alternative when handling synchronous communication, as it offers more flexibility and mitigates some of the challenges associated with synchronous messaging.
68 +* Synchronous messaging is the less used, the less advised option when implementing a messaging integration via eMagiz
69 +* Key characteristics of synchronous messaging are:
70 + ** Blocking. The sender initiates the process and waits for a response before continuing with the following message
71 + ** Systems depend on the responses of other systems for their function
72 + ** Messages have a time limit. The response needs to be back within 25 seconds (eMagiz default)
73 + ** Uses a request-response structure that talks to one system at a time
74 +* Using the API Gateway pattern can be a valid alternative when dealing with a synchronous integration demand.
76 76  
77 77  == 5. Suggested Additional Readings ==
78 78  
... ... @@ -81,7 +81,6 @@
81 81  * [[Crash Course (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.WebHome||target="blank"]]
82 82  ** [[Crash Course Messaging (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Messaging.WebHome||target="blank"]]
83 83  *** [[Messaging Asynchronous (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Messaging.crashcourse-messaging-messaging-asynchronous||target="blank"]]
84 -** [[Crash Course API Gateway (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.WebHome||target="blank"]]
85 85  * [[Intermediate Level (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.WebHome||target="blank"]]
86 86  ** [[Discover your integration landscape (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Discover your integration landscape.WebHome||target="blank"]]
87 87  *** [[Determining Integration Pattern (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Discover your integration landscape.intermediate-discover-your-integration-landscape-determining-integration-pattern||target="blank"]]