Present Situation:
- XA Transactions in the Broker for publish/subscribe from the internal Application.
- The de-coupling of the transactions between the webMethods IS and the internal was done by the JMS Adapter Notifications. The present Adapter Notifications use NO-TRANSATION.
Desired(To-Be) Situation:
- Broker communicates with XA Transations with the internal Application(Same as Existing Situation).
- The transaction made for receiving the message from the Broker should be such that it doesn’t interfere with the internal transactions. In the existing situation the JMS Adapter notification did this de-coupling. Since the Adapter Notifications are now removed with the JMS Triggers, the appropriate Transaction Management for the JMS Trigger needs to be re-considered.
- It has to also considered that the XA Transaction from the internal Application could be waiting for the Acknowledgement from the Broker in order for it to be complete. Hence, in case of errors/faults there shouldn’t be any transactions that should be lying open.
Notes:
It has to be noted that the message is removed from the JMS Queue only after the succesful commit of the transaction and the receipt of the acknowledgement. If not, then the message is send back to the JMS Queue.
For the processing in Pub Packages: Only the transformation of the JMS Messages is done from the Canonical and Published to the Broker.(What can be the possible error scenarios)?
For the processing in Sub Packages:The Canonical Message is transformed to the JMS and send to the JMS Broker.(What can be the possible error/fault scenarios)?
- Possible error scenarios that needs to be considered:
- What happens in XA, LOCAL and NO Transactions in case there is a Transient Error. How is the roll back done(after after the maximum number of retries).
- What happens in XA, LOCAL and NO Transactions in case there is a Fatal Error. How is the roll back done(after after the maximum number of retries).
In both the above mentioned cases, if these are handled automatically intrinsically by webMethods. Or if there are additonal handling needs to be done for this. In case of Additional Handling: Please specify what exactly needs to be done.
In case of any exception/error if the message is send back to the Broker(via rollback), where does the message land in the Broker Queue. It needs to be ascertained if the Broker Queue is struck with the Fault message in the top of the Message Queue so as to block ALL the processing of the remaining messages on that particular message specific JMS Topic - This is undesirable.
The extensive volume of the messages via these inferfaces needs to be considered when making decision on the above mentioned.