Skip to Content

Changes for page Asynchronous Routing

Last modified by Danniar Firdausy on 2024/09/04 09:01
From version 18.1
edited by eMagiz
on 2022/06/13 11:34
Change comment: There is no comment for this version
To version 21.1
edited by Erik Bakker
on 2022/08/15 08:06
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.eMagiz
1 +XWiki.ebakker
Default language
... ... @@ -1,0 +1,1 @@
1 +en
Content
... ... @@ -3,9 +3,6 @@
3 3  
4 4  Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
5 5  
6 -* Last update: February 25th, 2021
7 -* Required reading time: 7 minutes
8 -
9 9  == 1. Prerequisites ==
10 10  
11 11  * Basic knowledge of the eMagiz platform
... ... @@ -42,9 +42,9 @@
42 42  
43 43  This SpEL expression does the following things:
44 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
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
48 48  
49 49  In the standard router component this will look as follows:
50 50  
... ... @@ -91,19 +91,17 @@
91 91  
92 92  Steps to follow when adding an integration to the routing Part I:
93 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.
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 98  
99 99  Part II
100 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.
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.
107 107  
108 108  === 3.5 The result ===
109 109