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}} |