Changes for page Asynchronous Routing

Summary

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

Details

Page properties

Author

...	...	@@ -1,1 +1,1 @@
1		-XWiki.ebakker
	1	+XWiki.dfirdausy

Content

...	...	@@ -1,7 +1,7 @@
1	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.
	2	+In this microlearning, we will dive into the essentials of asynchronous routing and its importance in managing message distribution within the five-layer messaging model. We will cover the key concepts, including how to route messages efficiently and manage output control.
3	3
4		-Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
	4	+If you have any questions along the way, feel free to reach out to us at [[academy@emagiz.com>>mailto:academy@emagiz.com]].
5	5
6	6	== 1. Prerequisites ==
7	7
...	...	@@ -10,32 +10,27 @@
10	10	== 2. Key concepts ==
11	11
12	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.
	13	+* With asynchronous routing we mean: The process that routes messages that it receives to the correct outbound queue based on some metadata.
14	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	21	== 3. Asynchronous routing ==
22	22
23		-Asynchronous routing plays a crucial role in the distribution of messages it receives to one or more offramps.
	17	+Asynchronous routing plays a crucial role in the distribution of messages it receives to one or more offramps. In eMagiz, the asynchronous routing has three relevant parts:
24	24
25		-The asynchronous routing has three relevant parts:
	19	+* All asynchronous onramps that send data to the routing.
	20	+* Based on a decision made within the routing the message is routed to one or more offramp queues.
	21	+* Each offramp queue will receive data based on the decision unless you add another filter before the messages are sent to the offramp queue.
26	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	31	=== 3.1 Make a decision ===
32	32
33	33	In asynchronous routing, you can build your decision model on which the routing needs to make the decision.
34	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:
	27	+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. The SpEL expression looks as follows:
37	37
	29	+{{code language="xml"}}
	30	+
38	38	headers.{technicalnameofproject}\_targetSystem.split(',').![#this.trim()+#root.headers.{technicalnameofproject}_messageType]
	32	+
	33	+{{/code}}
39	39
40	40	This SpEL expression does the following things:
41	41
...	...	@@ -60,16 +60,10 @@
60	60
61	61	=== 3.2 Control output ===
62	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.
	58	+As the asynchronous routing plays a role in routing messages between all asynchronous flows in the messaging solution you can imagine that making changes does not need to happen lightly. The other aspect is that when multiple projects are being built at the same time the asynchronous routing will house a multitude of changes that need to go to Acceptance or Production at the same time.
67	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.
	60	+One control mechanism we consider a best practice to guard yourself against those risks is to add a filter before data is placed on the offramp queue.
	61	+By doing this consistently you can control when a specific offramp can receive data on any environment. In other words, when a certain system is not ready yet to receive data on Acceptance or Production but is ready on Test you can control this behavior with this solution.
73	73
74	74	Below you see how this will look on flow level.
75	75
...	...	@@ -88,19 +88,17 @@
88	88
89	89	Steps to follow when adding an integration to the routing Part I:
90	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.
	80	+* Add a header in the onramp named {technicalnameofproject}\_targetSystem (if this is not done yet)
	81	+* Fill this header with a value that should be defined as a property (naming convention = systemname.messagetype.targetsystems)
	82	+* 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)
	83	+* 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		-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.
	87	+* In this standard router a SpelExpression has to be defined **once** that concatenates the following headers: {technicalnameofproject}\_targetSystem and {technicalnameofproject}\_messageType.
	88	+* 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)
	89	+* 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
	90	+* This filter should look like this: '${routing.monitor.detorem.enabled}' == 'true'. The naming convention of said property is routing.targetsystem.messagetype.enabled.
104	104
105	105	=== 3.5 The result ===
106	106
...	...	@@ -110,25 +110,21 @@
110	110	[[image:Main.Images.Microlearning.WebHome@crashcourse-messaging-asynchronous-routing--simple-asynchronous-routing-example.png]]
111	111
112	112
113		-== 4. Assignment ==
	100	+== 4. Key takeaways ==
114	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.
	102	+* Use a single component to determine how messages are routed to different channels.
	103	+* Implement filters to manage when data is sent to each queue, ensuring messages are only routed when appropriate.
	104	+* Use the annotations within your asynchronous routing setup to document and maintain clarity of the configuration.
117	117
118		-== 5. Key takeaways ==
	106	+== 5. Suggested Additional Readings ==
119	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
	108	+If you are interested in this topic and want more information on it please read the help text provided by eMagiz and read the following link:
123	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		-
	110	+* [[Store (Menu)>>doc:Main.eMagiz Store.WebHome||target="blank"]]
	111	+** [[Accelerators (Navigation)>>doc:Main.eMagiz Store.Accelerators.WebHome||target="blank"]]
	112	+*** [[Routing - SpEL (Store Item)>>doc:Main.eMagiz Store.Accelerators.Routing - SpEL.WebHome||target="blank"]]
	113	+* [[Intermediate Level (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.WebHome||target="blank"]]
	114	+** [[Data traffic routing (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Data traffic routing.WebHome||target="blank"]]
	115	+*** [[Synchronous routing (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Data traffic routing.intermediate-data-traffic-routing-synchronous-routing||target="blank"]]
	116	+* [[Asynchronous Routing (Search Results)>>url:https://docs.emagiz.com/bin/view/Main/Search?sort=score&sortOrder=desc&highlight=true&facet=true&r=1&f_space_facet=0%2FMain.&l_space_facet=10&f_type=DOCUMENT&f_locale=en&f_locale=&f_locale=en&text=%22asynchronous+routing%22||target="blank"]]
134	134	)))((({{toc/}}))){{/container}}{{/container}}