6EAI JMS Transport
EAI JMS Transport
This chapter discusses the EAI JMS Transport business service. It includes the following topics:
About the EAI JMS Transport Business Service
The EAI JMS Transport business service is an API for accessing enterprise messaging systems. It supports the ability to send and receive messages by way of Java Message Service (JMS) servers. JMS defines two messaging models: point-to-point (by way of JMS queues) and publish-and-subscribe (by way of JMS topics). Both are supported by the Siebel EAI JMS Transport.
JMS queues and topics are identified by their Java Naming and Directory Interface (JNDI) names. A JNDI naming service is required to use the EAI JMS Transport. It contains entries for the queues and topics used.
Invoked Business Service methods read the JNDI properties in the Siebel application framework using the classpath defined for a named subsystem and then pass the information using HTTP to the Java layer that resides in the Java Web Container server.
The API of the EAI JMS Transport is very similar to other Siebel messaging APIs such as the EAI MQSeries Server Transport and EAI MSMQ Transport.
The EAI JMS Transport is built using the Java Business Service and therefore inherits all the requirements of that business service. This includes the independent installation of a Java Virtual Machine (JVM) and the configuration of the Siebel application to identify and create the JVM.
Oracle supports integration, using the EAI JMS Transport, with any JMS provider that conforms to the JMS 1.0.2b standard. The EAI JMS Transport provides support for basic integration with both queues and topics, with message types that are specified in About JMS Message Types.
Oracle does not support any vendor extensions to the JMS standard except where specified enhanced functionality is released and documented as part of a Siebel CRM release. The EAI JMS Transport provides basic JMS 1.0.2b functionality as described in this chapter. This transport does not provide access to advanced capabilities, such as any capabilities of the JMS 1.1 standard that are not backward-compatible with JMS 1.0.2b, or provide access to any other functionality that is not described in the Siebel Bookshelf. For information about JMS standards, see:
About Synchronous and Asynchronous Invocation
Like the EAI MQSeries Server Transport, the EAI JMS Transport has two modes of execution: synchronous and asynchronous. Synchronous execution involves invoking individual methods of the JMS Transport directly, just like any other business service. Because the caller waits for the method to return, such invocation is synchronous. Asynchronous execution means listening for messages arriving on a particular queue and taking action whenever one arrives. This involves the creation of a separate Siebel component, called a JMS Receiver. Like the MQ Receiver, whenever a message arrives on the queue, the JMS Receiver dispatches to a business service (or workflow) and optionally sends a reply message.
About the JMS Publish-and-Subscribe Model
The traditional message model, where a message is sent to a queue and later removed by a single receiver, is called point-to-point messaging. In addition to this familiar model, JMS also supports the publish-and-subscribe messaging model. Here, messages are published to topics, rather than sent to queues. Interested receivers subscribe to individual topics and receive a copy of each message published to the topic. To subscribe, a subscriber registers with the topic, providing a unique identifier.
For more information about the JMS publish-and-subscribe model, see:
http://www.oracle.com/technetwork/java/jms/index.html
JMS queues and topics are identified by their JNDI names. A JNDI naming service is required to use the JMS Transport. The JNDI naming service contains entries for the JMS queues (implementers of javax.jms.Queue) and topics (implementers of javax.jms.Topic) used, as well as the necessary JMS connection factories (implementers of either javax.jms.QueueFactory or javax.jms.Topic).
All methods that receive messages automatically time out if no message is available. The timeout length is three seconds by default and can be specified by the ReceiveTimeout argument.
Whether a call to Receive or Subscribe timed out is provided as the TimedOut property of the output property set.
Subscriptions to JMS topics are always durable subscriptions.
The term dispatch is used to refer to the operation of calling a business service or workflow, passing as input the content of a newly received message.
About Operations (Methods) of the EAI JMS Transport
The following is a summary of supported operations for use with the EAI JMS Transport:
Receive. Receive a message from a JMS queue.
ReceiveDispatch. Receive a message from a JMS queue, then dispatch.
ReceiveDispatchSend. Receive a message from a JMS queue, dispatch, and then send the result to a (possibly different) JMS queue.
Send. Send a message to a JMS queue.
SendReceive. Send a message to a JMS queue then receive a message from a (possibly different) JMS queue.
The JMSCorrelationID header of the reply message must be equal to the JMSCorrelationID of the message sent, unless it is null (if none was provided as an input to SendReceive), in which case it must be the JMSMessageID of the message sent.
Subscribe. Receive a message from a JMS topic. The subscriber identifier must be supplied as an input to this method.
SubscribeDispatch. Receive a message from a JMS topic, then dispatch. The subscriber identifier must be supplied as an input to this method.
Publish. Publish a message to a JMS topic.
The arguments to these methods and their exact semantics (along with valid values, default values, and so on) are described in the topic Detailed Input and Output Specifications for the EAI JMS Transport. All methods require the JNDI name of JMS ConnectionFactory and the JNDI name of the queue or topic.
Features Not Supported for Use with the Siebel JMS Transport
The following features are not supported for use with the Siebel JMS Transport:
Message Selection. JMS has a feature called Message Selection, by which a receiver or subscriber can filter the messages it receives by specifying certain criteria. This feature is not supported by the Siebel JMS Transport.
Concurrency with non-JMS messaging. It is not recommended that JMS messaging be used concurrently (for a single queue) with non-JMS messaging. For example, it is not recommended that a message be sent by way of JMS and later read using native tools. JMS vendors do not typically support such usage; it can result in the appearance of additional headers or additional obscure data in the body of the message.
Transport Layer Security (TLS). The Siebel JMS Transport is primarily designed to support message exchange with external messaging systems (providers) using the JMS 1.0.2b standard. The JMS standard is not bound to transport layers, such as TCP/IP, and does not address transport layer-specific features, such as securing TCP/IP socket connections using TLS. For information about enabling and using TLS with the Siebel JMS Transport, contact the vendor of your JMS system. For information about the JMS 1.0.2b standard, see:
About JMS Message Types
JMS defines five types of messages: TextMessage, BytesMessage, ObjectMessage, MapMessage, and StreamMessage. The Siebel JMS Transport supports only the types TextMessage and BytesMessage. If the JMS Transport receives an ObjectMessage, MapMessage, or StreamMessage from the JMS server, then the error Unsupported Message Type is produced.
Like all Siebel business services, the output of any method is a property set. If a BytesMessage is received, then the value of the property set has Binary type. If a TextMessage is received, then the value has String type.
Conversely, the input to any method is also a property set. For methods that involve sending or publishing a message, the type of message sent or published depends on the type of the value of the input property set. If the type is Binary, then a BytesMessage is sent and published. If the type is String, then a TextMessage is sent and published.
About Sending and Receiving XML
Messages whose content is XML are generally best treated as binary data and sent as BytesMessages. For example, the output of the Siebel business service EAI XML Converter is binary; therefore, if this is passed as the input to Send, then a BytesMessage is sent.
If XML is sent as a TextMessage, then the characters are encoded as UTF-16. Therefore, the XML document declares its encoding to be UTF-16.
Typically, when a message containing an XML document is received by the Siebel application, it is desirable to convert the document to a property set representation before processing it. This is accomplished automatically during the Dispatch step by specifying the ConverterService argument to be either XML Converter or EAI XML Converter. For more details about these converter services see XML Reference: Siebel Enterprise Application Integration.
About Multistep Operations Within a JMS Session
All JMS operations are performed in the context of a transactional JMS QueueSession. If a send or receive operation throws an exception, then the session is immediately rolled back. If the operation is successful, then the session is committed, unless the operation is part of a larger multistep operation. In the case of multistep operations, the transaction is handled as follows:
SendReceive. If the send operation succeeds, then the JMS session is committed and a receive operation is performed. This is necessary because the receive operation might depend on a response to the first message.
ReceiveDispatch. If the receive operation fails, then the JMS session is rolled back, and the dispatch operation is not attempted. If the receive operation succeeds, then the dispatch operation is attempted. If the dispatch succeeds, then the JMS session is committed; otherwise, both the Siebel transaction and the JMS session are rolled back.
SubscribeDispatch. Same as ReceiveDispatch.
ReceiveDispatchSend. If the receive operation fails, then the JMS session is rolled back, and further operations are not attempted. If the receive operation succeeds, then the dispatch operation is attempted. If the dispatch operation fails, then the JMS session and the Siebel transaction are rolled back; otherwise, the send operation is attempted. If the send operation fails, then the JMS session and the Siebel transaction are rolled back; otherwise, both are committed.
Each Dispatch operation is performed within a Siebel transaction.
Also, as with all Siebel EAI receivers, if an operation fails during the execution of the JMS Receiver, then the JMS Receiver component terminates. (A timeout is not a failure.)
About Undeliverable Messages in JMS Transport
If a message is undeliverable, in the sense that repeated attempts by the Siebel JMS Transport to receive the message fail, then the message must be removed from the queue. Most JMS vendors provide some mechanism for dealing with such “poison messages” Oracle WebLogic, for example, can be configured to limit the number of times it attempts to deliver a message before redirecting the message to an error queue or deleting the message altogether.
Detailed Input and Output Specifications for the EAI JMS Transport
This topic provides detailed information about the exact semantics of all input arguments and output values for each method of the EAI JMS Transport.
The following topics are discussed:
JMS Headers and Properties
Every JMS message has a set of standard headers. Some of these headers can be specified as arguments to the methods of the JMS Transport that involve sending or publishing, and some are available as properties of the output property set of methods that involve receiving or subscribing. These are detailed in the tables in Input Arguments Used by the Dispatch Step, Input Argument Values, and About the Output of the JMS Transport.
A JMS message can also be assigned properties. These might be user-defined properties specific to a particular application, or JMS-defined properties (for example JMSXProducerTXID) that are optionally supported by the JMS vendor. A property can be an instance of any Java class or any of the primitive Java types. All properties of a message received by the Siebel JMS Transport are available as properties of the output property set.
The name of the property is the original name with the eleven characters SIEBEL_JMS: prefixed; the value is the string obtained by converting the original value to a Java String. Conversely, when a message is sent, any property of the input property set whose name begins with SIEBEL_JMS: is added to the message as a JMS Message string property with the prefix SIEBEL_JMS: removed. For example, the property SIEBEL_JMS:foo is added to the message as the string property foo.
Input Arguments Used by the Dispatch Step
The following table shows the options for each input argument of the JMS Transport methods, except the user-defined properties and arguments used by the Dispatch step. R denotes a required argument; NR denotes an optional argument (not required); and I denotes an argument that is ignored. Notes following the table provide further explanation for particular values.
| Input Argument | Send |
Publish |
Send Receive |
Receive |
Subscribe |
Receive Dispatch |
Receive Dispatch Send |
Subscribe Dispatch |
|---|---|---|---|---|---|---|---|---|
ConnectionFactory |
R |
R |
R |
R |
R |
R |
R |
R |
ReceiveQueue |
I |
I |
R |
R |
I |
R |
R |
I |
ReceiveTimeout |
I |
I |
NR |
NR |
NR |
NR |
NR |
NR |
SendQueue |
R |
I |
R |
I |
I |
I |
R |
I |
Topic |
I |
R |
I |
I |
R |
I |
I |
R |
ConnectionUsername |
NR |
NR |
NR |
NR |
NR |
NR |
NR |
NR |
ConnectionPassword |
NR |
NR |
NR |
NR |
NR |
NR |
NR |
NR |
SendUsername |
NR |
I |
NR |
I |
I |
NR |
I |
I |
SendPassword |
NR |
I |
NR |
I |
I |
NR |
I |
I |
ReceiveUsername |
I |
I |
NR |
I |
I |
I |
NR |
I |
ReceivePassword |
I |
I |
NR |
I |
I |
I |
NR |
I |
TopicUsername |
I |
NR |
I |
I |
NR |
I |
I |
NR |
TopicPassword |
I |
NR |
I |
I |
NR |
I |
I |
NR |
SubscriberIdentifier |
I |
I |
I |
I |
R |
I |
I |
R |
JMS Headers |
||||||||
JMSPriority |
NR |
NR |
NR |
I |
I |
I |
NR 2 |
I |
JMSDeliveryMode |
NR |
NR |
NR |
I |
I |
I |
NR 2 |
I |
JMSExpiration |
NR |
NR |
NR |
I |
I |
I |
NR 2 |
I |
JMSReplyTo |
NR |
NR |
I |
I |
I |
I |
NR 2 |
I |
JMSType |
NR |
NR |
NR |
I |
I |
I |
NR 2 |
I |
JMSCorrelationID |
NR |
NR |
NR |
I |
I |
I |
I |
I |
Dispatch |
||||||||
Connection Subsystem |
NR |
NR |
NR |
NR |
NR |
NR |
NR |
NR |
DataHandling Subsystem |
I |
I |
I |
I |
I |
NR |
NR |
NR |
DispatchService |
I |
I |
I |
I |
I |
R |
R |
R |
DispatchMethod |
I |
I |
I |
I |
I |
R |
R |
R |
DispatchWorkflow Process |
I |
I |
I |
I |
I |
R |
R |
R |
DispatchRuleSet |
I |
I |
I |
I |
I |
R |
R |
R |
ConverterService |
I |
I |
I |
I |
I |
NR |
NR |
NR |
Some special notes regarding particular values in the previous table:
When the JMSReplyTo header is used, the SendQueue value is ignored.
When the JMSPriority, JMSDeliveryMode, JMSExpiration, JMSReplyTo, or JMSType header is used, these values are assigned to the reply message during the Send step.
The JMSReplyTo header of the sent message is set to the value of the ReceiveQueue argument.
The JMSCorrelationID header of the reply message cannot be set directly. The JMSCorrelationID of the reply message is set to the JMSCorrelationID of the received message, unless empty, in which case it is set to its JMSMessageID.
For DispatchService, DispatchMethod, DispatchWorkflowProcess, and DispatchRuleSet method arguments, one of the following three combinations is required:
(DispatchService && DispatchMethod)
DispatchWorkflowProcess
DispatchRuleSet
The ConnectionUsername and ConnectionPassword input parameters apply to IBM WebSphere MQ only.
Note: When sending messages to IBM WebSphere MQ, ConnectionUsername and ConnectionPassword are required for the Windows 2012 Server platform and recommended for all other Windows platforms.The SendUsername, SendPassword, ReceiveUsername, ReceivePassword, TopicUsername, and TopicPassword input parameters apply to Oracle WebLogic only.
The JMSType and JMSCorrelationID input arguments can also be used as output arguments.
For the ConnectionSubsystem input argument, a subsystem can be provided instead of the connection parameters. However, it must contain the same required method arguments as used for the connection parameters.
For the DataHandlingSubsystem input argument, a subsystem can be provided instead of the dispatch parameters. However, it must contain the same required method arguments as used for the dispatch parameters.
The ConverterService input argument is used to process the output of the received message before dispatching.
In place of providing the arguments individually, the single argument ConnectionSubsystem can be provided. Its value must be the name of a valid named subsystem of type JMSSubsys, and it must include all of the arguments that are required by the method to which it is passed. See About the JMS Receiver for more information about that named subsystem.
JMS message properties are also supported as input arguments (properties) as described in JMS Headers and Properties.
Input Argument Values
The following table provides details for each input argument about the allowable values, default values, and special values, as well as the behavior if an invalid value is passed.
| Input | Default | Allowable Values | Special Values | If Value Invalid |
|---|---|---|---|---|
ConnectionFactory |
NONE |
JNDI connection factory name |
Not applicable |
ERROR |
ReceiveQueue |
NONE |
JNDI queue name |
Not applicable |
ERROR |
ReceiveTimeout |
3000 |
Any integer greater than to 0
Caution: Be careful NOT to set the value less than or equal to 0.
|
Not applicable |
Noninteger defaults to 3000 |
ConnectionUsername |
NONE |
Valid username |
Not applicable |
Not applicable |
ConnectionPassword |
NONE |
Valid password |
Not applicable |
Not applicable |
SendQueue |
NONE |
JNDI queue name |
Not applicable |
ERROR |
SendUsername |
NONE |
Valid username |
Not applicable |
Not applicable |
SendPassword |
NONE |
Valid password |
Not applicable |
Not applicable |
ReceiveUsername |
NONE |
Valid username |
Not applicable |
Not applicable |
ReceivePassword |
NONE |
Valid password |
Not applicable |
Not applicable |
TopicUsername |
NONE |
Valid username |
Not applicable |
Not applicable |
TopicPassword |
NONE |
Valid password |
Not applicable |
Not applicable |
Topic |
NONE |
JNDI topic name |
Not applicable |
ERROR |
SubscriberIdentifier |
NONE |
ANY STRING |
Not applicable |
Not applicable |
JMS Headers |
||||
JMSCorrelationID |
NOT SET |
ANY STRING |
Not applicable |
Not applicable |
JMSPriority |
javax.jms.Message. DEFAULT_PRIORITY (4) |
Any integer from 0 to 9 |
(0 lowest; 9 highest) |
DEFAULT |
JMSDeliveryMode |
javax.jms.Delivery Mode.PERSISTENT |
PERSISTENT, NON_PERSISTENT |
Not applicable |
DEFAULT |
JMSExpiration |
javax.jms.Message. DEFAULT_TIME_TO_ LIVE (0) |
Any nonnegative integer |
0: Message never expires |
DEFAULT |
JMSReplyTo |
NOT SET |
JNDI queue name |
Not applicable |
ERROR |
JMSType |
SiebelJMSMessage |
ANY STRING |
Not applicable |
Not applicable |
Dispatch |
||||
ConnectionSubsystem |
NONE |
A JMSSubsys named subsystem |
Not applicable |
ERROR |
DataHandlingSub system |
NONE |
An EAITransportData HandlingSubsys named subsystem |
Not applicable |
ERROR |
DispatchService |
NONE |
Business service name |
Not applicable |
ERROR |
DispatchMethod |
NONE |
Business service method |
Not applicable |
ERROR |
DispatchWorkflow Process |
NONE |
Workflow name |
Not applicable |
ERROR |
DispatchRuleSet |
NONE |
Rule set name |
Not applicable |
ERROR |
ConverterService |
NONE |
Business service name |
Not applicable |
ERROR |
About the Output of the JMS Transport
The output of the JMS Transport methods includes the following parts:
The content of the received message (if the method involves receiving a message). See the previous topic, Input Arguments Used by the Dispatch Step, for details about typing.
JMS properties of the received message (if the method involves receiving a message), as described in the topic JMS Headers and Properties.
Certain JMS headers of the message sent or received, as described in the following table.
The special properties TimedOut (if the method involves receiving a message) and DispatchError (if the method involves dispatching), as described in the following table. Each property is either True or False.
The following table enumerates for each method of JMS Transport the JMS headers and other distinguished properties that appear as properties of the output property set of the method. Yes means the argument is present; No means the argument is absent.
| Output | Send |
Publish |
Send Receive |
Receive |
Subscribe |
Receive Dispatch |
Receive Dispatch Send |
Subscribe Dispatch |
|---|---|---|---|---|---|---|---|---|
TimedOut |
No |
No |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
JMSType + |
No |
No |
Yes |
Yes |
Yes |
Yes |
No |
Yes |
JMSCorrelation ID+ |
No |
No |
Yes |
Yes |
Yes |
Yes |
No |
Yes |
JMSRedelivered |
No |
No |
Yes |
Yes |
Yes |
Yes |
No |
Yes |
JMSTimestamp |
No |
No |
Yes |
Yes |
Yes |
Yes |
No |
Yes |
JMSMessageID |
Yes 1 |
Yes 1 |
Yes 2 |
Yes 2 |
Yes 2 |
Yes |
Yes 1 |
Yes |
DispatchError |
No |
No |
No |
No |
No |
Yes |
Yes |
Yes |
Some special notes regarding the information in this table:
Yes1: JMSMessageID, the value assigned by the JMS server of the sent (or published) message.
Yes2: JMSMessageID, the value assigned by the JMS server of the received (or subscribed) message.
+: An output argument that can also be used as an input argument.
All other message properties (user-defined; not JMS headers) are provided as output properties with SIEBEL_JMS: prefixed to the original property name, and the value is converted to a String.
For the multistep methods ReceiveDispatch, ReceiveDispatchSend, and SubscribeDispatch, properties are passed between the individual steps according to the following rules:
All outputs of the Receive (or Subscribe) step are passed as inputs to the subsequent Dispatch step.
In the case of an error during the Dispatch step, its output is returned.
The input to the Dispatch step includes all properties in the original input as well as properties returned by the Receive (or Subscribe) step.
Configuring the EAI JMS Transport
The EAI JMS Transport is built using the Java Business Service and therefore inherits all the requirements of that business service. This includes the independent installation of a Java Virtual Machine (JVM) and the configuration of the Siebel application to identify and create the VM. Configuration of the Siebel application requires creating a named subsystem of type JVMSubSys with the necessary properties. Refer to the Java Business Service documentation for instructions on how to configure the JVM named subsystem.
The EAI JMS Transport requires that the CLASSPATH property of the JVM subsystem include the following packages or classes:
Siebel.jar
SiebelJI_lang.jar (where lang corresponds to the default language for your installation)
A directory containing the location of the jndi.properties file
The jndi.properties file contains the necessary name value pairs required to perform a JNDI lookup and bind to the remote queue.
Necessary classes and JAR files as required by the JMS provider.
If you want multiple JVM subsystems, then you must configure additional components. For example, you can have EAIObjMgr_WL pointing to a JVM subsystem called JAVA_WL and EAIObjMgr_ORACLE pointing to a JVM subsystem called JAVA_ORACLE.
To verify that the CLASSPATH and jndi.properties are properly configured, see Troubleshooting for the JMS Transport.
The following JMS Transport configuration topics are also discussed here:
About the JMSSubsys Named Subsystem
The arguments to any method of JMS Transport can be supplied individually as properties of the input property set or as part of a named 32-bit subsystem of type JMSSubsys. When invoking the JMS Transport asynchronously by starting a JMS Receiver component, the arguments must be supplied by way of a named subsystem.
This subsystem supplies all of the necessary parameters for any one of these three methods: ReceiveDispatch, ReceiveDispatchSend, or SubscribeDispatch. The parameters for the three methods are ConnectionFactory, ReceiveQueue, SendQueue, Topic, SubscriberIdentifier, ReceiveTimeout, JMSType, JMSPriority, JMSExpiration, and JMSDeliveryMode.
In addition, this subsystem has a property JVMSubsys, which can be given the name of the JVM subsystem instance to use. The default value is JAVA. Therefore, if the property JVMSubsys is not explicitly given a value, then there must be a properly configured instance of the type JVMSubSys named JAVA.
About the JavaContainerSubsys Named Subsystem
The arguments to any method of JMS Transport can be supplied individually as properties of the input property set or as part of a named 64-bit subsystem of type JavaContainerSubsys. When invoking the JMS Transport asynchronously by starting a JMS Receiver component, the arguments must be supplied by way of a named subsystem.
This subsystem supplies all of the necessary parameters for any one of these three methods: ReceiveDispatch, ReceiveDispatchSend, or SubscribeDispatch. The parameters for the three methods are CONTAINERURL and CLASSPATH.
For more information about configuring the JavaContainerSubsys subsystem, see Creating a 64-bit Java Subsystem by Using the Siebel Server Manager and Creating a 64-bit Java Subsystem by Using the Siebel Web Client.
About the JMS Receiver
The JMS Receiver (alias EAIJMSRcvr) 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, then the message is committed to the queue. If there is an error, then 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 Component
The JMS Receiver is multithreaded and operates in batch mode. (In some previous versions, this component was single-threaded and ran in the background.)
A task for the JMS Receiver component starts automatically when the Siebel Server is started, where Default Tasks (alias DfltTasks) is set to 1. Otherwise, you must start tasks manually. For more information about DfltTasks, see Siebel System Administration Guide.
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 the following table.
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.
| Parameter | Description |
|---|---|
MaxTasks |
Total number of tasks that can run concurrently on a Siebel Application Object Manager. For more information about 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 about 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 about 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 about administering named subsystems, see Siebel System Administration Guide.
About Reconnecting to the External JMS Queue
If the external system is not ready to receive messages, then the JMS Receiver component fails when it attempts to connect. To avoid this failure, two new parameters have been added to the JMS Receiver: CompMaxRetries and CompRetryInterval. You can set these parameters as needed.
The reconnection parameters for the JMS Receiver are described in the following table.
Table Reconnection Parameters for the JMS Receiver Component
| Parameter | Default Value | Description |
|---|---|---|
CompMaxRetries |
10 |
Specifies the number of times the reconnection is attempted. Valid values are positive integers. |
CompRetryInterval |
60 |
Specifies the interval in seconds between each retry. Valid values are positive integers. |
These parameters are used with the AutoRestart and NumRestart parameters. AutoRestart enables restart attempts when set to TRUE. NumRestart determines how many attempts are made to restart the JMS Receiver task if it fails.
CompMaxRetries and CompRetryInterval control reconnection attempts to the JMS queue to avoid JMS Receiver failure. AutoRestart and NumRestart are used when the JMS Receiver task ends with an error unrelated to losing the queue connectivity. For more information about NumRestart and AutoRestart, see Siebel System Administration Guide.
Creating a JMS Subsystem by Using the Siebel Web Client
The following is an alternative procedure for creating a JMS Subsystem by using the Siebel Web Client and then configuring the JMS Transport.
To configure the JMS Transport by using the Siebel Web Client
In the Siebel client, navigate to the Administration - Server Configuration screen, Enterprises view.
In the first list applet, select the Enterprise Server that you want to configure.
In the middle applet, click the Profile Configuration tab.
Click New to create a new component profile and set the following parameters:
Name Value Profile
JMS_Q1ReceiveDispatchSend
Alias
JMS_Q1ReceiveDispatchSend
Subsystem Type
JMSSubsys
In the Profile Parameters list applet (the last applet), specify the parameters required for the type of operations the subsystem will support (for example, Receive or ReceiveDispatchSend).
For example, if this subsystem needed to support the ReceiveDispatchSend operation, then at least the following values must be set:
Name Value ConnectionFactory
examples.jms.QueueConnectionFactory
JVM Subsystem
JAVA
ReceiveQueue
examples.jms.fromSiebel
SendQueue
examples.jms.toSiebel
Receive Timeout
1000
Sending and Receiving JMS Messages
The following procedure describes how to set up the Siebel application to send a message to an external system using the EAI JMS Transport and receive a corresponding reply from the external system.
To send and receive messages with the JMS Transport
Set up a JMS queue to receive messages from the Siebel application and give the queue an easy-to-identify name, such as fromSiebel.
Refer to your JMS provider documentation on how to administer, monitor, and define new persistent queues.
Set up a JMS queue to send messages to the Siebel application.
Refer to your JMS provider documentation on how to administer, monitor and define new persistent queues.
Give the queue an easy-to-identify name, such as toSiebel.
Create a message in the queue.
Note: To test this scenario adequately, you must have a partner application that can place a valid message for the Siebel application into the queue.Set up a workflow in Siebel Tools to send a message out and receive a message back in response using the EAI JMS Transport. The workflow should contain the following steps, as shown in the following image:
Siebel Order (Query by ID)
EAI XML Converter (IntObjHierToXMLDoc)
EAI JMS Transport (SendReceive)
EAI XML Converter (XMLDocToIntObjHier)
Siebel Order (Synchronize)
Note: For details on the Business Process Designer, see Siebel Business Process Framework: Workflow Guide.Create the following process properties:
Name Data Type In/Out Default String Comments OrderXML
Binary
In
Not applicable
Not applicable
JMSConnectionFactory
String
In
examples.jms. ConnectionFactory
JNDI name of the JMS connection factory
JMSReceiveQueue
String
In
examples.jms.toSiebel
JNDI name of the queue
JMSSendQueue
String
In
examples.jms.fromSiebel
JNDI name of the queue
JMSReceiveTimeout
String
In
180000
Not applicable
Order Message
Integration Object
In
Not applicable
Not applicable
Set up the first step of the workflow to use the Siebel Order ASI with the QueryById method to query the information from the Siebel database using the following input and output arguments:
Input Argument Type Property Name PrimaryRowId
Process Property
Object Id
Property Name Type Output Argument Order Message
Output Argument
SiebelMessage
Set up the second step of the workflow to use the EAI XML Converter with the IntObjHierToXMLDoc method to convert the data extracted from the Siebel database to XML using the following input and output arguments:
Input Argument Type Value Property Name GenerateProcessingInstructions
Literal
False
Not applicable
SiebelMessage
Process Property
Not applicable
Order Message
Property Name Type Output Argument OrderXML
Output Argument
<Value>
Set up the third step of the workflow, after Start, to use the EAI JMS Transport with the SendReceive method using the following input and output arguments:
Input Argument Type Property Name <Value>
Process Property
OrderXML
ConnectionFactory
Process Property
JMSConnectionFactory
ReceiveQueue
Process Property
JMSReceiveQueue
ReceiveTimeout
Process Property
JMSReceiveTimeout
SendQueue
Process Property
JMSSendQueue
Property Name Type Output Argument OrderXML
Output Argument
<Value>
Set up the fourth step to use the EAI XML Converter with the XMLDocToIntObjHier method to convert the XML message to an Integration Object using the following input and output arguments:
Input Argument Type Property Name <Value>
Process Property
OrderXML
Property Name Type Output Argument Order Message
Output Argument
SiebelMessage
Set up the last step to use the Siebel Order ASI with the Synchronize message to update the Siebel database using the following input and output arguments:
Input Argument Type Property Name SiebelMessage
Process Property
Order Message
Property Name Type Output Argument Order Message
Output Argument
SiebelMessage
Save and deploy the workflow.
It is recommended that the Workflow Simulator be used for testing purposes.
Note: To test this scenario adequately, you must have a partner application that can accept the message and return a response. The correlation ID of the response message must be set to the message ID of the message originally sent by the Siebel application.
Receiving, Dispatching, and Sending JMS Messages
The procedure in this section describes how to set up your system to receive inbound messages from JMS, perform an action within the Siebel application based upon the message, and send a synchronous response back to the external system.
To receive, dispatch, and send messages using EAI JMS Transport
Set up a JMS queue to receive messages from the Siebel application and give the queue an easy to identify name, such as fromSiebel.
Refer to your JMS provider documentation on how to administer, monitor, and define new persistent queues.
Set up a JMS queue to send messages to the Siebel application.
Refer to your JMS provider documentation on how to administer, monitor and define new persistent queues.
Give the queue an easy-to-identify name such as toSiebel.
Create a message in the queue.
Note: To test this scenario adequately, you must have a partner application that can place a valid message for the Siebel application into the queue.Set up a workflow in Siebel Tools to process the incoming XML request. The workflow should contain the following steps, as shown in the following image:
EAI XML Convert (XMLDocToIntObjHier): Receives an incoming XML document and converts it to an integration object.
Siebel Order ASI (QueryByExample): Executes a query using Siebel Order application service.
EAI XML Converter (IntObjHierToXMLDoc): Converts the response to an XML document.
Note: For details on the Business Process Designer, see Siebel Business Process Framework: Workflow Guide.Create the following process properties:
Name Data Type In/Out Default String Comments <Value>
Binary
In/Out
<Value>
Order Integration Object
Order Message
Hierarchy
In/Out
Not applicable
XML representation of the integration object
Set up the first step of the workflow, after Start, to use the EAI XML Converter with the XMLDocToIntObjHier method.
This step converts the incoming XML document to an integration object representation using the following input and output arguments:
Input Argument Type Property Name <Value>
Process Property
<Value>
Property Name Type Output Argument Order Message
Output Argument
SiebelMessage
Set up the second step to use the Siebel Order ASI with the QueryByExample method.
This step queries the Order business object based upon the provided XML document using the following input and output arguments:
Input Argument Type Property Name SiebelMessage
Process Property
Order Message
Property Name Type Output Argument Order Message
Output Argument
SiebelMessage
Set up the third step to use the EAI XML Converter with the IntObjHierToXMLDoc method.
This step converts the integration object to a well-formed XML document using the following input and output arguments:
Input Argument Type Property Name SiebelMessage
Process Property
Order Message
Property Name Type Output Argument <Value>
Output Argument
<Value>
Save and deploy the workflow.
For details on deploying workflows, see Siebel Business Process Framework: Workflow Guide.
Define a JMS Connection subsystem using SrvrMgr (command line utility) or the Server Administration screen.
Note: Restart the Siebel Server to make the new subsystem available.Following is an example using SrvrMgr:
Note: ConnectionFactory, ReceiveQueue and SendQueue require JNDI names, which varies depending upon the JMS provider and your implementation.create named subsystem JMSToFromSiebel for subsystem JMSSubsys with ConnectionFactory="jndiName.ConnectionFactory", ReceiveQueue="jndiName.toSiebel ", SendQueue="jndiName.fromSiebel", ReceiveTimeout=3000
Define a data handling subsystem to dispatch the message from the toSiebel queue to the workflow as previously defined (JMS Query Order):
create named subsystem QueryOrder for subsystem EAITransportDataHandlingSubsys with DispatchWorkflowProcess="JMS Query Order"
Note: The Siebel Server must be restarted in order for the data handling subsystem to be available.After restarting the Siebel Server, start a new JMS Receiver from the SrvrMgr command line.
The following is an example that instructs the receiver to use the JMSToFromSiebel connection subsystem defined in Step 9, the QueryOrder data handling subsystem defined in Step 10, and instructs the receiver to use the ReceiveDispatchSend method of the EAI JMS Transport:
start task for comp JMSReceiver with ReceiverConnectionSubsystem= JMSToFromSiebel, ReceiverDataHandlingSubsystem=QueryOrder, ReceiverMethodName=ReceiveDispatchSend
Place a message resembling the following on the toSiebel queue:
Note: A third-party product such as Hermes (available from Sourceforge.net) is required to place a message on a queue. In the following sample document, the Siebel Order ASI queries for all orders associated with the Hibbings Manufacturing account.<?xml version="1.0" encoding="UTF-16"?> <SiebelMessage IntObjectName="Order Interface"> <ListOfOrderInterface> <Orders> <Account>Hibbings Manufacturing</Account> </Orders> </ListOfOrderInterface> </SiebelMessage>
Sending and Receiving Custom JMS Properties
Properties can be assigned to a JMS message. A property can be an instance of any Java class or any of the primitive Java types. All properties of a message received by the Siebel JMS Transport are available as properties of the output property set. The Siebel EAI infrastructure can send and receive custom JMS properties without having to write custom code.
The name of a custom property is the original name with the eleven characters SIEBEL_JMS: prefixed; the value is the string obtained by converting the original value to a Java String object. When sending a message, any property of the input property set whose name begins with SIEBEL_JMS: is added to the message being sent as a JMS Message string property with the prefix SIEBEL_JMS: removed. For example, the property SIEBEL_JMS:foo is added to the message as the string property foo.
Receiving Custom Properties in Inbound Messages
Inbound messages are received through the JMS Receiver component (ReceiveDispatchSend or ReceiveDispatch method). This component is usually configured to dispatch the message to a workflow process.
To receive a custom JMS property in a workflow process
Create a workflow process property as follows:
Name Data Type In/Out SIEBEL_JMS:name
String
In/Out
Note: There is no space between the colon and the custom property name.Repeat the previous step for every custom JMS property that is expected to be received and processed.
At run time, the Siebel EAI infrastructure automatically copies the value of the correct JMS property from the received message to the appropriate Workflow process property.
For example, to have two JMS properties called TLFXUserId and TLFXGroupId available to a workflow process, you must define two process properties called SIEBEL_JMS:TLFXUserId and SIEBEL_JMS:TLFXGroupId.
The workflow process can also set the values of the JMS properties using a step that calls the Workflow Utilities business service (Echo method) as shown in the following example:
Input Argument Type Value SOV_Group
Expression
“SOV_Group”
SOV_User
Expression
“SOV_User”
Property Name Type Output Argument SIEBEL_JMS:TLFXGroupId
Output Argument
SOV_Group
SIEBEL_JMS:TLFXUserId
Output Argument
SOV_User
An input argument (SOV_Group and SOV_User in the example) can be any string, with the requirement that the same string must be used as the output argument.
Because the process properties are defined as In/Out, they are passed back to the caller (the JMS Receiver in this case). The JMS Transport includes them in the output message as JMS properties.
For more information about creating workflow processes, see Siebel Business Process Framework: Workflow Guide.
Sending Custom Properties in Outbound Messages
In the standard application, outbound messages are sent to the JMS queue using the EAI JMS Transport business service (Send and SendReceive methods).
The standard BS though does not have the ability to set custom JMS properties, but it is extremely easy to create a new clone of the EAI JMS Transport BS to handle those.
To set custom JMS properties in outbound messages
In Siebel Tools, create and open a workspace.
Copy the EAI JMS Transport business service, then give the copy a new name and display name, such as My EAI JMS Clone.
In the new business service, add business service method arguments to the Send method as follows:
Name Data Type Type SIEBEL_JMS:name
String
Input
Repeat the previous step for the SendReceive method, but enter Input / Output for the Type property.
Using Input / Output as the Type is necessary if the external system modifies the JMS properties and the new values are read into the Siebel application.
Deliver the workspace.
The new business service can be used in any workflow process. You can pick the custom JMS properties as input argument names when defining workflow steps, and the custom JMS properties are added to the JMS message. For more information about creating workflow processes, see Siebel Business Process Framework: Workflow Guide. For more information about business services, see Integration Platform Technologies: Siebel Enterprise Application Integration.
Enabling Authentication and Authorization for the EAI JMS Transport
Authentication and authorization can be configured on JMS servers to protect JMS destinations. Oracle supports the following scenarios for use in the Siebel application:
Require username and password to perform a JNDI lookup.
Require username and password to create connections to the JMS server.
Require username and password to send, receive, publish, subscribe from, or subscribe to JMS destinations that have the authorization enforced by a JMS server.
The responsibility of the Siebel EAI JMS Transport business service as a JMS client is twofold:
Provides configuration mechanism and read credentials from the Siebel application configuration file.
Establishes proper security context for executing privileged operations.
The following authentication and authorization topics are also discussed:
About JMS Credential Specification
The following method arguments are added to the EAI JMS Transport business service methods to use when completing the JMS credential specification:
ConnectionUsername and ConnectionPassword. The credentials used to create JMS connections (applicable for use with IBM WebSphere MQ only, see Configuring Against IBM WebSphere MQ).
SendUsername and SendPassword. The credentials used to send messages to SendQueue (applicable for use with Oracle WebLogic only, see Configuring Against Oracle WebLogic Server).
ReceiveUsername and ReceivePassword. The credentials used to receive messages from ReceiveQueue (applicable for use with Oracle WebLogic only, see Configuring Against Oracle WebLogic Server).
TopicUsername and TopicPassword. The credentials used to publish/subscribe to/from Topic (applicable for use with Oracle WebLogic only, see Configuring Against Oracle WebLogic Server).
Send and receive credentials are specified separately because some JMS business service methods (SendReceive and ReceiveDispatchSend) contain both send and receive operations, and it is possible that SendQueue and ReceiveQueue are protected by different credentials.
Configuring Credentials in JNDI
JNDI credentials are specified in the jndi.properties file by setting java.naming.security.principal to the username and java.naming.security.credentials to the password. For more details, refer to the JNDI specification. The construction of the naming context automatically reads the credentials from the jndi.properties file and uses those credentials to connect to a JNDI server if authentication is required to perform JNDI lookup.
For security reasons, Siebel CRM requires that the value of java.naming.security.credentials (representing the JNDI password) in the jndi.properties file be encrypted. The JNDIEncryptionCheck parameter in the JMSSubsys named subsystem is set to TRUE by default to enforce the encryption requirement. In this case, Siebel CRM decrypts the encrypted value of java.naming.security.credentials.
Customers encrypt the value of java.naming.security.credentials in the jndi.properties file by using the following encryption utilities:
EncryptJndi.sh, found in the
<SIEBEL_ROOT>/ses/siebsrvr/binfolder on UNIXEncryptJndi.bat, found in the
<SIEBEL_ROOT>\ses\siebsrvr\binfolder on Windows
Configuring Credentials in JMS
JMS-related credentials (those listed in the JMS credential specification) are passed in through a Siebel application-defined configuration mechanism. For configuring JMS-related credentials, see Configuring the EAI JMS Transport.
JMS Password Encryption
When passwords are provided through service input properties (ConnectionPassword, SendPassword, ReceivePassword, or TopicPassword), they are encrypted manually using the Siebel encryptstring utility. The EAI JMS Transport business service attempts to decrypt the password before using it. Passwords supplied using the name server have already been encrypted by the server manager; therefore, it is not necessary to encrypt it again with encryptstring.
BIN directory of your installation of the Siebel Server. For more information, see
Siebel Security Guide.
Configuring Against Oracle WebLogic Server
The following instructions let you configure the EAI JMS Transport business service against Oracle WebLogic Server.
To configure the EAI JMS Transport business service against Oracle WebLogic Server
Authorize a user to send from SendQueue using SendUsername and SendPassword.
Authorize a user to receive from ReceiveQueue using ReceiveUsername and ReceivePassword.
Authorize a user to publish and subscribe to and from Topic using TopicUsername and TopicPassword.
By default, the Oracle WebLogic server does not require a username or password to connect to or lookup JNDI objects. If the server does require this, then configure the EAI JMS Transport business service following Step 4 and Step 5.
ConnectionUsername and ConnectionPassword are set to a user who can connect to the JMS server, but the user has no privileges for any JMS destinations.
ConnectionUsername and ConnectionPassword can also be left blank if the JMS server accepts anonymous connections.
If JNDI lookup is protected, then the jndi.properties file contains the java.naming.security.principal and the java.naming.security.credentials parameters that are used to perform the JNDI lookup.
Note: The JNDI principal and credentials are set to a user who can only perform the JNDI lookup, but has no privileges for any JMS destinations.
Configuring Against TIBCO Enterprise Message Service
For the TIBCO Enterprise Message Service (EMS) client, no separate security context is needed for each operation. Once a connection is established, with the proper credential, all requests sent through the same connection use the same connection security context. This means that switching the security context requires switching connections.
For the ReceiveDispatchSend method, the implication is that the receive credentials must be the same as the send credentials. Receive and send must be executed on the same session or connection to remain a single transaction.
To configure the EAI JMS Transport business service against TIBCO EMS
ConnectionUsername and ConnectionPassword are set to proper credentials for executing the JMS operations specified by the JMS business service method.
For example, in the Send method, both ConnectionUsername and ConnectionPassword are set to the credentials that are authorized to send messages to SendQueue.
In the ReceiveDispatchSend method, ConnectionUsername and ConnectionPassword are set to the credentials that can both send to SendQueue and receive from ReceiveQueue.
Set the following input properties to empty:
SendUsername
SendPassword
ReceiveUsername
ReceivePassword
TopicUsername
TopicPassword
The jndi.properties file contains the java.naming.security.principal and java.naming.security.credentials properties that are used to connect to the EMS server and to lookup JNDI objects.
However, the connection to the EMS server, and the ability to lookup JNDI objects, does not occur if anonymous access is enabled by TIBCO EMS. For more information, see the TIBCO EMS documentation.
Note: These JNDI credentials are set separately from ConnectionUsername and ConnectionPassword.
Configuring Against IBM WebSphere MQ
For the IBM WebSphere MQ client, no separate security context is needed for each operation. Once a connection is established, all requests sent through the same connection use the same connection context.
For the ReceiveDispatchSend method, the implication is that the receive credentials must be the same as the send credentials. Receive and send must be executed on the same session or connection to remain a single transaction.
To configure the EAI JMS Transport business service against IBM WebSphere MQ
Set the ConnectionUsername and ConnectionPassword to the proper credentials to execute the JMS operations specified by the JMS business service method. For example, in the Send method, both ConnectionUsername and ConnectionPassword must be set to the credentials that are authorized to send messages to SendQueue.
Note: ConnectionUsername and ConnectionPassword are required for the Windows 2012 Server platform and recommended for all other Windows platforms.In the ReceiveDispatchSend method, set the ConnectionUsername and ConnectionPassword to the credentials that can both send to SendQueue and receive from ReceiveQueue.
Make sure the jndi.properties file contains the java.naming.security.principal and java.naming.security.credentials properties that are used to connect to the EMS server and to look up JNDI objects.
Note: These JNDI credentials are set separately from ConnectionUsername and ConnectionPassword.
For more information about configuring the EAI JMS Transport business service against IBM WebSphere MQ, see 828113.1 (Article ID) on My Oracle Support.
About Security Configuration on the JMS Server
For information about how to protect JMS resources on the JMS server, see the specific vendor documentation.
Troubleshooting for the JMS Transport
Several diagnostic methods are present in the EAI JMS Transport to assist in troubleshooting CLASSPATH, JNDI, and problems connecting to the JMS server:
CheckClasspath. Iterates through the JVM’s classpath, checking for the existence of each directory in the file system.
Note: The length of the classpath is limited to 1024 characters. However, it might be truncated when displayed in the user interface and srvrmgr command-line interface. To see the entire classpath, examine the log file. For information about logging, see About Logging for the JMS Transport.CheckJNDIContext. Creates a JNDI InitialContext based on parameters (context factory class, URL) in the jndi.properties file.
Lists the parameters and the entries found in the context, as well as the names and classes of the administered objects.
CheckJNDIObjects. Retrieves administered objects (connection factory, queue, topic) from JNDI.
If CheckJNDIObjects finishes without errors, then JNDI binding is proper.
If CheckJNDIObjects finishes with errors, then it means that the JNDI binding has not been done properly. Rebind the JNDI objects or check the jndi.properties file to see if the provider URL is pointing to the correct location.
CheckJMSServer. Invokes JMS methods directly and simply. If SendQueue is specified, then CheckJMSServer sends a message and then receives a message. If SendQueue is not specified and Topic is specified, then it creates a durable subscriber, publishes a message, receives it, and then unsubscribes.
If CheckJMSServer finishes without errors, then both the queuing system and JMS are communicating properly.
If CheckJMSServer finishes with errors, then it means that the JMS queue in the queuing system is not functioning properly. Check the corresponding queue in the queuing system.
CheckAll. Executes all checks: CheckClasspath, CheckJNDIContext, CheckJNDIObjects, CheckJMSServer.
The following table contains more details on arguments used with some of the JMS Transport debugging methods. The arguments listed are used by all three methods.
| Method | Argument | Display Name | Type | Description |
|---|---|---|---|---|
CheckJNDIObjects CheckJMSServer CheckAll |
ConnectionFactory |
Connection Factory |
Input |
JNDI name for the JMSConnectionFactory |
SendQueue |
Send Queue |
Input |
JNDI name for the queue (optional) |
|
Topic |
Topic |
Input |
JNDI name of the topic (optional) |
About Logging for the JMS Transport
The JMS Transport logs messages to a file if the Java system property jms.log is set. This property is specified among the VMOPTIONS in the JVM subsystem using the -Djms.log option.
The -Djms.log option must specify the path and file name but not the extension, because the JMS Transport automatically adds the .txt extension plus some information about the PID and thread ID.
For example, by using:
VMOPTIONS="-Djms.log=C:\temp\mylog"
The log file generated is:
C:\temp\mylog_xxx_yyy.txt
For more information about JMS logging, refer to the JMS vendor’s documentation.
About Caching for the JMS Transport
JMS Receiver connections are cached in Siebel Business Applications. In Siebel CRM version 8.1 and later, JNDI objects are also cached for performance and reliability. Caching eliminates the JNDI service as a point of failure.
JNDI object caching is active by default. To turn off caching (that is, to force JNDI lookup every time), use the DisableJNDIObjectCache business service method argument for any EAI JMS Transport business service method (operation). When DisableJNDIObjectCache is set to true, JNDI objects are not cached.