Global Transactions and Quality of Service in OSB

Bookmark and Share
Last week I had a great OSB BlackBelt training of Samrat Ray and organized by the SOA Community  In this training we talked a lot about Global Transactions ( XA), QoS ( Quality of Service )  in combination with Transports and JCA Adapters. Because this is so important ( you dont want to loose a Message ) I decide to make a blog about this subject and I will explain the different scenarios options you have in the Oracle Service Bus.



Before I can start I need to create and configure some Queues. In this blogpost I will use JMS for the Proxy and the Business service but you can also use EJB, MQ or the Direct Binding ( SOA Suite 11g ) for the Business Service, they all support XA, normal Web Services does not support XA ).



First create the RequestQ Queue combined with an ErrorQ Queue ( Now failed messages will be redirected to this Queue and won't be lost in Space), a ReponseQ Queue and a DestinationQ Queue ( used in the Business service )



Here is a picture how you can define an Error Queue on the RequestQ.  Go to the Queue, select the Delivery Failure Tab in the Configuration Tab. Now you can set the Redirect Expiration Policy and select the Error destinations.





I start with a simple scenario.  Add a message in the RequestQ and we will expect the message in the ResponseQ.



Add a Proxy Service ( any XML) and select JMS as protocol. OSB generates a default url with an internal XA connection factory and add the Queue name to this URL.



Add the destination Queue in the Proxy Service by enabling the Is Response Required option. Use text as Response Message Type ( else it will be hard to read the message ) and provide the Response URI.



Leave the Message Flow empty and a message in the RequestQ ( Go to the Queue, monitoring tab and a create a new message).  Always change the Redelivery Limit  ( Don't use the value -1 )

You will this message in the ResponseQ.



So far so good, now let's raise an Error on the Response Channel and take a look at the results. In the message flow I added a PipelinePair with a stage and an Error activity.

What you will see the message is removed from the RequestQ and the ResponseQ only gets a message with a SERVER_ERROR header and the content is gone.

We can solve this by making a change in the Proxy Service. Enable the Same Transaction For Response option, the response Thread will take over the transaction so when now something happens the transaction will be roll backed.







Add a message to the RequestQ, ( set the Redelivery to 2 else you will get a loop ) what you will see that the message now is added to the ErrorQ and not to the ResponseQ. This is good behaviour. Now you can re-process this message again by moving it to the RequestQ or let an ErrorHospital handle it.



The next step is adding a business service and make this part of the Global Transaction. Add a routing to this Business Service in the message flow of the Proxy Service. This will also add the message to the DestinationQ. Make sure  that the Message Type = text ( for this test only )

When you now put a message on the RequestQ, the message is also roll backed on the DestinationQ and only exists in the Error Queue.

When you disable the option Same Transaction for Response ( Default behavior ) then this message will be commited even when there is an error in the Response Channel of the Proxy Service.



The last part of this blog is taking a look at Quality of Service ( QoS ),  You need to add a Routing options activity to the request part of the Routing. First set QoS on Best Effort.



When we disable the Same Transaction for Response option and add a message on the RequestQ with a retry delivery of 5, You will see 6 messages in the DestinationQ. Don't think you will like this,so let's change this to Exactly Once.



You will only see this message once.



Conclusion: You need to think about your process and ask yourself is it a problem when you loose a  message and what about when you deliver the same message again and again. Be aware default XA is not enabled in OSB and you need to configure and test this. Off course you need to use XA connection factories, Datasources and XA configured Resource Adapters. Business Services which call Web Services won't be part of XA, use for this Direct Binding transport  ( SOA Suite 11g )

{ 0 comments... Views All / Send Comment! }

Post a Comment