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.
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.
The picture shows IFS Connect with the central Message Router
Following points below are a summary of the Message Routing functionality.
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.
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:
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.
Routing of outbound messages (sent from business logic in the database) is performed in two phases:
PLSQLAP_Server_API
package)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.
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:
See also Application Message structure.