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 19.1
edited by Erik Bakker
on 2022/08/15 08:03
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -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
42 +1. It looks for the header called {technicalnameofproject}\_targetSystem and will split each entry based on the separator (a comma)
43 +2. It will trim the result of this split and combine it the value in the header called {technicalnameofproject}\_messageType
44 +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.
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.
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.
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.
102 102  
103 103  === 3.5 The result ===
104 104