Changes for page Asynchronous Routing

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

From version 22.1
edited by Erik Bakker
on 2022/08/15 08:07
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  
... ... @@ -60,10 +60,16 @@
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 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.
66 +As the asynchronous plays a role in routing messages between all asynchronous flows in a
67 +the messaging solution you can imagine that making changes does not need to happen lightly.
68 +The other aspect is that when multiple projects are being built at the same time the asynchronous routing
69 +will house a multitude of changes that need to go to Acceptance or Production at the same time.
64 64  
65 -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.
66 -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.
71 +One control mechanism we consider a best practice to guard yourself against those risks is to add a filter
72 +before data is placed on the offramp queue.
73 +By doing this consistently you can control when a specific offramp can receive data on any environment.
74 +In other words, when a certain system is not ready yet to receive data on Acceptance or Production but is ready on Test
75 +you can control this behavior with this solution.
67 67  
68 68  Below you see how this will look on flow level.
69 69  
... ... @@ -82,17 +82,19 @@
82 82  
83 83  Steps to follow when adding an integration to the routing Part I:
84 84  
85 -* Add a header in the onramp named {technicalnameofproject}\_targetSystem (if this is not done yet)
86 -* Fill this header with a value that should be defined as a property (naming convention = systemname.messagetype.targetsystems)
87 -* 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)
88 -* 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.
89 89  
90 90  Part II
91 91  
92 -* In this standard router a SpelExpression has to be defined **once** that concatenates the following headers: {technicalnameofproject}\_targetSystem and {technicalnameofproject}\_messageType.
93 -* 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)
94 -* 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
95 -* 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.
96 96  
97 97  === 3.5 The result ===
98 98