MQSeries.net :: View topic - MQ OTMA Bridge versus IMS MQ Triggering

PeterPotkay · Posted: Mon Mar 18, 2013 2:14 am Post subject:

Is there on online reference for getting messages into IMS via MQ from the mid tier, comparing the pros and cons of the OTMA bridge versus MQ Triggering?
Some things Iâ€™m thinking ofâ€¦.
1. If the existing mainframe application canâ€™t or wonâ€™t change to become MQ aware, the OTMA Bridge will allow the integration, while MQ Triggering will not. An MQ Triggered app need MQ API calls.

2. If you need to execute the IMS transactions using the UserID in the MQMD of the incoming message, the OTMA bridge will allow this, while MQ Triggering will (apparently) not. So IF you trust the MQMD User Identity (a separate topic, letâ€™s not go down that rat hole here), the bridge will carry this identity into the IMS transaction.

3. If you are dealing with extremely high volumes (thatâ€™s a relative term), I suppose the OTMA Bridge is a more efficient method as itâ€™s constantly watching the MQ app queues and transferring the messages directly into the IMS queue, while the MQ Trigger model involves the extra overhead of trigger messages into init queues. If the app is going to only do a one and done, that could be a lot of trigger messages all day every day as app messages arrive all day every day.

4. One OTMA queue can invoke any number of TCODES, without needing separate MQ queues and process definitions for each. But you can set up multiple MQ queues feeding the same OTMA if you want more granularity for MQ Statistics or Alerting and Monitoring

5. It seems simpler from the MQ Infrastructure side for the OTMA method. Just create a new MQ queue, map it to the right storage class, and tell the IMS guys to do their part. But I donâ€™t know how complex the IMS set up is.

6. For an MQ guy, the Mq Triggering method seems more straight forward. Thereâ€™s some under the covers magic happening in the OTMA link that is a black box. Who do you call when things go wrong there. But I suppose all of this IT stuff is magic when you get down to it â€“ eventually you gotta trust the stuff works. It would help to have a good DeveloperWorks article with pictures on this topic.

7. MQ Triggering will allow triggering by depth, while the OTAM bridge deals with the messages immediately as they arrive. Playing around with GET Inhibit and Get Enable jobs and some monitoring script to watch the input queue might be a way to simulate depth triggering for the OTMA queue method.

8. If you are MQ Triggering, the triggered app is MQ aware and thus has the ability to use all the MQ Options and MQMD fields the way it sees fit. I donâ€™t think the OTMA Bridge is as flexible in this regard, although it has gotten better since MQ 5.3 (it can now respect Expiry on the reply message as it relates to the Request message, for example)

9. The front end app will likely have an easier time building the input message if its destined for an MQ Triggered queue instead of an OTMA queue â€“ no need to mess with building an IIH header. (Note to self: Research if WMB or DataPower XI52 has any built in functionality to make building an IIH header easier. Any Support Pack for helping regular MQ Clients, kinda like the XMS pack helps building RFH2 headers (back before Message Properties)).

Bottom line question: If you have a green field and everything is new (front end app and backend app), do we go for the MQ OTMA bridge method or the MQ Triggering method? I know, I know â€“ â€œIt Depends.â€ But do you have any corrections or additions to the above list to help make the call?
_________________
Peter Potkay
Keep Calm and MQ On