Wiki source code of Asynchronous Routing
Show last authors
author | version | line-number | content |
---|---|---|---|
1 | {{container}}{{container layoutStyle="columns"}}((( | ||
2 | In this microlearning, we will explain the basics of asynchronous routing that plays a vital role in the distribution of messages within the five-layer model of messaging. | ||
3 | |||
4 | Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]]. | ||
5 | |||
6 | * Last update: February 25th, 2021 | ||
7 | * Required reading time: 7 minutes | ||
8 | |||
9 | == 1. Prerequisites == | ||
10 | |||
11 | * Basic knowledge of the eMagiz platform | ||
12 | |||
13 | == 2. Key concepts == | ||
14 | |||
15 | This microlearning centers around asynchronous routing for messaging flows in eMagiz. | ||
16 | By asynchronous routing we mean: The process that routes messages that it receives to the correct outbound queue based on some metadata. | ||
17 | |||
18 | The asynchronous routing has three relevant parts: | ||
19 | |||
20 | * All asynchronous onramps send their data to the routing | ||
21 | * Based on a decision made within the routing the message is routed to one or more offramp queues | ||
22 | * Each offramp queue will receive data based on the decision unless you add another filter before the messages are sent to the offramp queue | ||
23 | |||
24 | == 3. Asynchronous routing == | ||
25 | |||
26 | Asynchronous routing plays a crucial role in the distribution of messages it receives to one or more offramps. | ||
27 | |||
28 | The asynchronous routing has three relevant parts: | ||
29 | |||
30 | * All asynchronous onramps send their data to the routing | ||
31 | * Based on a decision made within the routing the message is routed to one or more offramp queues | ||
32 | * Each offramp queue will receive data based on the decision unless you add another filter before the messages are sent to the offramp queue | ||
33 | |||
34 | === 3.1 Make a decision === | ||
35 | |||
36 | In asynchronous routing, you can build your decision model on which the routing needs to make the decision. | ||
37 | |||
38 | The best practice for setting up your asynchronous routing process is to use one SpEL expression that determines to which offramp queues a messages needs to be routed. | ||
39 | The SpEL expression looks as follows: | ||
40 | |||
41 | headers.{technicalnameofproject}\_targetSystem.split(',').![#this.trim()+#root.headers.{technicalnameofproject}_messageType] | ||
42 | |||
43 | This SpEL expression does the following things: | ||
44 | |||
45 | 1. It looks for the header called {technicalnameofproject}\_targetSystem and will split each entry based on the separator (a comma) | ||
46 | 2. It will trim the result of this split and combine it the value in the header called {technicalnameofproject}\_messageType | ||
47 | 3. For every unique combination it will search to a pre-configured list to see to which channel the message should be sent | ||
48 | |||
49 | In the standard router component this will look as follows: | ||
50 | |||
51 | [[image:Main.Images.Microlearning.WebHome@crashcourse-messaging-asynchronous-routing--routing-decision.png]] | ||
52 | |||
53 | In this simple case, we only have one channel as a result because all routings start simple. | ||
54 | The moment you add new offramps to your project you need to add the new entry(s) to this list. | ||
55 | Doing so is easy when you are in Start Editing Mode. Simply open the router component and select the button New Mapping | ||
56 | |||
57 | [[image:Main.Images.Microlearning.WebHome@crashcourse-messaging-asynchronous-routing--new-value-mapping.png]] | ||
58 | |||
59 | In here you fill in the correct unique combination of a target system and the message type and select the channel you want to route the message to. | ||
60 | When you are satisfied you can press Save and the new entry will be registered in eMagiz. | ||
61 | |||
62 | Don't forget to make a new version and deploy it to actualize your changes. | ||
63 | |||
64 | === 3.2 Control output === | ||
65 | |||
66 | As the asynchronous plays a role in routing messages between all asynchronous flows in a | ||
67 | the messaging solution you can imagine that making changes does not need to happen lightly. | ||
68 | The other aspect is that when multiple projects are being built at the same time the asynchronous routing | ||
69 | will house a multitude of changes that need to go to Acceptance or Production at the same time. | ||
70 | |||
71 | One control mechanism we consider a best practice to guard yourself against those risks is to add a filter | ||
72 | before data is placed on the offramp queue. | ||
73 | By doing this consistently you can control when a specific offramp can receive data on any environment. | ||
74 | In other words, when a certain system is not ready yet to receive data on Acceptance or Production but is ready on Test | ||
75 | you can control this behavior with this solution. | ||
76 | |||
77 | Below you see how this will look on flow level. | ||
78 | |||
79 | [[image:Main.Images.Microlearning.WebHome@crashcourse-messaging-asynchronous-routing--filter-construction.png]] | ||
80 | |||
81 | When we zoom in on the filter component we see a simple SpEL expression that checks the value of a certain property. | ||
82 | When the value of the property is true the message can pass. If the value of the property is any other value the message will be halted. | ||
83 | The best practice would be to work with false to get clarity on what the intended use of the property value is. | ||
84 | |||
85 | [[image:Main.Images.Microlearning.WebHome@crashcourse-messaging-asynchronous-routing--filter-configuration.png]] | ||
86 | |||
87 | === 3.4 Step by step guide === | ||
88 | |||
89 | Furthermore, as a best practice, we give you a short guide that you can add to your asynchronous routing as annotations | ||
90 | to ensure that you always know what you need to do to make this a reality. | ||
91 | |||
92 | Steps to follow when adding an integration to the routing Part I: | ||
93 | |||
94 | 1. Add a header in the onramp named {technicalnameofproject}\_targetSystem (if this is not done yet) | ||
95 | 2. Fill this header with a value that should be defined as a property (naming convention = systemname.messagetype.targetsystems) | ||
96 | 3. This property should be created in Test, Accp, and Prod and filled with all target systems for a certain message type (notation = systemname1,systemname2,systemname3) | ||
97 | 4. In the routing a standard router should be used as the first building block after receiving the input. | ||
98 | |||
99 | Part II | ||
100 | |||
101 | 5. In this standard router a SpelExpression has to be defined **once** that concatenates the following headers: {technicalnameofproject}\_targetSystem and {technicalnameofproject}\_messageType. | ||
102 | 6. For every unique combination there is a value that should be specified alongside the channel on which to put the message (this should be a channel that ultimately leads to the correct offramp queue) | ||
103 | 7. For every channel that leads to a JMS outbound channel adapter a filter needs to be added to make sure that each output option can be turned on or off easily. | ||
104 | This to prevent that messages are sent to a system that does not expect them then | ||
105 | 8 This filter should look like this: '${routing.monitor.detorem.enabled}' == 'true'. | ||
106 | The naming convention of said property is routing.targetsystem.messagetype.enabled. | ||
107 | |||
108 | === 3.5 The result === | ||
109 | |||
110 | The result of setting up your asynchronous routing in this manner | ||
111 | is that you have one single point of entry, one single piece of decision logic, and a way to control the output per specific output channel. | ||
112 | |||
113 | [[image:Main.Images.Microlearning.WebHome@crashcourse-messaging-asynchronous-routing--simple-asynchronous-routing-example.png]] | ||
114 | |||
115 | |||
116 | == 4. Assignment == | ||
117 | |||
118 | Build your asynchronous routing based on the best practice for one of the offramps that are available within your (Academy) project. | ||
119 | This assignment can be completed with the help of your (Academy) project you have created/used in the previous assignment. | ||
120 | |||
121 | == 5. Key takeaways == | ||
122 | |||
123 | * Use one component that decides to route messages to certain channels | ||
124 | * Control the output with a filter to prevent data to be sent to a queue too early | ||
125 | * Use the annotations to write down the step by step guide within your asynchronous routing | ||
126 | |||
127 | == 6. Suggested Additional Readings == | ||
128 | |||
129 | If you are interested in this topic and want more information on it please read the help text provided by eMagiz. | ||
130 | |||
131 | == 7. Silent demonstration video == | ||
132 | |||
133 | This video demonstrates how you could have handled the assignment and gives you some context on what you have just learned. | ||
134 | |||
135 | {{video attachment="crashcourse-messaging-asynchronous-routing.mp4" reference="Main.Videos.Microlearning.WebHome"/}} | ||
136 | |||
137 | )))((({{toc/}}))){{/container}}{{/container}} |