The detail of the routing allows you to edit all the rules to choose the next element to process.
The first part of the screen just summarizes when this routing will be used, by clearly showing which preceding steps are shared by all the channels involved in this routing.
The second part of the screen displays all the rules. There is one line by possible candidate that can be chosen by the routing. The columns of the table are:
Tells in which order the rules will be evaluated. The system first evaluates rules that have the lowest priority. The evaluation of the rules is stopped as soon as the condition of a rule is satisfied, and the system chooses the next element notified in this rule. |
|
Tells which metadata will be used for testing the condition. For example, in the figure, the metadata com_babelway_messaging_context_mail_subject has been selected. This means that the rule will be satisfied if the subject of the email used to receive the message matches the following expression. If you want that your condition applies on the whole message, select com_babelway_messaging_context_message. Please refer to the Metadata chapter for a list and description of all available metadata. |
|
A regular expression that the selected metadata must match to satisfy the routing rule. Please refer to the Regular Expression in External References chapter in the appendices for description and reference about regular expressions. |
|
The element that will be chosen as next element for the processing if the rule matches. |
|
The channels that are still reachable after having chosen the rule. If you still get multiple channels, it means that another routing will happen at a further step to choose the right channel. |
As an example, the rules illustrated in the figure above can be read. :
- If the subject of the email is "Tutorial1", then choose the transformation "Countries xml to csv" (used in Channel "Tutorial 1") as next step.
- If the subject of the email is "Tutorial2", then choose the transformation "Countries xml to csv-1" (leading to Channel "Tutorial 2a" or "Tutorial 2b") as next step.
Using regex and xpath in the routing condition
For example, we have five channels. Four of them receive an XML message file and one of them receives an EDIFACT message file. For the EDIFACT message, we will use a regex for the routing rule and for the XML message, we will use the xpath for the routing rules.
Note: In Babelway, we're using the standard Java version of REGEX, and it's the same used all over the system.
Below is the logic for the routing rules that we want to achieve.
- Channel 1 will receive order messages from the sender with the "1146875312911" GLN.
- Channel 2 will receive order messages from the sender with the "2214674221322" GLN.
- Channel 3 will receive order messages from the sender with the "3357465940233" GLN and with a test Indicator equal to 1.
- Channel 4 will receive order messages from the sender with the "4409782460744" GLN and with a message version equal to 2.
- Channel 5 will receive order messages from the sender with the "8426571930459" GLN.
- The non routable messages channel will receive all order messages that didn't match any of the above routing rules.
Note: All the channels are sharing the Gateway In, and the channels ( Channel 1, Channel 2, Channel 3, Channel 4 ) are sharing the Gateway In and Message In.
As we can see in the above figure, we have two routing tables when we display the routing page from Channel 4 The first table is responsible for routing messages between Channel 5, Non routable message channel and Group of channels " Channel 1 and Channel 2 and Channel 3 and Channel 4 ", while the second table is responsible for routing messages between Channel 1, Channel 2, Channel 3 and Channel 4.
Note: We can see two routing tables when we check the routing from Channel 4 because all the channels are sharing the Gateway In and some of the channels are sharing the Message In only, and that is why we can see two routing tables.
Regarding the first routing table
For Channel 5 we used .*UNB.*8426571930459.*BGM\ 220.* as regex expression to match all of the EDIFACT order messages received from the sender whose GLN is "8426571930459".
Note:
- The . means match any single character.
- The * means match any number of repeats ( Zero or more ).
- The .* combined means match any character repeats zero or more times.
- The \ is used to escape any regex special characters, In this case to escape the character.
For the group of channels ( Channel 1, Channel 2, Channel 3, Channel 4 ) we used xpath:count(/EDIXml) =1 to match all XML order messages and then in the second routing table we will route each message to its corresponding channel.
Note: To be able to use xpath in the routing rule we must use xpath: before the xpath condition.
For the Non routable messages channel we used .* as regex expression to match all order messages that didn't match any of the above routing rules.
Regarding the second routing table
For Channel 1 we used this xpath:/EDIXml/SenderID="1146875312911" to match all XML order messages received from the sender whose GLN is "1146875312911".
For Channel 2 we used this xpath:/EDIXml/SenderID="2214674221322" to match all XML order messages received from the sender whose GLN is "2214674221322".
For Channel 3 we used this xpath:/EDIXml/SenderID="3357465940233" and /EDIXml/TestIndicator=1 to match all of the XML order messages received from the sender whose GLN is "3357465940233" and with a test indicator value of 1.
For Channel 4 we used this xpath:/EDIXml/SenderID="4409782460744" and /EDIXml/Version=2 to match all XML order messages received from the sender whose GLN is "4409782460744" and with Version value of 2.
Using lookup table function in the routing condition
For some complex channels set up we can benefit from the ability to use the lookup table function in the routing condition in order to achieve the requested routing logic.
The below example shows how we can use the lookup table function in the routing condition to route the messages if they are duplicate messages then route them to the "Duplicate messages" channel, If the messages are for existing suppliers then route them to the "Receive notification messages for existing suppliers" channel, If the messages are for suppliers that don't exist in the system then route them to the "Send notification and original message that supplier doesn't exist" channel, Finally route the other messages to "No notification" channel, as shown below.
Below are the complete routing rules in order to check them.
1- xpath:not(contains('NOT_FOUND', bbw:lookupTableValue('Check duplicate messages','Reference','Reference',/Invoice/InvoiceNumber,'NOT_FOUND')))
2- xpath:not(contains('NOT_FOUND', bbw:lookupTableValue('Suppliers','ID','ID',/Invoice/SupplierID,'NOT_FOUND')))