Skip to Content
Last modified by Danniar Firdausy on 2023/08/11 11:14
From version 4.1
edited by Erik Bakker
on 2022/08/23 10:02
Change comment: There is no comment for this version
To version 15.1
edited by Danniar Firdausy
on 2023/08/11 10:59
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Messaging Synchronous
1 +Create Synchronous Messaging
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.ebakker
1 +XWiki.dfirdausy
Default language
... ... @@ -1,0 +1,1 @@
1 +en
Content
... ... @@ -1,72 +1,31 @@
1 1  {{container}}
2 -{{container layoutStyle="columns"}}
3 -(((
4 -In this microlearning, we will explain the basics of the synchronous messaging pattern.
2 +{{container layoutStyle="columns"}}(((
3 +In this exercise, we will guide you to create a simple synchronous messaging pattern based on the previous microlearnings.
5 5  
6 6  Should you have any questions, please get in touch with [[academy@emagiz.com>>mailto:academy@emagiz.com]].
7 7  
8 -* Last update: August 5th, 2021
9 -* Required reading time: 5 minutes
10 -
11 11  == 1. Prerequisites ==
12 12  
13 -* Intermediate knowledge of the eMagiz platform
9 +* Completed the previous microlearnings of this intermediate course.
14 14  
15 -== 2. Key concepts ==
11 +== 2. Exercise ==
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.
13 +Below, the exercise for this part of the intermediate course, which centers around the synchronous messaging pattern in eMagiz, is given. By synchronous, we mean the process that processes data and then subsequently informs the caller what the status is.
19 19  
20 -Key characteristics of synchronous messaging are:
15 +=== 2.1. Creating Synchronous Messaging ===
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
17 +In the previous microlearnings, we have learned what synchronous messaging is, what the key characteristics are, what might be the use case, what its difference is from the asynchronous counterpart, and what methods of connectivity are supported (i.e., REST, SOAP, Database, File). In this exercise, we will practice how to construct synchronous messaging within eMagiz.
26 26  
27 -== 3. Messaging Synchronous ==
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)
30 -
31 -Key characteristics of synchronous messaging are:
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
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"]]
39 -
19 +As a target practice, try to construct a synchronous messaging that refers to this architecture below, with inbound and outbound adapters of your preference:
20 +
40 40  [[image:Main.Images.Microlearning.WebHome@intermediate-key-concepts-emagiz-messaging-messaging-synchronous--concept.png]]
22 +
23 +== 3. Solution ==
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"]].
25 +In this short movie, you will find the workout of this exercise. Take a moment to review this one and compare it to your solution. As an example, we use HTTP inbound and outbound gateway here in this exercise.
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.
27 +{{video attachment="Exercises - Intermediate - Key Concepts eMagiz Messaging [Create].mp4" reference="Main.Videos.Microlearning.WebHome"/}}
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"]].
47 -
48 -== 4. Assignment ==
49 -
50 -No assignment accompanies this microlearning.
51 -
52 -== 5. Key takeaways ==
53 -
54 -* The key aspects are:
55 - * Entry is the starting point of the integration process in messaging
56 - * Queues are an internal resource of eMagiz
57 - * Outside parties are not allowed to write on eMagiz queues directly
58 - * eMagiz facilitates various connectivity methods (i.e., REST, SOAP, Database, File)
59 -
60 -
61 -
62 -== 6. Suggested Additional Readings ==
63 -
64 -If you are interested in this topic, please boost your knowledge with the help of the internet.
65 -
66 -== 7. Silent demonstration video ==
67 -
68 -As this is a more theoretical microlearning, we have no video for this.
69 -
70 70  )))
71 71  
72 72  ((({{toc/}}))){{/container}}