Transports and Interfaces: Siebel Enterprise Application Integration > EAI MQSeries Transport > About Siebel EAI MQSeries Transport >

About the EAI MQSeries Server Transport

Before using the EAI MQSeries Server Transport, you need to install and configure IBM MQSeries software. Contact your IBM sales representative for details.

Configuring the EAI MQSeries Server Transport

The Siebel EAI MQSeries Server Transport is designed to provide a messaging solution to help you integrate data between Siebel Business Applications and external applications that can interface with the IBM MQSeries. The EAI MQSeries Server Transport transports messages to and from IBM MQSeries queues.

NOTE:  The EAI MQSeries Server Transport can connect only to IBM MQSeries Server software. The IBM MQSeries server must be running on the same system with your Siebel Server.

The EAI MQSeries Server Transport supports the inbound and outbound methods described in the Outbound Methods for a Transport Business Service and Inbound Methods for a Transport Business Service.

Using the SendReceive Method with MQSeries

The SendReceive method on the EAI MQSeries Server Transport sends a message and waits for a response from the target application on a response queue. This response message corresponds to the original message using the correlation ID in MQSeries.

NOTE:  It is the responsibility of the external application to set the correlation ID of the response to the Siebel Business Application to the message ID of the original message.

Using the EAI MQSeries Server Transport on AIX

When you use the EAI MQSeries Server Transport on AIX, the shared memory segment required by the EAI MQSeries Server process can collide with the shared memory segment required by the queue manager. By default, the EAI MQSeries queue manager tries to use shared memory segment number 8. The EAI MQSeries Server Transport does not rely on any specific number and uses whatever segment is given to the process by the AIX operating system.

However, if you are using the default configuration, there is a possibility that the EAI MQSeries Server process gets segment number 8 from the operating system first, and as a result the queue manager cannot get its segment. In this case, the MQSeries Server Transport service fails with an error code of 2059 because it cannot connect to the queue manager.

To fix a shared memory segment conflict with the EAI MQSeries Server Transport 5.2 on AIX

1. Shut down any queue manager connected to the EAI MQSeries Transport.
2. Edit the file /var/mqm/mqs.ini. In the QueueManager section, for each queue manager of interest, add an additional line explicitly specifying the shared memory segment to use. For example:

   QueueManager:
   Name=myQueueManager
   Prefix=/var/mqm
   Directory=myQueueManager
   IPCCBaseAddress=12

3. Restart each queue manager.

NOTE:  This example shows shared number 12 used as the memory segment number. Possible legal values for the IPCCBaseAddress are 4, 5, 8, 9, 10, 11, and 12, although 8 has been found to be problematic. It is possible to run into this error even with the memory segment number set as 12 if the operating system has non-deterministically allocated segment 12 to the EAI MQSeries Server process ahead of the queue manager. If this is the case, a different segment number may need to be specified.

If the EAI MQSeries Server Transport business service on AIX continues to fail even after you have followed the previous procedures, you can configure the AIX environment to run Siebel Server with less memory using environment variable LDR_CNTRL. After you have finished, follow the procedures in the preceding section.

To configure the AIX environment to run Siebel Server with less memory

1. Shut down Siebel Server.
2. In the shell that you use to bring up Siebel Server, set the environment variable LDR_CNTRL. Using csh:

   setenv LDR_CNTRL MAXDATA=0x30000000

   NOTE:  You can save the setting in the siebenv.sh or siebenv.csh.

3. Restart Siebel Server with this environment variable.

EAI MQSeries Server Transport Parameters

In addition to supporting the common transport parameters presented in Table 4, the EAI MQSeries Server Transport also uses the parameters shown in Table 5. These can be specified as either service method arguments, subsystem parameters, or user properties.

NOTE:  In order to send to a model queue, the model queue must have a definition type of PERMANENT and the following arguments must be supplied in the workflow process: Model Queue, Physical Queue, Queue Manager, and Message Text.

In addition to the EAI MQSeries Server Transport, you can run the MQSeries Server Receiver, which is a server component that periodically checks the MQSeries queues you specify, for inbound messages.

NOTE:  The persistence of the message is the same as the persistence of the queue itself.

Dispatch Error Handling for the EAI MQSeries Server Transport

When using ReceiveDispatch and ReceiveDispatchSend methods, you need to be aware of specific MQSeries behavior that might affect your messages.

NOTE:  The transaction does not end when the message is received from the queue because it waits for the entire dispatch process to either complete successfully for commit or fail for rollback.

If all the following conditions are met, the message is sent to the Backout Requeue Queue of the current queue manager:

• A dispatch error has occurred.
• The RollbackOnDispatchError property is set to TRUE.
• The message has been rolled back by a count exceeding the Backout Threshold of the queue.

NOTE:  If the Backout Requeue Queue has not been specified for the Queue Manager, then the message is sent to the Dead Letter Queue of the current queue manager. If there is no specified Dead Letter Queue for the current queue manager, then the queue defaults to the SYSTEM.DEAD.LETTER.QUEUE.

Exposing MQMD Headers as Properties

The EAI MQSeries Server Transport feature exposes all the MQMD headers as properties of a property set.

You can set any MQMD message header for the Siebel application by specifying it as property in a property set on the outbound side. Whereas on the inbound side, the MQMD message header of the response is exposed to the user as property on the output property set.

On the inbound side you can have all the MQMD message headers as part of the output property set without having to do extra steps to see these MQMD message headers.

On the outbound side, you can set the MQMD message headers using the EAI MQSeries Server Transport. In order to modify the MQMD message headers on the outbound side, the property value for FullMQMDControl needs to be set to TRUE.

During the sending business service step (EAI MQSeries Server Transport.Send) within the workflow process, input arguments are added that can modify MQMD headers. Once the property FullMQMDControl is set to TRUE, you can modify other MQMD headers as the examples reflect in Table 6:

NOTE:  When using the Message Type header (MQMD_S_In_MsgType), make sure that the message type set makes sense in context. For example, if the Send method is used to send a message to MQSeries, the MsgType should not be set to MQMT_REQUEST. If the SendReceive method is used to send and request a response from MQSeries, then the MsgType of MQMT_REQUEST is applicable (this is automatically set by the Siebel application). In Table 6, MsgType is set to TestMsgHeader.

Table 7 summarizes the MQMD message headers that are exposed as properties in a property set.