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.
• 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 IFS Solution Manager (Setup IFS Connect). Also behavior of the existing queues can be changed using the same feature.

Those default message queues are

1. Default Batch Queue (BATCH1):
   The default queue for application server tasks other then print jobs.
2. Print Agent Batch Queue (BATCH2):
   By default Print Agent jobs will be placed in this queue.
3. Default Inbound Queue (IN1):
   By default any inbound asynchronous message will be placed in this queue before processing.
4. Default Outbound Queue (OUT1):
   By default all outbound asynchronous application messages will be placed here before being processed by the Batch Processor.
5. Notification Queue (NOTIFICATIONS):
   Notification messages are being kept here. For example any finished Connectivity Event messages will be kept here.
6. 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.
7. Error Queue (ERROR):
   Whenever an error in resolving queue name occurred while processing an application message it will be posted in the error queue.
8. 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.

An important property of a message queue is its Execution Mode. With exception of ERROR and TRASHCAN queues it is possible to choose one the following modes for any queue:

• InParallel
• InSequence
• InOrder

Messages in an InParallel queue are executed parallel. Processing of messages is started by the database trigger (see the description of the flow) and the message state is change from Released to Processing. The only difference between InParallel and InSequence is that messages in an InSequence queue are executed one at time, but without any specific order. Message flow and state transitions are the same for both modes.
A queue can be manually stopped causing all new messages to enter state Suspended. Starting a queue will cause all suspended messages to be released and processed by the trigger. Queue can only be stopped manually.
When examining messages in such queue there can be a number of messages in state Processing and normally shouldn't be any message in state Released.

The InOrder mode is quite different. In this mode the purpose of JMS messages sent by the database trigger is only to notify the Batch Processor about new messages without changing state. Messages are remained Released until fetched by the Batch Processor, which will change the state to Processing for the first message. Messages are executed one by one in a strict order and a single JMS message will trig the execution of all released messages in the queue, of course, one at time.
Another behavior of an InOrder queue is that it will be automatically stopped on failure and will require manual restart after the cause of the failure has been removed. Stopping an InOrder queue will not cause any state transition - released messages will remain in state Released. Consequently there are no needs for any state transition on starting the queue - it will just resume processing of messages in order, provided the first one is not Failed.
When examining messages in an InOrder queue there should be only one (or none) message in state Processing and possibly a number of messages in state Released.
State Suspended can only be entered when manually suspending messages in Solution Manager.

Understanding an Application Message

Application message is the 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 and response addresses.
  Destination addresses are used for sending the content of the message to the destination address, while the response addresses uses the response from successful execution of the main destination address as the input data. Both of these address types share the same format.
   

  An entry in the Address list describes:

  • the address data to be used when processing
  • transport connector to be used (BizApi, 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 consists of  XML data to be used in processing the message. Function result contains the result of the initial request after processed by the BizAPI. A reply body consists of the data sent in a reply message. This may be XML, PDF, Text or Binary data. The body is always stored in original format.