Changes for page Asynchronous Routing

Summary

• Page properties (4 modified, 0 added, 0 removed)

Details

Page properties

Title

...	...	@@ -1,1 +1,0 @@
1		-Asynchronous Routing

Parent

...	...	@@ -1,1 +1,0 @@
1		-WebHome

Default language

...	...	@@ -1,1 +1,0 @@
1		-en

Content

...	...	@@ -1,8 +1,13 @@
1	1	{{container}}{{container layoutStyle="columns"}}(((
	2	+= Asynchronous Routing =
	3	+
2	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	3
4	4	Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
5	5
	8	+* Last update: February 25th, 2021
	9	+* Required reading time: 7 minutes
	10	+
6	6	== 1. Prerequisites ==
7	7
8	8	* Basic knowledge of the eMagiz platform
...	...	@@ -18,6 +18,8 @@
18	18	* Based on a decision made within the routing the message is routed to one or more offramp queues
19	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	20
	26	+
	27	+
21	21	== 3. Asynchronous routing ==
22	22
23	23	Asynchronous routing plays a crucial role in the distribution of messages it receives to one or more offramps.
...	...	@@ -39,9 +39,9 @@
39	39
40	40	This SpEL expression does the following things:
41	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
	49	+1. It looks for the header called {technicalnameofproject}\_targetSystem and will split each entry based on the separator (a comma)
	50	+2. It will trim the result of this split and combine it the value in the header called {technicalnameofproject}\_messageType
	51	+3. For every unique combination it will search to a pre-configured list to see to which channel the message should be sent
45	45
46	46	In the standard router component this will look as follows:
47	47
...	...	@@ -88,17 +88,19 @@
88	88
89	89	Steps to follow when adding an integration to the routing Part I:
90	90
91		-* Add a header in the onramp named {technicalnameofproject}\_targetSystem (if this is not done yet)
92		-* Fill this header with a value that should be defined as a property (naming convention = systemname.messagetype.targetsystems)
93		-* 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		-* In the routing a standard router should be used as the first building block after receiving the input.
	98	+1. Add a header in the onramp named {technicalnameofproject}\_targetSystem (if this is not done yet)
	99	+2. Fill this header with a value that should be defined as a property (naming convention = systemname.messagetype.targetsystems)
	100	+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)
	101	+4. In the routing a standard router should be used as the first building block after receiving the input.
95	95
96	96	Part II
97	97
98		-* In this standard router a SpelExpression has to be defined **once** that concatenates the following headers: {technicalnameofproject}\_targetSystem and {technicalnameofproject}\_messageType.
99		-* 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		-* 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. This to prevent that messages are sent to a system that does not expect them then
101		-* This filter should look like this: '${routing.monitor.detorem.enabled}' == 'true'. The naming convention of said property is routing.targetsystem.messagetype.enabled.
	105	+5. In this standard router a SpelExpression has to be defined **once** that concatenates the following headers: {technicalnameofproject}\_targetSystem and {technicalnameofproject}\_messageType.
	106	+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)
	107	+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.
	108	+ This to prevent that messages are sent to a system that does not expect them then
	109	+ 8 This filter should look like this: '${routing.monitor.detorem.enabled}' == 'true'.
	110	+ The naming convention of said property is routing.targetsystem.messagetype.enabled.
102	102
103	103	=== 3.5 The result ===
104	104
...	...	@@ -108,6 +108,7 @@
108	108	[[image:Main.Images.Microlearning.WebHome@crashcourse-messaging-asynchronous-routing--simple-asynchronous-routing-example.png]]
109	109
110	110
	120	+
111	111	== 4. Assignment ==
112	112
113	113	Build your asynchronous routing based on the best practice for one of the offramps that are available within your (Academy) project.
...	...	@@ -119,6 +119,8 @@
119	119	* Control the output with a filter to prevent data to be sent to a queue too early
120	120	* Use the annotations to write down the step by step guide within your asynchronous routing
121	121
	132	+
	133	+
122	122	== 6. Suggested Additional Readings ==
123	123
124	124	If you are interested in this topic and want more information on it please read the help text provided by eMagiz.