JMS Transport – Advanced settings

• The option Enable Message Persistence is by default enabled, which guarantees message delivery because the messages persist and will survive server shutdowns and failures.
  • To improve throughput, deselect this option if the occasional loss of a message is tolerable.
• Set a time interval in milliseconds in the Expiration field to specify the message time-to-live.
  • After the time-to-live is passed, the message will automatically be treated according to the Expiration Policy defined on the JMS destination (that is, the queue) and either discarded, logged, or redirected to another JMS destination.
  • The default value of 0 for Expiration means that a message never expires and therefore waits to be consumed forever or until the server is shutdown, if the message is not persistent.
• Any JMS destination can override the Expiration set on the business service by setting the Time-to-Live Override setting through the WebLogic console when configuring the JMS destination.

Changing JMS transport Headers

• When sending a message to JMS queue or topic through a business service, default values for several JMS Transport message headers are used. The message headers as well as the message properties can be overwritten by using a Transport Header action in a proxy service when routing to the business service.

Set the properties and deploy the project. On testing you will see these

Check the messages on the destination queue.

We have successfully overwritten the JMS header values configured in business service using the transport header action.

Note: The Transport Header action can be placed into the Request Action of the Routing action or Publish action in order to override the jms header values.

Consuming from a JMS Queue

Testing the JMS Consumer

Deploy the JMSConsumer proxy and the message is gone.

You can now check the OSB server logs and you should see the logged body element [highlighted].

Key points

• On a proxy service, the JMS protocol always works inbound, that is, the proxy service is consuming messages from a queue.
• On a business service in contrast, the JMS protocol always works outbound, that is, the business service is putting the message to a queue.

Configuring Retry handling in JMS

Configure the redelivery limit and expiration policy on a Queue that will take part in a reliable communication. This option prevents an infinite loop: when the redelivery limit is reached, the message will be moved to the error queue. The redelivery limit on the queue will always override the value set on the message itself.

When creating a message from the weblogic console make sure to overwrite the -1 in the Redelivery Limit field to the same value as specified on the queue Otherwise the -1 will overwrite the setting on the queue and it will again retry forever.[Bug in console]

Explanation

When a proxy service reads a message from the NYSSourceQueue and there is an error somewhere in the process, the message will be rolled back and stays on the queue. WebLogic will detect this and wait for 15 seconds before the proxy service can consume it again. If this happens three times then WebLogic will move the message automatically to the error queue. Such an error queue can be monitored for new messages through the WebLogic diagnostic module. An administrator might be able to solve the problem and remove the message or move it back into the original queue.

These settings can also be done from the Advanced Settings section on the JMS Transport tab of the proxy service. In that case, they will overwrite any settings specified directly on the JMS queue:

We can also override the delivery mode in WebLogic, which takes precedence over all the settings that the producer of the message specifies in the delivery mode.

The Enable Message Persistence property on the business service will not override what we have set in a Transport Header action.

Effect of using Non XA Connection Factory

Non XA CF Testing

The message is lost because the processing of the proxy service has been done in a local transaction. Because of the error, the OSB transaction rolls back, but the consumption from the NYSSourceQueue has happened in a different transaction and was already committed, so the message is lost!

Moving messages in JMS Queues – using OSB Console

How to implement transactions and message persistence

QOS – Using Best effort

By setting the QoS setting in the Routing Options to Best Effort, we force the business service not to use the global transaction. This means that the enqueue of the message into the DestinationQueue happens in its own local transaction and is therefore, committed independently of the global transaction. Because the global transaction retries three times, we get four messages in the DestinationQueue, one for the original request and three for the retries. This is probably not the behaviour we want and therefore, we have to be careful when using the Best Effort QoS setting.

When we use XA-enabled resources, enable Same Transaction For Response, and use

Exactly Once QoS on the outbound transport, every resource will be rolled-back in case of an

error in the Request or Response lane. To make this work, we should check if we are using

a XA or non-XA resource and what the value of the QoS is, otherwise the resource won’t take

part in the global transaction.

In this recipe, we don’t need to set QoS to Exactly Once because this is the default value when

we use JMS with a XA Connection Factory as inbound transport.

To know the QoS values of your proxy service, we can read the following transport variables:

f $inbound/ctx:transport/ctx:qualityOfService

f $outbound/ctx:transport/ctx:qualityOfService

The inbound variable value can’t be changed and OSB uses the inbound value as a default

value for the outbound transport. We can change the outbound QoS value with a Routing

Options action.

Only use the Exactly Once of QoS when there is a transaction involved.

In case of a Publish or a Service Callout action, the default value of QoS is always Best

Effort. This means in case of a JCA resource such as a DB or an AQ adapter we need to set

the dataSourceName property of the resource adapter and not using the xADataSourcename

property, otherwise we will get a runtime error. If the Publish or Service Callout action should

be part of the global transaction, then use the Routing Options action and set the QoS to

Exactly Once. In the case of a JCA adapter, we need to use the xADataSourceName property

of the resource adapter.

If our business service Publish action or Service Callout does not support XA, then with

each retry of the proxy service, the service will be invoked. This can lead to many duplicate

messages or invokes.

We can also force this behavior in a XA-enabled business service by adding a Routing Option

in the Request Action of the Route Node. In the Routing Options, you need to enable

QoS and set it to Best Effort. With Best Effort, the resource won’t take part in the global

transaction even when XA is enabled.

Don’t use the OSB console for testing XA. The test of the proxy

or business service in the OSB console is not the same as

when putting a message on a queue. The OSB console can’t

start a transaction.