JMS 1.1 Acquire Connection and Session Service
The JMS 1.1 Acquire Connection and Session service opens a connection and session with a remote JMS server. This service is used as part of a business process with other services like JMS 1.1 Send Message, Receive Message, Request Reply, and Release Connection services.
The following table provides an overview of the service:
System Name | JMS1.1 Acquire Connection And Session service |
---|---|
Graphical Process Modeler (GPM) categories | All Services |
Description | The JMS 1.1 Acquire Connection and Session service opens a connection and session with a remote JMS Server. |
Business usage | The JMS 1.1 Acquire Connection and Session service opens a connection and session with a remote JMS Server. |
Usage example | Use this service in a business process to acquire a connection and session which will be used by the other JMS services. |
Preconfigured? | No |
Requires third-party files? | The JMS provider jar must be provided to the system,
using one of the following methods:
Before
you install/load the jar file, you need to know:
|
Platform availability | All supported platforms |
Related services | This service must be used as the first JMS 1.1
service in a business process to open the session. Related services
include:
|
Application requirements | None |
Initiates business processes? | No |
Invocation | This service is invoked as part of a business process. |
Business process context considerations | The service can either be configured from the UI or through the GPM. The
connection and session-related parameters are set in this service and are used to send, receive,
request/reply and release services. If the Acquire Connection parameters are set in the GPM, they take precedence over the UI parameters. |
Returned status values | None |
Restrictions | None |
Persistence level | Minimum |
Testing considerations | Enable JMS logging from the Admin Console by selecting Operations > System > Logs. |
Configuring the JMS 1.1 Acquire Connection and Session Service
You will need to create a configuration of the JMS 1.1 Acquire Connection and Session service in the Admin Console. You must specify field settings for the service. You can set parameters at the service configuration level in the Admin Console and at the business process level in the GPM. The GPM parameter values override any parameters set in the Admin Console.
Use the following field definitions to create a new configuration of the JMS 1.1 Acquire Connection and Session service.
UI Field Name | GPM Field Name | Description |
---|---|---|
Name | Unique name for the service configuration. Required. | |
Description | Description for the service configuration, for reference purposes. Required. | |
Select a Group | Select one of the options:
|
|
Config | Select the name of the service configuration from the list. | |
Connection Type | CONN_TYPE | Defines whether to use JNDI or not. Required. Valid
values are:
|
Pool Name | POOL_NAME | Name of the pool. Required. |
Context Factory | CONTEXT_FACTORY | Context Factory name as provided by the JMS Provider. Required. Only displayed if using JNDI. |
URL | BROKER_URL | URL needed to connect with the JMS provider. Required. Only displayed if using JNDI. |
Broker URL | BROKER_URL | URL needed to connect with the JMS provider. Required. Only displayed if using Non-JNDI. |
Producer/Consumer Destination | DESTINATION_NAME_INSTANCE | Destination name from where to send/ receive the
messages:
|
Destination Type | DESTINATION_TYPE_INSTANCE | Destination type. Required. Valid values are:
|
Connection Factory | CONN_FACTORY | Connection Factory name as provided by the JMS Provider. Required. |
Connection Factory User Name | JMS_FACTORY_USERNAME | User name for connection factory if the connection factory is secured. Required if connection factory is used. Only displayed if using JNDI. |
Connection Factory Password | JMS_FACTORY_PASSWORD | Password for connection factory if the connection factory is secured. Required if the connection factory being used is secured. Only displayed if using JNDI. |
Connection UserName | JMS_CONN_USERNAME | Identifies the Connection User Name. |
Connection Password | JMS_CONN_PASSWORD | Identifies the Connection Password. |
Client ID | CLIENT_ID | Identifies the Client ID. Required if using Durable Subscriber. |
Number of Connections | NO_OF_CONN | Number of connections to be kept in the pool. The pool is lazily initialized. Lazily initialized means that only when a new request comes to create a connection a fresh connection and its associated sessions get created. Required. Valid value is any valid integer. Default is 1. |
Number of Sessions | NO_OF_SESSIONS | Number of sessions to be kept in the pool. Required. Valid value is any valid integer. Default is 500. In JMS, sessions are responsible for achieving multi-threaded message delivery. Multi-threaded message delivery is the ability to send/receive messages in parallel at the same time. So ideally the number of sessions should be equal to the number of messages that you want to send/receive in parallel. (Basically running multiple send/receive business processes in parallel can ensure sending/receiving messages in parallel.) Having this number less than the number of messages that are required to be sent/received in parallel will cause some of the messages to wait while others (number equal to the number of sessions) are being sent/received. |
Time to Live (per connection in ms) | TIME_TO_LIVE | Amount of time the connection should be kept alive in milliseconds. Required. Valid value is any valid integer. Default is 300000 (milliseconds). If a connection remains idle (not used by either producer or consumer) for this amount of time, whenever a new call comes to create a new connection or use an existing connection from pool, the idle connection is closed and a fresh connection is created and added to the pool. The idle connection will not be closed automatically but only when a new call comes to create/fetch a new connection. |
Use SSL | SSL_SETTING_ssl_option | Whether to use SSL or not. Required. Valid values
are:
|
CAs Certificate | SSL_SETTING_ca_cert_ids | Select from list of available CA certificates checked in on the server. Required.
Only displayed if SSL_MUST was selected for Use SSL. If failover URL is used to connect to ActiveMQ,
then add ActiveMQ certificates to the B2B JDK's cacerts store. Below are the example commands:
and restart B2B node. |
Use Custom Class Loading | UseCustomClassLoading | Required.
|
Use Custom Class Loading (continued) | The only limitation is that in certain scenarios with custom class loading customers might have to change the JMS_EXCLUDES list. There is a standard list that has been provided in the documentation for well know vendors. You should review the JMS_EXCLUDES property for proper configuration. Permissions to the jar and directory need to be read for the user that the system is running as. | |
System Certificate | SSL_SETTING_keyCertID | Select from list of available system certificates checked in on the server. Optional. Only displayed if SSL_MUST was selected for Use SSL. |
Jar Location | jarLocation | Path and directory to the jars required for custom class loading. Required. This field is only displayed if True was selected for Use Custom Class Loading. In you want to change the jar location or use new jars, you need to release the old custom class loader using the JMS 1.1 Release Connection Session service and then the new class loader needs to be created. If need you more information, see the JMS 1.1 Release Connection Session service or the JMX documentation. |
JMS Provider | JmsProviderName | If you are using SSL, select the JMS Provider from
the list of providers. Valid values are:
|
JMS Provider Specific Properties | In Property Name field, type provider-specific parameters as key/value pairs. Supports up to 5 key/value pairs. For example, if the setting of Provider is sampleProp = testValue, then "Property Name" should be completed as sampleProp and "Property Value" should be testValue. This allows you to configure up to 5 properties. This setup is only available if connection type is JNDI. | |
PIN_TO _THREAD | Default is true. Do not change the value of this parameter. This parameter ensures that all the services in the work flow surrounded by service with PIN_TO_THREAD=true indicates the start of the boundary and service with PIN TO THREAD=false is end of that boundary and all services in this boundary will run on the same node and same thread. As a result, all the JMS 1.1 services that are bounded by JMS 1.1 Acquire Connection and Session service (where PIN_TO_THREAD is true) and JMS 1.1 Release Connection and Session service (where PIN_TO_THREAD is marked as false) will always run on the same node and same thread. |
Parameters Passed From Business Process to Service
- CONN_TYPE
- POOL_NAME
- CONTEXT_FACTORY
- BROKER_URL
- DESTINATION_NAME_INSTANCE
- DESTINATION_TYPE_INSTANCE
- CONN_FACTORY
- JMS_FACTORY_USERNAME
- JMS_FACTORY_PASSWORD
- JMS_CONN_USERNAME
- JMS_CONN_PASSWORD
- CLIENT_ID
- NO_OF_CONN
- TIME_TO_LIVE
- UseCustomClassLoading
- SSL_SETTING_ca_cert_ids
- SSL_SETTING_keyCertID
- jarLocation
- JmsProvider Name
Parameters That Must Be Added in BPML
If the Acquire Connection service is already configured you do need not add any parameters to the business process.
Example Business Processes
The following are two examples of using the JMS1.1 Acquire Connection And Session service.
Example 1
The following example overrides any parameters in the JMS 1.1 Acquire Connection And Session service. Any parameters set at the business process level will take precedence over those set in the UI.
<process name="jms11SendToQueueRegression">
<sequence>
<operation name="JMS11AcquireConnSessionService">
<participant name="JMS11AcquireConnectionAndSessionForQueue" />
<output message="JMS11AcquireConnSessionServiceInputMessage">
<assign to="." from="*"></assign>
<assign to="CONN_FACTORY">ConnectionFactoryName</assign>
<assign to="DESTINATION_NAME_INSTANCE">DestinationName
</assign>
<assign to="DESTINATION_TYPE_INSTANCE">QUEUE</assign>
<assign to="NO_OF_CONNS ">1</assign>
<assign to="NO_OF_SESSIONS">100</assign>
<assign to>
</output>
<input message="inmsg">
<assign to="." from="*"></assign>
</input>
</operation>
<operation name="JMS11SendMessageService">
<participant name="JMS11SendMsgRegression" />
<output message="JMS11SendMessageServiceInputMessage">
<assign to="." from="*"></assign>
<assign to="MSG_TYPE">TextMessage</assign>
</output>
<input message="inmsg">
<assign to="." from="*"></assign>
</input>
</operation>
<operation name="JMS11ReleaseConnSessionService">
<participant name="JMS11ReleaseConnectionAndSession" />
<output message="JMS11ReleaseConnSessionServiceInputMessage">
<assign to="." from="*"></assign>
</output>
<input message="inmsg">
<assign to="." from="*"></assign>
</input>
</operation>
</sequence>
</process>
Example 2
The following example uses everything from the service which was configured using the UI.
<process name="jms11SendToQueueRegression">
<sequence>
<operation name="JMS11AcquireConnSessionService">
<participant name="JMS11AcquireConnectionAndSessionForQueue" />
<output message="JMS11AcquireConnSessionServiceInputMessage">
<assign to="." from="*"></assign>
</output>
<input message="inmsg">
<assign to="." from="*"></assign>
</input>
</operation>
<operation name="JMS11SendMessageService">
<participant name="JMS11SendMsgRegression" />
<output message="JMS11SendMessageServiceInputMessage">
<assign to="." from="*"></assign>
<assign to="MSG_TYPE">TextMessage</assign>
</output>
<input message="inmsg">
<assign to="." from="*"></assign>
</input>
</operation>
<operation name="JMS11ReleaseConnSessionService">
<participant name="JMS11ReleaseConnectionAndSession" />
<output message="JMS11ReleaseConnSessionServiceInputMessage">
<assign to="." from="*"></assign>
</output>
<input message="inmsg">
<assign to="." from="*"></assign>
</input>
</operation>
</sequence>
</process>
Frequently Asked Questions
Why is my message failing?
If you are using custom class loading in the JMS 1.1, there is a chance that when receiving messages via the Sync Receive Service or the Async Receive Adapter, the replyTo header object in the JMS Message header might be of a class that is not present in the Sterling B2B Integrator dynamic class path.
- Add the jar to the Sterling B2B Integrator dynamic class path rather than using custom class loading.
- Provide a queue/topic name explicitly in the service.
What does the PIN_TO_THREAD parameter do and should I ever change it?
JMS 1.1 uses a parameter called PIN_TO_THREAD. This parameter ensures that all the services in the work flow surrounded by service with PIN_TO_THREAD=true indicates the start of the boundary and service with PIN_TO_THREAD=false is end of that boundary and all services in this boundary will run on the same node and same thread. As a result, all the JMS 1.1 services that are bounded by JMS 1.1 Acquire Connection and Session service (where PIN_TO_THREAD is true) and JMS 1.1 Release Connection and Session service (where PIN_TO_THREAD is marked as false) will always run on the same node and same thread.
The main reasons for this are around transactionality and utilization of the same session and connection object. So basically between PIN_TO_THREAD=true and PIN_TO_THREAD=false the services will be able to use the same session and connection object. Also, the JMS transactions are governed by session objects. The same session ensures that you can have multiple services using the same session and all of these can be rolled back or committed together.
You should not change this parameter.