Message Routing

Message routing describes queuing and dispatching to different targets of a message from/to IFS Applications. This will be based on the message type and/or the content of the message.

Note: This version of IFS Application is supplied with a new Router implementation. Read more about that here.

Contents

• Definitions
• Overview
• Message Router
• Routing of Outbound messages
• Routing Address chaining
• Routing Rules and Addresses

Definitions

An Inbound message is a message sent to IFS Applications from the outside world. The message can be received by a Connect Reader or the SOAP Gateway and is routed to it's destination.

An Outbound message is a message sent from the business logic in IFS Applications and is routed to it's destination.

The above doesn't define destination of a message, i.e. an Inbound message is typically routed to the business logic in IFS Applications, but can also be routed to the outside world. And the opposite - an Outbound message is typically routed to the outside world, but can also be routed back to the business logic in IFS Applications.

An Inbound message is routed by an Inbound Routing Rule, while an Outbound message is routed by an Outbound Routing Rule. But as stated above the type of the Routing Rule describes only where the routed message is coming from, not where it is routed to. The destination of the routed message is defined by the Routing Address used by the rule. Furthermore a Routing Rule can define several addresses of different types, that can also be chained.

With other words we can say that Routing Addresses can also be of Inbound or Outbound type. An Inbound Routing Address is sending the message to the business logic in IFS Applications, while an Outbound Routing Address is sending the message to the outside world.

IFS Applications offers two types of Inbound Routing Addresses: BizAPI and PL/SQL. Inbound Addresses don't make use of any Connect Senders. Other types of Routing Addresses, like File, Ftp, Http, JMS, Mail are Outbound Addresses and require definition of corresponding Connect Sender.

Overview

The picture shows IFS Connect with the central Message Router

Following points below are a summary of the Message Routing functionality.

• All inbound messages that are received by IFS Connect and outbound messages that are sent from IFS Connect go through the Message Router.
• The goal of Message Router is to find a Routing Rule that best matches the message.
• Each Routing Rule defines a number of conditions that are used to match the message.
• A Routing Rule condition may be a Content based condition or a Location based condition.

Note: In content based routing we compare the content of the message header/body with the given values. In location based routing we compare the details of the location from where we got the message, e.g. reader name, name and/or the directory of the file.

• Both Content based routing conditions and Location based routing conditions can apply for Inbound message routing while outbound message routing will only be handled by using content based routing conditions.
• In routing it is vital to match at least one rule.
• All conditions in the matched rule must satisfy the message.
• If more than one Routing Rule matches the message, the one with the greatest number of conditions, content and location based, will be used.
• When there are Routing Rules with equal numbers of conditions that match and this is an inbound flow, the one with greatest number of location based conditions will be used.
• If there are still rules with equal numbers of conditions that match, the first one according to the alphabetical order of rule description will be used.
• The found Routing Rule determines the destination addresses
• A Destination Address defines transport connector (destination) type, transformers, envelop and character encoding to be used with the message.
• You can route a message to more than one destination by setting several addresses to a rule.
• It is possible to create chain of addresses, i.e. second address takes as input response produced by the first one, third address takes as input response produced by the second one, and so on.
• You can have several addresses in the same chain link, i.e. taking the same input data. In such case one of those addresses must be marked as main. Response from main address is taken as input to all addresses in the next chain link.
• Destination types include Business API's (BizApi's), PL/SQL methods and Transport Connectors such as FTP, Mail, File, Http(s) etc. 

Message Router

The goal of the Message Router is to find a Routing Rule that best matches the incoming message (inbound or outbound). The router performs content based routing on all XML (and XLS) documents. In addition, content based routing is also performed on text documents for inbound messages (recognized as NONE_XML), but is simpler and not that effective as XML routing.

Routing is performed according to the following steps:

1. Check if simplified routing is enabled, defined attribute is present in the message and there are rules defining the actual value. Use simplified routing if so.
2. Inbound message: check the location based conditions.
   Outbound message: check Application Message attributes.
3. Inbound message: parse and check the incoming XML document, if present.
   Outbound message: parse and check the output XML document produced by the invoked outbound BizAPI, if present.
4. Inbound message: check the incoming text document, if present. Parsing of text documents is much simpler compared with XML document - the entire document is just treated as a single string.
   Outbound message: parse and check the XML document sent to BizAPI as input.

   Note: An inbound message can contain only one document: XML, text or other format. An outbound message can contain one or two XML documents: initial request and outbound BizAPI response (function result), if such is defined.

5. If there are several rules satisfying the message, choose the one that has most conditions.
6. If there are several rules with the same number of conditions and this is an inbound flow, choose the one with most location based conditions.
7. Finally, if there are still rules with the same number of conditions, the first one according to the alphabetical order of rule description will be chosen.

Routing of Outbound messages

Routing of outbound messages (sent from business logic in the database) is performed in two phases:

1. pre-routing in the database (the PLSQLAP_Server_API package)
2. final routing performed by Message Router running in the Middleware Server

The goal of the pre-routing phase is to find a queue the message can be put into, which is especially crucial for in-order messages. But if possible this phase can perform full routing, i.e. find a suitable rule and add destination addresses. If the pre-routing phase cannot decide about the queue and the message is not of in-order type, it will be put into the special system queue with name UNROUTED.

The pre-routing phase is based on the four Application Message attributes: MESSAGE_FUNCTION, MESSAGE_TYPE, SENDER and RECEIVER, so any rule not defining any of those attributes cannot be found by this phase.

Because of the above there is a limitation for in-order processing - all routing rules defined on an in-order queue must define conditions based on at least one of the mentioned four Application Message attributes (in addition to other content based conditions). The pre-routing phase will abort the execution if there are rules defined on an in-order queue that do not define conditions based on any of those four attributes.

Another limitation related to in-order processing is that if there are several rules matching the same subset of conditions based on the mentioned four Application Message attributes, all those rules must be defined on the same queue. If the pre-routing phase cannot find a queue for an in-order flow, the function will be aborted with an exception.

The pre-routing phase is trying to find all routing rules with conditions satisfying the message based on the mentioned four attributes. If the best candidate, i.e. the one with the most number of conditions, does not contain any other conditions (i.e. not based on the mentioned four attributes) and has more conditions than any other rule that doesn't define any of the four attributes (and consequently cannot be find by the pre-routing phase), then the final routing will take place already during the pre-routing phase. Otherwise the list of candidates is analyzed and, if all define the same queue and there are no other rules that don't make usage of the four attributes, the pre-routing phase will use the found queue to put the message to. In other cases, the UNROUTED queue will be set.

But if any of the found rules define an in-order queue, the execution will be aborted with an exception.

If no rules can be found and there are no other rules that do not use any of the four attributes, the message will be put to the ERROR queue instead.

An exception from the statement above is for event messages. In cases when queue would be set to UNROUTED or ERROR, for those messages it will be set to NOTIFICATIONS instead.

Routing Address chaining

A Routing Rule can define a number of destination Routing Addresses (BizAPI, FTP, Mail, File, Http, JMS). Addresses can be chained, i.e. divided in a number of groups (chain links). If there are several addresses in a group (chain link), one must be defined as main. After successful processing each address delivers a response - for some address types (File, FTP...) it will be just a receipt, while for other (BizAPI, Http...) the response can contain real business data. Each address can define a number of transformers that have to be called before sending data to the destination and a number of response transformers that work on the response data. An address can also define envelope and encoding.

Message processing works as follow:

1. Message to be processed is sent as input to all destination addresses in the first address chain link.
2. All addresses in the first chain link are executed, but only response from the main address within this link is sent back.
3. Response from the main address in the first chain link is then passed as input to all addresses in chain link two.
4. Message processing continues with all defined address chain links.
5. Response from the main address within the last chain link is sent back to the caller.

See also Application Message structure.