Changes for page Asynchronous Routing

Summary

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

Details

Page properties

Title

...	...	@@ -1,1 +1,1 @@
1		-crashcourse-messaging-asynchronous-routing
	1	+Asynchronous Routing

Default language

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

Content

...	...	@@ -1,13 +1,8 @@
1	1	{{container}}{{container layoutStyle="columns"}}(((
2		-= Asynchronous Routing =
3		-
4	4	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.
5	5
6	6	Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
7	7
8		-* Last update: February 25th, 2021
9		-* Required reading time: 7 minutes
10		-
11	11	== 1. Prerequisites ==
12	12
13	13	* Basic knowledge of the eMagiz platform
...	...	@@ -23,8 +23,6 @@
23	23	* Based on a decision made within the routing the message is routed to one or more offramp queues
24	24	* Each offramp queue will receive data based on the decision unless you add another filter before the messages are sent to the offramp queue
25	25
26		-
27		-
28	28	== 3. Asynchronous routing ==
29	29
30	30	Asynchronous routing plays a crucial role in the distribution of messages it receives to one or more offramps.
...	...	@@ -46,9 +46,9 @@
46	46
47	47	This SpEL expression does the following things:
48	48
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
	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
52	52
53	53	In the standard router component this will look as follows:
54	54
...	...	@@ -95,19 +95,17 @@
95	95
96	96	Steps to follow when adding an integration to the routing Part I:
97	97
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.
	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.
102	102
103	103	Part II
104	104
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.
	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.
111	111
112	112	=== 3.5 The result ===
113	113
...	...	@@ -117,7 +117,6 @@
117	117	[[image:Main.Images.Microlearning.WebHome@crashcourse-messaging-asynchronous-routing--simple-asynchronous-routing-example.png]]
118	118
119	119
120		-
121	121	== 4. Assignment ==
122	122
123	123	Build your asynchronous routing based on the best practice for one of the offramps that are available within your (Academy) project.
...	...	@@ -129,8 +129,6 @@
129	129	* Control the output with a filter to prevent data to be sent to a queue too early
130	130	* Use the annotations to write down the step by step guide within your asynchronous routing
131	131
132		-
133		-
134	134	== 6. Suggested Additional Readings ==
135	135
136	136	If you are interested in this topic and want more information on it please read the help text provided by eMagiz.