Skip to Content

Changes for page Messaging Synchronous

Last modified by Danniar Firdausy on 2024/09/16 13:37
From version 13.13
edited by Danniar Firdausy
on 2024/09/16 13:36
Change comment: There is no comment for this version
To version 13.14
edited by Danniar Firdausy
on 2024/09/16 13:37
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -21,19 +21,12 @@
21 21  * Messages have a time limit. The response needs to be back within 25 seconds (eMagiz default)
22 22  * Uses a request-response structure that talks to one system at a time
23 23  
24 +{{info}}In case you want to learn more about asynchronous messaging, please check out this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Messaging.crashcourse-messaging-messaging-asynchronous||target="blank"]].{{/info}}
25 +
24 24  == 3. Messaging Synchronous ==
25 25  
26 -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>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Messaging.crashcourse-messaging-messaging-asynchronous||target="blank"]].
28 +Synchronous messaging is the less used, the less advised option when implementing a messaging integration via eMagiz. With this approach, 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||target="blank"]].
27 27  
28 -Key characteristics of synchronous messaging are:
29 -
30 -* Blocking. The sender initiates the process and waits for a response before continuing with the following message
31 -* Systems depend on the responses of other systems for their function
32 -* Messages have a time limit. The response needs to be back within 25 seconds (eMagiz default)
33 -* Uses a request-response structure that talks to one system at a time
34 -
35 -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||target="blank"]].
36 -
37 37  [[image:Main.Images.Microlearning.WebHome@intermediate-key-concepts-emagiz-messaging-messaging-synchronous--concept.png]]
38 38  
39 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"]].