Routing rules are objects that define what will be done to an inbound message ONEiO has received. Logic in what order rules are applied to messages is;
Conditions -> Runtime Variable Mappings -> Outbound Mappings and Conversation Variable Mappings
General info about the routing of messages
Multiple rules can match the incoming message and in this case, it might be routed to multiple target systems. The next figure shows how the rule matching process works.
The rules matching works as follows (see figure above):
-
Get all rules ordered by priority (higher priority rule gets handled before lower priority rule)
-
Initially match rules to endpoint and entity type
-
Check if conditions match the rules
-
Check if any drop rules match
-
If drop rule, ONEiO drops message and do no more routing is done
-
-
Ignore rules with wrong operation, i.e. create rule for updates and updates for creates
-
Identify rules which should be delayed and rules for further processing
-
Process delayed rules
-
Route the matching rules
-
No routing result if no rules match
Matching is case insensitive. All the matching in Routing Rules against attribute names and values is done case-insensitively.
When multiple routing rules are matching the same message, the processing order of the rules is based on rule priority values. Rules have a priority of 0 by default. Rule with higher priority (larger value) gets handled before rules with lower priority. Rules with the same priority are handled in a non-determined order.
Delay Rule Executions
In some cases a message cannot be routed when received, this is when delaying the rule execution comes in handy. See delay routing logic page for details.
Rule matching
Conditions
Message conditions are conditions checked against the inbound message. There are two types of message conditions: conditions that check the attributes of the inbound message and conditions that check attachments of the inbound message.
Attribute conditions
The parts of the condition are:
- attribute: what attribute to check. The attribute can be from an inbound message or a conversation variable.
- operation: How to check. Here are the possible operations:
EQUALS, NOT_EQUALS, EXISTS, NOT_EXISTS, STARTS_WITH, NOT_STARTS_WITH, IN, NOT_IN, CONTAINS, NOT_CONTAINS, LESS_THAN, GREATER_THAN_OR_EQUALS - value: What value should we use for the comparison. This single-value is used for all the other operations than IN and NOT_IN. Value can be a string or an attribute. If you set ${some_attribute} as value, the conditions need to match the value of attribute some_attribute. The attribute can be from an inbound message or a conversation variable.
There can be several message conditions defined. When there are multiple conditions, all of them have to match (AND operation).
Check inbound message attachments
You can set a condition that the rule matches if there is one or more attachments in the inbound message, or if there aren't any.
It makes no sense to have multiple message attachment conditions, but you can have both a message attachment condition with one or more message attribute conditions.
Action
Action defines what the rule does.
- Route to the target relays the message to the target according to the mappings defined
- Process only does all the same things as Route, but does not send out the outbound message. This is normally used to set some values to a conversation for later use, even if we do not want to relay the message.
- Drop the message stops all processing of the inbound message. Note that all drop rules are handled first, regardless of rule priorities.
Operation
Operation defines if the message is the first one sent to a certain system, i.e. it creates a new entity in the destination system. This is an easy way to separate create and update situations, which many times need a bit different kinds of mappings. The possible values for operation conditions are: CREATE, UPDATE. When the operation condition is completely missing, the rule is valid for both cases.
Iterate
Iterate option can be used if there is a need to produce multiple outbound messages from a single inbound message. For.ex. there can be a situation where an inbound message contains three attachments but the target would need them to be sent one by one.
- By Message element selection produces as many outbound messages as there are subelements in the inbound messages element defined.
- Delimiter-separated values selection produces as many outbound messages as there are split results in the selected inbound message's element. The split is done with the configured separator. E.g. if inbound message's element contains the string "First; Second; Third" and we define semicolon as the separator, we will get 3 outbound messages, where first has value "First" as the element value, second has value "Second" as the element value and third has value "Third" as the element value.
- By each inbound attachment selection produces as many outbound messages as there are attachments in the inbound message
IMPORTANT
Iteration can only be used in UPDATE or ALL MESSAGES rules.
See more details from Routing Rules.
Comments
Please sign in to leave a comment.