Message Queues¶
Message queues are the place holders of Application Messages. IFS Connect Message Queues are used for different purposes, such as:
- Storage of messages when they are processed asynchronously (in some circumstances even synchronous messages can be stored).
- Storage of background jobs.
- Storage of notification, warning and error messages.
Some default queues are created at the initialization process and are used by the IFS Connect Framework for the above purposes while any new queue can be created and configured by using the Message Queue feature in Setup IFS Connect client feature.
Those default message queues are
- Default Batch Queue (BATCH1):
The default queue for application server tasks other then print jobs. - Print Agent Batch Queue (BATCH2):
This queue has been moved to the Report Message Queue. - Default Inbound Queue (IN1):
By default any inbound asynchronous message will be placed in this queue before processing. - Default Outbound Queue (OUT1):
By default all outbound asynchronous application messages will be placed here before being processed by the Batch Processor. - Notification Queue (NOTIFICATIONS):
Notification messages are being kept here. For example any finished Connectivity Event messages will be kept here. - Default Queue (DEFAULT):
Default queue for synchronous message and messages for which the queue name is not defined, i.e. posted through the SOAP Gateway. - Error Queue (ERROR):
Whenever an error in resolving queue name occurred while processing an application message it will be posted in the error queue. - Connect Reader Response Queue (READER_RESPONSE)
By default messages created as response for messages read by Connector Readers are placed here. - Queue for un-routed outbound messages (UNROUTED)
Routing of outbound messages is performed in two phases, where the first one takes place already in PL/SQL code. The goal of this phase is to find a queue the message can be put into. If the logic cannot find a suitable queue, the message will be temporarily put into this queue. - Trashcan Queue (TRASHCAN):
All messages that are to be deleted by the database task "Cleanup Application Message Queues" will be kept here.
Note: Any message that should be deleted permanently should be moved to the Trashcan Queue so that the cleaning database task can identify and remove it.
Understanding an Application Message¶
An Application Message is a data structure used in IFS Connect framework. Any application message consists of three major parts:
- Header
General information that is relevant to a particular application message is defined in the header part of the application message. The header part is used to specify the application message itself. -
Address List
The Address list of an application message describes the associated destination addresses. Destination addresses can be chained.
Destination addresses in the first address chain link are used for sending the content of the message to the destination. Addresses in other address chain links use the response from successful execution of the main address in the previous link as the input data.
An entry in the Address list describes:- the address data to be used when processing
- transport connector type to be used (File, Mail etc)
- envelop, encoding and transformers
- state whether the message was processed correctly, any error description, max retires and retry count on failures
- sender, sent date and receiver name
- expiry date for processing
-
Message Bodies
An Application Message can contain initial request, function result and reply bodies.
Inbound messages do not contain function result. Initial request body typically consists of XML data to be used in processing the message.
A reply body consists of the data sent in a reply message, i.e. as a result of successful execution of a destination address. This may be XML, PDF, Text or Binary data. The body is always stored in original format. If the body contains any type of text data (XML or plain text) it is always encoded in UTF-8 character encoding.