How do I decide which integration queue to use when bringing data into Maximo?

The I-F, by default, provides two inbound JMS queues that are used by Enterprise Services.  The queues vary in behavior based on the ‘consumer’ of the queue.  The consumer is the processing that retrieves the messages from the queue (while the queue provider would be the processing that loads messages into the queue).  For the default inbound queues, the sequential queue (sqin) has a CRON task as the consumer while the continuous queue (cqin) uses Message Driven Beans (MDBs).

Sequential Queue Processing

The processing design for the sequential queue, sqin, is that message order is maintained and the order of processing is First-In/First-Out (FIFO).   The messages are consumed by the JMS Cron task in the order that the messages were placed into the queue.  If an error occurs while processing the message into Maximo, the processing will stop on that error and not continue to subsequent messages.  Only when the message in error is processed successfully (on a retry or through correction) or when the message is deleted (by an administrator) would processing continue to the next message in the queue.  Note: this processing model also applies to the default outbound queue (sqout), which is configured as a sequential queue.

Continuous Queue Processing

The processing design for the continuous queue, cqin, is that message order is not guaranteed and the processing occurs in a multi-threaded manner (multiple messages processed at the same time).  In many cases, messages will process in the order that they were put into the queue but this is not guaranteed.  The continuous queue provides more through-put in terms of the number of messages that can be loaded within a specific time window. The messages are consumed by MDBs provided by the application server.  This allows scalability where MDBs across a cluster of servers could be processing messages from the cqin at the same time.  If an error occurs while processing the message into Maximo, the processing will perform retries of the message (as configured) but other messages will continue to process.  It is recommended that an error queue (exception destination) be configured for cqin to offload messages in error to a separate queue.

If you require that the messages maintain strict ordering based on order of the messages as they are placed into the queue, then your choice would be to use the sqin.  If you don’t require strict ordering, then you can choose to use the cqin which will give you better performance in the case you are loading large amounts of data.  Configuration of which queue an Enterprise Service uses is done in the External Systems application.

Some additional points

Ordering dependencies when using cqin

Although cqin does not guarantee the processing order of messages, you still may be able to load data that contains dependencies between messages.  For example, there are two new assets messages in the queue and one is a parent to the other.  If the child asset processes first, Maximo will give an error because it has a reference to the parent asset number that has yet to be created.  If you have configured the cqin queue to perform 5 retries, then it is possible that parent asset gets created (processed by a different MDB) and on one of the retries of the child asset it processes cleanly, since the parent was added.  This is often referred to as self-correcting.  In the case where the parent did not process before the child completed all of its retries, then the child message will go on Hold (and pushed to an error queue if configured).  An administrator can re-process the message using the Message Reprocessing application and if the parent record has been created, then the child should re-process successfully.

Minimizing the impact of errors when using sqin/sqout

The primary downside to using the sequential queue is that when an error occurs, the queue becomes blocked and no other messages can be processed. Some options to minimize the impact include:

• Set up a separate sequential queue for each external system – an error for one external system message won’t impact the processing of messages for other external systems – doing this will still maintain the order of messages for a specific external system
• Set up a separate sequential queue for each Channel or Service – an error for one channel/service message won’t impact the processing of messages for other channels/services - doing this will still maintain the order of messages for a specific Channel or Service
• Although not provided by default, you could create a second outbound queue and configure processing to be done by MDBs (I.e. create a continuous outbound queue).