Continuous Outbound Queue
AnamitraBhattacharyya 100000B6YW Comment (1) Visits (19364)
Maximo Integration framework supports asynchronous processing using JMS queues. Queues are tied to External systems configuration such that each external system can potentially have their own set of outbound and inbound queues to communicate with Maximo.
Outbound queues are meant to facilitate asynchronous
messaging from Maximo to External system. For example when a Mbo gets
Inbound queues are meant to facilitate asynchronous messaging from External System to Maximo. Inbound queue messages can crea
Continuous queue processing is not meant to stop on error. Though messages come out of the queue in order [FIFO], they are processed by multiple consumers [Message Driven Beans] simultaneously and hence will most certainly be processed out of order. This lends to the “self-correcting” nature of this queue where even if the messages were queued out of order – the messages may be processed in the right order [as needed by Maximo business rules – like GL message needs to go before the Purchase Order message which refers to that GL] as they error out and get retried by the consumers repeatedly.
A sequential inbound queue is very similar to the sequential
outbound queue – the only difference being the direction which the message is
moving. In case of sequential outbound the messages are moving from queue to
external system and for the inbound sequential it is moving from the queue to
Probably by this time you have noticed that the continuous
outbound queue is conspicuously missing. The initial design reason for this
being – when messages get stuck for outbound sequential queue, it is mostly
because of some bad [endpoint] configuration or network connectivity issue as
opposed to a business validation error. In that case it is not very useful to
try all messages as they are all bound to fail.
There is however valid use cases where the error maybe due to a business validation which can be resolved by a subsequent message [out-of-order issue] or maybe the error is localized to one particular module of the External system and other modules are functional and can consume messages. In either case it seems like a waste of resource and time to shut down the outbound queue just for one message failure. So the challenge is how to get a continuous out queue. Fortunately it is a fairly simple customization effort.
A queue by itself is neither continuous not sequential – it is just a queue which will give out messages in FIFO order. It is how you consume messages from the queue that makes it continuous or sequential. When you put multiple consumers [Message Driven Beans] for a queue – those consumers are going to process messages in parallel and are not going to wait when one of the consumers get a bad message. So the trick is to put an MDB for the out queue.
MIF already ships with 2 JMS consumers –
Both these components are written generically to consume messages continuously [MDB] and sequentially [crontask] agnostic of the direction [outbound or inbound]. Each of them refer to a direction specific component called the MessageProcessor
They handle processing the messages inbound to Maximo or outbound to the External System. Maximo allows customizing these processors as they are registered with crontask parameters [for JMS crontask] and EJB deployment descriptor [for MDB - ejb-jar.xml for mboejb module – as shown below].
As evident from the above ejb-jar.xml snippet – the MDB JMSC
Note that the message processor has been changed to refer to the Queu
Make sure that the id entered in step 2 [Mes
That should be good enough to get it working. You can also mark the queue as sequential – false in the maxqueue dialog. This is just for a clean implementation and not really used by the MIF outbound framework.
Another variation of this would have been to not tamper with the existing outbound queue and to create an entirely new queue and register it in maxqueue table and then change the External System configuration to point to that as the outbound sequential queue. External system configuration unfortunately does not let you define both sequential and continuous out queues.For more details on continuous queue configuration please refer to this blog.