Transports and Interfaces: Siebel Enterprise Application Integration > EAI JMS Transport > Configuring the EAI JMS Transport >

About the JMS Receiver


The JMS Receiver is a Siebel Server component that makes it possible for the JMS Transport to be invoked asynchronously. The JMS Receiver:

  • Listens for messages arriving on a JMS queue or topic and takes action whenever a message arrives.
  • Repeatedly invokes a single method of the JMS Transport: ReceiveDispatch, ReceiveDispatchSend, or SubscribeDispatch.
  • Takes a message from the queue and dispatches it to the corresponding workflow or business service for execution. If execution is successful, the message is committed to the queue. If there is an error, the message is rolled back to the queue.
  • Uses AUTO_ACKNOWLEDGE mode. In AUTO_ACKNOWLEDGE mode, the session automatically acknowledges the receipt of a message when it has either successfully returned from a call to receive or the message listener it has called to process the message successfully returns.

About Multithreading in the JMS Receiver

In Siebel CRM version 8.1.1.11, Siebel CRM version 8.2.2.4, and later, the JMS Receiver is multithreaded and operates in batch mode. A new Siebel Server component, EAIJMSRcvr, has been defined for this purpose. (In previous versions, it was single threaded and ran in the background.)

When a JMS Receiver task is started, a main task and several worker threads are created, whose number depends on the MinWorkQThreads and MaxWorkQThreads parameters listed in Table 17.

NOTE:  The JMS Receiver task must be started manually. It does not start automatically when the Siebel Server is started.

After the worker threads are created, the main task thread starts calling the specified method on the EAI JMS Transport business service in an infinite loop, until a shutdown component is signaled. At the same time, the worker threads start their own infinite loop and perform the same duties as the main thread: they call the specified method on the EAI JMS Transport business service.

In effect, the ReceiveDispatchSend operation (or any method specified) is now called by multiple threads in the same task. Previously, a single sequential call to the ReceiveDispatchSend method was made in a single process. Now, the same operation happens in parallel. The thread parallelism effectively increases scalability while limiting CPU load and memory utilization.

Table 17. Siebel Server Parameters Used in Multithreading
Parameter
Description

MaxTasks

Total number of tasks that can run concurrently on a Siebel Application Object Manager. For more information on MaxTasks, see Siebel Performance Tuning Guide.

MaxMTServers

Maximum number of multithreaded processes that can run concurrently on a Siebel Application Object Manager. For more information on MaxMTServers, see Siebel Performance Tuning Guide.

MinMTServers

Minimum number of multithreaded processes that can run concurrently on a Siebel Application Object Manager. For more information on MinMTServers, see Siebel Performance Tuning Guide.

MaxWorkQThreads

Maximum number of worker threads in a process. The default is 4.

MinWorkQThreads

Minimum number of worker threads in a process. The default is 4.

MaxWorkQLength

Maximum number of work items handled by a worker thread. The default is 20.

Considerations When Using Multithreading

Multithreading works best when messages are atomic; that is, their processing does not depend on the processing of other messages. The messages can be processed in parallel without conflicts.

If one message is dependent on another, then the messages must be processed in the correct order. For example, you must create an account before creating a service request for it, and create an order before adding an order line item.

You can use validation scripting to make sure that parents are created before children. However, creating a data architecture that does not require additional scripting will deliver a performance benefit to the end-to-end solution.

About Configuring the JMS Receiver

An instance of the JMS Receiver is configured with the parameters of a JMSSubsys named subsystem, which specify the queue or topic to listen to, and the action to be taken.

The JMSReceiver task has the following three parts:

  • ReceiverConnectionSubsystem is the named subsystem.
  • ReceiverDataHandlingSubsystem dispatches the message from the ReceiveQueue to the workflow previously defined.
  • ReceiverMethodName is the EAI JMS Transport business service method invoked.

The following is an example of how an instance of the JMS Receiver can be configured and run by using the Siebel Server Manager command-line interface:

create named subsystem MyJMSConnSubsys_SR for subsystem JMSSubsys with
ConnectionFactory="weblogic.examples.jms.QueueConnectionFactory",
ReceiveQueue="weblogic.examples.jms.exampleQueueReceive",
SendQueue="weblogic.examples.jms.exampleQueueSend",
ReceiveTimeout=3000

create named subsystem SiebelEcho for subsystem EAITransportDataHandlingSubsys with
DispatchService="Workflow Utilities",
DispatchMethod="ECHO"

start task for comp JMSReceiver with
ReceiverConnectionSubsystem=MyJMSConnSubsys_SR,
ReceiverDataHandlingSubsystem=SiebelEcho,
ReceiverMethodName=ReceiveDispatchSend

For a detailed workflow example using a JMS Receiver, see Receiving, Dispatching, and Sending JMS Messages. For a discussion of named subsystems for Siebel EAI, see EAI Transports and Interfaces Overview. For more information on administering named subsystems, see Siebel System Administration Guide.

Transports and Interfaces: Siebel Enterprise Application Integration Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices.