Changes for page Asynchronous Routing

Last modified by Danniar Firdausy on 2024/09/04 09:01

From version 21.1
edited by Erik Bakker
on 2022/08/15 08:06
Change comment: There is no comment for this version
To version 18.1
edited by eMagiz
on 2022/06/13 11:34
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.ebakker
1 +XWiki.eMagiz
Default language
... ... @@ -1,1 +1,0 @@
1 -en
Content
... ... @@ -3,6 +3,9 @@
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 +
6 6  == 1. Prerequisites ==
7 7  
8 8  * Basic knowledge of the eMagiz platform
... ... @@ -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
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
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.
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.
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.
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.
102 102  
103 103  === 3.5 The result ===
104 104