Wiki source code of Asynchronous Routing

Version 19.1 by Erik Bakker on 2022/08/15 08:03

version	line-number	content
16.1	1	{{container}}{{container layoutStyle="columns"}}(((
1.1	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
16.1	4	Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
1.1	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	1. It looks for the header called {technicalnameofproject}\_targetSystem and will split each entry based on the separator (a comma)
	43	2. It will trim the result of this split and combine it the value in the header called {technicalnameofproject}\_messageType
	44	3. 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
16.1	48	[[image:Main.Images.Microlearning.WebHome@crashcourse-messaging-asynchronous-routing--routing-decision.png]]
1.1	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
16.1	54	[[image:Main.Images.Microlearning.WebHome@crashcourse-messaging-asynchronous-routing--new-value-mapping.png]]
1.1	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
16.1	76	[[image:Main.Images.Microlearning.WebHome@crashcourse-messaging-asynchronous-routing--filter-construction.png]]
1.1	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
16.1	82	[[image:Main.Images.Microlearning.WebHome@crashcourse-messaging-asynchronous-routing--filter-configuration.png]]
1.1	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
16.1	110	[[image:Main.Images.Microlearning.WebHome@crashcourse-messaging-asynchronous-routing--simple-asynchronous-routing-example.png]]
1.1	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
16.1	132	{{video attachment="crashcourse-messaging-asynchronous-routing.mp4" reference="Main.Videos.Microlearning.WebHome"/}}
1.1	133
16.1	134	)))((({{toc/}}))){{/container}}{{/container}}

Wiki source code of Asynchronous Routing

Navigation