Skip navigation.
Downloads | Product Documentation | Support

WebLogic Tuxedo Connector Administration Guide

# How to Configure the Tuxedo Queuing Bridge

The following sections provide information on the Tuxedo Queuing Bridge functionality and configuration.

- Overview of the Tuxedo Queuing Bridge
- Configuring the Tuxedo Queuing Bridge
- Tuxedo Queuing Bridge Connectivity
- Example Connection Type Configurations
- Priority Mapping
- Error Queues

# Overview of the Tuxedo Queuing Bridge

The Tuxedo Queuing Bridge is a part of the WebLogic Tuxedo Connector that provides a bi-directional JMS interface for your WebLogic Server applications communicate to Tuxedo application environments. The transfer of messaging between the environments consists of JMS based messages containing text, Byte, or XML data streams used to invoke services on behalf of the client application.

Figure 6-1 Interaction between WebLogic Server and Tuxedo with the Queing Bridge

The following features determine the functionality of the Tuxedo Queuing Bridge:

- Connectivity is determined by the configuration of the attributes in theTuxedo Queuing Bridge and Redirections of your WTC Service.
- The Tuxedo Queuing Bridge uses Java Messaging Service (JMS) to provide an interface to a Tuxedo /Q or a Tuxedo service.
- The Tuxedo Queuing Bridge provides simple translation between XML and FML32 to provide connectivity to existing Tuxedo systems.

## How Tuxedo Queuing Bridge connects JMS with Tuxedo

Note: All messages remain on the JMS queue until they have been acknowledged.

This section provides information on how JMS messages flow through the Tuxedo Queuing Bridge to Tuxedo queues and services.

1. A JMS client, such as a web enabled WLPI application, places a message to be processed by Tuxedo on a JMS Queue. If this message was part of a transaction, the transaction commits.
2. The message is removed from the JMS queue to be processed by the Tuxedo Queuing Bridge Converter.
3. The Tuxedo Queuing Bridge Converter checks the message type and converts supported JMS types to JATMI buffer types.

- BytesMessage, TextMessage, XML are converted respectively to TypedCArray, TypedString, and TypedFML32. XML/FML translation is performed according to the `TranslateFML` attribute.
- Translation errors are sent to the `wlsServerErrorDestination` queue and the message is acknowledged in the JMS session.
- If an unrecognized JMS message is received: an appropriate error message is logged, the message is acknowledged, and then is discarded. This is considered a configuration error and the Tuxedo Queuing Bridge does not redirect the message to the error queue.

1. The converted message is sent to Tuxedo using the T/Domain gateway.

- Messages with a redirect set to `JmsQ2TuxQ` use JATMI `tpenqueue` to deliver the message to a Tuxedo queue.
- Messages with a redirect set to `JmsQ2TuxS` use JATMI `tpcall` to deliver the message to a Tuxedo service.

1. The `tpenqueue` is successful or `tpcall` is successful and the return results are placed in the replyQ. The message is acknowledged in the JMS session.

- If the `tpenqueue` or `tpcall` fails, Tuxedo Queuing Bridge delivers the message to the `wlsServerErrorDestination` queue and the message is acknowledged in the JMS session. If a `wlsServerErrorDestination` queue is not configured, the message is discarded and the Tuxedo Queuing Bridge processes the next available unacknowledged message.

## How Tuxedo Queuing Bridge connects Tuxedo to JMS

Note: Tuxedo Queuing Bridge uses a transaction to prevent the loss of messages while transferring messages from Tuxedo /Q to a JMS queue.

This section provides information on how Tuxedo messages flow through the Tuxedo Queuing Bridge to a JMS queue using the `TuxQ2JmsQ` redirect.

1. Tuxedo Queuing Bridge polls the Tuxedo queue for available messages.
2. A Tuxedo service places a message on a Tuxedo queue.
3. Tuxedo Queuing Bridge uses JATMI `tpdequeue` to forward the message from Tuxedo and places the message in the JMS queue.

- If a message cannot be redirected to a JMS queue for any reason after the specified retries have been exhausted, the message is put into the `tuxErrorDestination` queue within the same queue space as the Tuxedo queue.
- If the Tuxedo Queuing Bridge is not able to put the message into the `tuxErrorDestination` queue for any reason, an error is logged and the message is lost.
- If the `tuxErrorDestination` queue is not specified, the message is lost.

## Tuxedo Queuing Bridge Limitations

The Tuxedo Queuing Bridge has the following limitations:

- Transactions are not used when retrieving messages from the JMS location and placing them on the Tuxedo queue or invoking a Tuxedo service.
- Tuxedo Queuing Bridge is thread intensive. A thread is used to transport each message from JMS queue to Tuxedo. A polling thread is required to monitor the configured Tuxedo queue.
- The XML/FML translator is intended to construct simple message structures. For more information on XML to FML conversion see, FML32 Considerations.

# Configuring the Tuxedo Queuing Bridge

Tuxedo Queuing Bridge connectivity is determined by configuring the attributes in the Tuxedo Queuing Bridge and Redirections of your WTC Service. These attributes contain the necessary information to establish a connection to Tuxedo.

## Starting the Tuxedo Queuing Bridge

The Tuxedo Queuing Bridge is started as part of the WebLogic Server application environment if the Tuxedo Queuing Bridge and Redirections of your WTC Service are configured and the WTC Service is is deployed to a target server. Any configuration condition that prevents the Tuxedo Queuing Bridge from starting results in an error being logged.

## Error Logging

WebLogic Tuxedo Connector errors are logged to the WebLogic Server error log.

# Tuxedo Queuing Bridge Connectivity

Note: JMS message types: MapMessage, ObjectMessage, StreamMessage are not valid in WebLogic Tuxedo Connector. If one of these message types is received by the Tuxedo Queuing Bridge, a log entry is generated indicating this is an unsupported type and the message is discarded.

The Tuxedo Queuing Bridge establishes a one-way data connection between instances of a JMS queue and a Tuxedo /Q or a JMS queue and a Tuxedo service. This connection is represented by the Tuxedo Queuing Bridge and Redirections configurations of your WTC Service and provides a one-to-one connection between the identified points. Three types of connections can be configured. The following is a description of each of the connection types:

- `JmsQ2TuxQ`: Reads from a given JMS queue and transports the messages to the specified Tuxedo /Q.
- `TuxQ2JmsQ`: Reads from a Tuxedo /Q and transports the messages to JMS.
- `JmsQ2TuxS`: Reads from a given JMS queue, synchronously calls the specified Tuxedo service, and places the reply back onto a specified JMS queue.

# Example Connection Type Configurations

The following sections provide example configurations for each connection type.

## Example JmsQ2TuxQ Configuration

The following section provides an example configuration in the `config.xml` file for reading from a JMS queue and sending to Tuxedo /Q.

>     <WTCtBridgeRedirect
>          Direction="JmsQ2TuxQ"
>          Name="redir0"
>          ReplyQ="RPLYQ"
>          SourceName="weblogic.jms.Jms2TuxQueue"
>          TargetAccessPoint="TDOM2"
>          TargetName="STRING"
>          TargetQspace="QSPACE"
>          TranslateFML="NO"/>

The following section describes the components of the `JmsQ2TuxQ` configuration:

- The `Direction` connection type is `JmsQ2TuxQ`.
- `Source Name` specifies the name of the JMS queue to read is `weblogic.jms.Jms2TuxQueue`. The Tuxedo Queuing Bridge establishes a JMS client session to this queue using CLIENT_ACKNOWLEDGE semantics.
- `Target Access Point` specifies the name of the access point is `TDOM2.`
- `Target Qspace` specifies the name of the Qspace is `Qspace`.
- `Target Name` specifies the name of the queue is `STRING.`
- `ReplyQ` specifies the name of a JMS reply queue is `RPLYQ`. Use of this queue causes `tpenqueue` to provide `TMFORWARD` functionality.
- `TranslateFML` set to NO specifies that no data translation is provided by the Tuxedo Queuing Bridge.

The following table provides information on JmsQtoTuxQ message mapping:

From: JMS Message Type | To: WebLogic Tuxedo Connector JATMI (Tuxedo)
--- | ---
BytesMessage | TypedCArray
TextMessage (translateFML = NONE) | TypedString
TextMessage (translateFML = FLAT) | TypedFML32

## Example TuxQ2JmsQ Configuration

The following section provides an example configuration in the `config.xml` file for reading from a Tuxedo /Q and sending to a JMS queue.

>     <WTCtBridgeRedirect
>          Direction="TuxQ2JmsQ"
>          Name="redir1"
>          SourceAccessPoint="TDOM2"
>          SourceName="STRING"
>          SourceQspace="QSPACE"
>          TargetName="weblogic.jms.Tux2JmsQueue"
>          TranslateFML="NO"/>

The following section describes the components of the `TuxQ2JmsQ` configuration:

- The `Direction` connection type is `TuxQ2JmsQ`.
- `Target Name` specifies the name of the JMS queue to read is `weblogic.jms.Tux2JmsQueue`.
- `Source Access Point` specifies the name of the access point is `TDOM2.`
- `Source Qspace` specifies the name of the Qspace is `Qspace.`
- `Source Name` specifies the name of the queue is `STRING.`
- `TranslateFML` set to NO specifies that no data translation is provided by the Tuxedo Queuing Bridge.
- `TranslateFML` set to Flat specifies that the data is translated from FML to XML by the Tuxedo Queuing Bridge.

The following table provides information on TuxQ2JmsQ message mapping:

From: WebLogic Tuxedo Connector JATMI (Tuxedo) | To: JMS Message Type
--- | ---
TypedCArray | BytesMessage
TypedString (translateFML = NO) | TextMessage
TypedFML32 (translateFML = FLAT) | TextMessage
TypedFML (translateFML = FLAT) | TextMessage
TypedXML | TextMessage

## Example JmsQ2TuxS Configuration

Note: For more information on XML/FML conversion, see Using FML with WebLogic Tuxedo Connector.

The following section provides an example configuration in the `config.xml` file for reading from a JMS queue, calling a Tuxedo service, and then writing the results back to a JMS queue.

>     <WTCtBridgeRedirect
>          Direction="JmsQ2TuxS"
>          Name="redir0"
>          ReplyQ="weblogic.jms.Tux2JmsQueue"
>          SourceName="weblogic.jms.Jms2TuxQueue"
>          TargetAccessPoint="TDOM2"
>          TargetName="TOUPPER"
>          TranslateFML="FLAT"/>

The following section describes the components of the `JmsQ2TuxS` configuration:

- The `Direction` connection type is `JmsQ2TuxS`.
- `Source Name` specifies the name of the JMS queue to read is `weblogic.jms.Jms2TuxQueue`.
- `Target Access Point` specifies the name of the access point is `TDOM2.`
- `Target Name` specifies the name of the queue is TOUPPER`.`
- `ReplyQ` specifies the name of the JMS reply queue is weblogic.jms.Tux2JmsQueue`.`
- `TranslateFML` set to `FLAT` specifies that when a JMS message is received, the message is in XML format and is converted into the corresponding FML32 data buffer. The message is then placed in a `tpcall` with arguments `TDOM2` and TOUPPER`.` The resulting message is then translated from FML32 into XML and placed on the `weblogic.jms.Tux2JmsQueue`.

The following table provides information on the JMSQ2TuxX message mapping:

JMS Message Type | WebLogic Tuxedo Connector JATMI (Tuxedo) | JMS Message Type
--- | --- | ---
BytesMessage | TypedCArray | BytesMessage
TextMessage (translateFML = NONE) | TypedString | TextMessage
TextMessage (translateFML = FLAT) | TypedFML32 | TextMessage

# Priority Mapping

WebLogic Tuxedo Connector supports multiple Tuxedo Queuing Bridge redirect instances. In many environments, using multiple redirect instances significantly improves application scalability and performance. However, it does randomizes the order in which messages are processed. Although priority mapping does not guarantee ordering, it does provides a mechanism to react to messages based on an assigned importance. If the order of delivery must be guaranteed, use a single Tuxedo Queuing Bridge redirect instance.

Use Priority Mapping to map priorities between the JMS and Tuxedo.

- JMS has ten priorities (0 - 9).
- Tuxedo/Q has 100 priorities (1 - 100).

This section provides a mechanism to map the priorities between the Tuxedo and JMS subsystems. There are two mapping directions:

- `JmstoTux`
- `TuxtoJms`

Defaults are provided for all values, shown below in pairs of `value`:`range`.

- The `value` specifies the given input priority.
- The `range` specifies a sequential group of resulting output priorities.

`JmstoTux`- 0:1 | 1:12 | 2:23 | 3:34 | 4:45 | 5:56 | 6:67 | 7:78 | 8:89 | 9:100

`TuxtoJms`- 0:1-10|1:11-20|2:21-30|3:31-40|4:41-50|5:51-60|6:61-70|7:71-80|8:81-90|9:91-100

For this configuration, a JMS message of priority 7 is assigned a priority of 78 in the Tuxedo /Q. A Tuxedo /Q with a priority of 47 is assigned a JMS priority of 4.

# Error Queues

When Tuxedo Queuing Bridge encounters a problem retrieving messages from Tuxedo Queue or JMS Queue after the retry interval:

- The information is logged.
- The message is saved in the error queue if it is configured.

## WLS Error Destination

The `WLS Error Destination` queue is used if a JMS message cannot be properly delivered due to Tuxedo failure or a translation error.

## Unsupported Message Types

If an unrecognized JMS message is received, an appropriate error message is logged and the message is discarded. This is considered a configuration error and the Tuxedo Queuing Bridge does not redirect the message to the error queue.

## Tuxedo Error Queue

The `Tuxedo Error Queue` is the failure queue for the JATMI primitive `tpdequeue` during a `TuxQ2JmsQ` redirect.

## Limitations

The Tuxedo Queuing Bridge error queues have the following limitations:

- `Tuxedo Error Destination` can be specified only once. Any error queue name associated with the `ErrorDestination` implies that all the QSPACEs have the same error queue name available.
- When there is an error, the message is put back in the source QSPACE. Assuming the QSPACE is corrupted or full, subsequent messages would be lost.
- There is no way to drop messages on error. All messages are received or none are received.
- Information about the error is only available in the server log.