Default JMS Provider
For the provider selected in JMS Provider Type, enable this provider as the default, if desired. You can select one provider as the default, if you are setting up multiple services.
JMS Provider Type
List of configuration templates that contain some pre-defined default settings for the type of JMS provider being used. Theoretically, any provider that provides JNDI access to JMS resources can be used. If the specific provider is not on the list, you can select
Other JMS
to populate the configuration with some commonly used, generic JNDI properties.
Connection Factory Name
The JNDI name of the JMS connection factory.
Connection User
Include user credentials when creating connections on the connection factory. With providers hosted by an application server, this is usually not required since authentication takes place when accessing objects through the JNDI context. MQ Series is one provider that requires connection credential.
Connection Password
Password for the above user.
Send Empty Credentials
For MQ Series, when connecting to a remote queue manager when authentication is not enabled. You need to send empty strings ("") as username/password on the connection or it will fail with a security exception.
Maximum Total Connections
Each JMS Manager maintains an internal pool of connections to enhance performance when interacting with a remote JMS provider.
Sets the maximum number of active connections allowed at any one time. This includes connections used for asynchronous listeners configured under Queues and Listeners and Topics and Listeners as well as those used for invoke activities. If the maximum is reached, clients must wait until a connection is returned to the pool.
Setting the maximum value to -1 indicates that the manager may create as many connections as needed, with no upper limit so clients never have to wait. Change this value from the default of -1 if more connections are being created than the JMS provider can handle.
This value should be set to one of the following:
-1 (unlimited)
A number higher than the total number of listeners for both queues and topics and plus some connections for invokes
Maximum Free Connections
Sets the number of unused connections the manager retains at any one time. If a connection is returned to the pool, and there are already the maximum free connections sitting idle, the connection is closed. This allows the total number of connections from the pool to shrink and grow as necessary. Setting the maximum free connections to 0 prevents the Process Server from holding onto connections. Each client receives a newly created connection.
Ensure that the free connections value is lower than the value for Maximum Total Connections.
Delivery Mode
This setting controls whether or not the JMS provider persists messages to storage for all processes. An individual process can have a different persistence setting, which overrides this setting.
Enable this setting to persist messages in the event of a JMS failure. When this mode is enabled, Process Server instructs the JMS provider to ensure that a message is not lost in transit in case of a JMS provider failure. It is logged to stable storage.
Note that persistent delivery requires that your JMS provider be configured with storage. Also, there is usually a performance hit with persisting messages.
The default is disabled, which means the messages are sent with non-persistent delivery mode. This mode does not require any knowledge of how a provider is configured for storage.
Time to Live (ms)
Specifies the amount of time for which an unconsumed message remains on a queue. If a message will become obsolete after a certain period, you might want to set the time to live period. The expiration of obsolete messages conserves storage and computing resources.
Default is 0, which means that the default for the provider is used. Typically, this means that messages never expire and remain on the queue forever.
If you configure the time to live period and invoke a process by using the REST endpoint. If the HTTP message is not consumed within the time to live period, the request fails. You see the HTTP error
503 Service Unavailable
with the following error message:
Message discarded having exceeded the defined TTL.
Priority (int)
Specifies a non-negative integer for a message handling priority. Default is 0, which means that the default for the provider is used. An individual process can specify a priority, which overrides this setting.
JMS defines a 10-level priority value with zero as the lowest and nine as the highest. Clients should consider 0-4 as gradients of normal priority and 5-9 as gradients of expedited priority. Priority is set to four, by default.
Initial Context Properties
The set of name-value pairs used to establish a connection to the server hosting the JMS resources for access via JNDI lookup.
As an example, by selecting "BEA Weblogic" as the provider type, a set of default initial context properties that are generally used by WebLogic clients is displayed. Update the values for the URL, username, and password to match your environment.
Queues and Listeners
To enable connectivity with external clients and services over JMS, configure connections to an external JMS server.
Queue Name
/
Topic Name
(
required
). Descriptive name for the configuration
JNDI Location
(
required
). Location name used for JNDI lookups
Listener Class
(
required
). Message listener class name. The listener class is responsible for dispatching messages to Process Server.
If you are deploying processes created with
Process Developer
, use the listener class name:
com.activee.rt.mom.jms.transport.AeJmsBpelListener
If you are deploying processes created with
Process Designer
, use the listener class name:
com.activevos.rt.socrates.web.mom.jms.AeRealTimeJmsListener
If needed, you can create a custom listener class that extends the default listener class to include custom behavior. Specify the custom listener here.
Listener Count
(
required
). Number of connections to keep open. When the server starts, the JMS manager creates instances of this class that serve as asynchronous consumers on the destination. Each asynchronous consumer has its own connection to the JMS server. The number of consumers and connections created is controlled by the listener count.
Selector
(
optional
). JMS message selector string.
Default Service
(
optional
). Specifies the name of the BPEL service to use when the target service cannot be determined from the addressing headers or message properties.
Note:
One alternative to specifying a service is to include the JMS message property
JmsTargetService = “myRoleServiceName”
in the incoming message. Another alternative is to include a service name as a query parameter in a wsa:To header in a myRole partner link (for example,
<destination JNDI name>?<servicename>)
. These scenarios are for receiving XML messages over JMS.
Run-As Identity
(optional). Specifies an identity for a JMS request. The identity is a role-based or group membership. If not specified, the request runs anonymously. Using this property is analogous to specifying an identity for a message-driven bean in
ejb-jar.xm
l. Use this option if you want the JMS listener to invoke processes that have been secured with the Allowed Roles restriction in the Process Deployment Descriptor (pdd). Another use case is using the aeRunAs header for Human Task (B4P) operations. This case allows you to specify a RunAs Identity with the abTrust security role.
Tenant Context
Applicable for a MultiTenant-licensed server.
XA Transaction
(optional). If enabled for a supported platform, and if required setup has been performed, indicates that a JMS read from the queue and the process engine should participate in the same transaction. For a discussion, see
Enabling XA Transaction Handling.
Rollback on Error
: Select
Rollback on Error
if you want to decline messages that encounter an exception, or failed messages, and move to the next message. For example, the exception could be because of an authentication failure.
If you select
Rollback on Error
, you must configure how the message server handles failed messages. For example, you can configure the message server to redeliver failed messages 10 times. Or, you can configure the server to move failed messages to a dead letter queue and decide what to do with them at a later point.
For example, add the following policy entry to configure Apache ActiveMQ server to move failed messages to a dead letter queue:
<policyEntry queue=">">
<deadLetterStrategy>
<individualDeadLetterStrategy queuePrefix="DLQ." useQueueForQueueMessages="true" processNonPersistent="true"/>
</deadLetterStrategy>
</policyEntry>
Here, if the original queue is
userIDs
, the dead letter queue that Apache ActiveMQ server creates is
DLQ.userIDs
.
The
Rollback on Error
option does not apply to messages that were delivered to target processes. A message is considered successfully processed if it invokes a target process, even if the process fails.
For new queues and listeners, the
Rollback on Error
option is selected by default.
Topics and Listeners
This section is where the listeners that receive messages on behalf of the Process Server are configured. At a minimum, a single listener bound to a JNDI location on the server is needed to dispatch incoming messages to the server.
If more destinations are required to service requests, new definitions can be added by selecting
Add Queue
or
Add Topic
.
