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