OSB 11g - Quality of Service or Transaction Use Case

In previous post, I explained the basics of Qos (Quality of Service). In this post, I will show you how and where we can use Qos and how global transactions work in Oracle service bus.

For this use case, at source side we have JMS queue and at target side we have external service (SOA Composite) hosted on different server. We use OSB to transfer message from JMS queue to external service.

Our requirement is to rollback the message to main queue if external server which hosts the service is down. We have put “Delivery Failure” retries in main queue which means when message rollback to main queue, it will try to process same message again after some time as configured and once all retries completed and still we are not able to send message to external service then put the message to error queue.

To configure retry able queue, you can check this post.

We create proxy service which listen the message from JMS queue and business service which sends the message to external service.

In OSB, we can invoke business service from proxy service message flow in three different ways; you can choose required option as per requirement.

• Routing- Using route Node
• Publish
• Service Callout

In This post, we will discuss about Qos or Transaction for all above mentioned options one by one.

Let’s start with actual implementation of use case.

First create an OSB project, add required folder structure to it. Import External service WSDL and XSD file in the project.

Now create a proxy service, which read the message from JMS queue (SampleQueue). Since we are reading the message from JMS queue so this is transactional proxy means this proxy supports transaction.

Now create a business service which sends the message to external service.

Now we will discuss above mentioned business service invocation methods one by one.

Routing

We use routing when we want to route the message to business service. For routing by default Qos is “Exactly-Once” so we need not to set Qos in the message flow separately.

As shown in below diagram, when external server which hosts the external service is down then the message will roll back to main queue and from there it will be send to error queue once all retries completes.

Service Callout

We use service callout inside stage activity. We use it when we need to get response from external service in between the flow. Here we will see how Qos or transaction works in this case.

As shown in below diagram, message will be roll back to main queue in case external server is down. And from main queue message will be sent to error queue after all retries completes. 

Publish

We use publish activity to publish the message. We can use this activity inside stage activity. Transaction behaves differently when we use this activity.

As shown in below figure when we use publish activity then it will not roll back message to main queue if external server is down.

To support transaction for publish activity; we need to add Qos explicitly. As shown below when we set Qos to “Exactly-Once” then the message will roll back to main queue in case external server is down.

Tweet