Property | Description |
|---|---|
Default JMS Provider | Indicates whether the selected JMS provider must be used as the default JMS provider. When you create multiple JMS Messaging Services, you can designate one JMS provider as the default for all the services. |
JMS Provider Type | The JMS provider type that is to be used for the JMS Messaging Service. You can select one of the following JMS providers:
When you select a JMS provider type, a list of initial context properties that contain pre-defined default settings for the selected JMS provider appears. You can update the values that appear in the Initial Context Properties section. You can specify any provider that provides JNDI access to JMS resources. If the provider that you want to use is not available in the list, you can select Other JMS to populate the configuration with commonly used, generic JNDI properties. If you select the IBM WebSphere provider type, you will not be able to configure the queue listener and topic listener properties and the following message appears: Configuration of Queue and Topic listeners is not available with the Websphere JMS provider. Websphere JMS explicitly forbids creating asynchronous consumers outside of a message-driven bean deployment when running on a Websphere server. |
Connection Factory Name | The JNDI name of the JMS connection factory. |
Connection User | Indicates whether to include user credentials while creating connections on the connection factory. If the provider is hosted by an application server, you do not need to configure the connection user because authentication takes place when you access objects through the JNDI context. IBM MQ Series is a provider that requires connection credentials. |
Connection Password | Password for the connection user. |
Send Empty Credentials | This option is applicable for IBM MQ Series when you connect to a remote queue manager and do not enable authentication. You must send empty strings ("") in the connection for the user name and password. Otherwise, the connection fails 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. This option sets the maximum number of active connections allowed at any time. This includes connections used for asynchronous listeners configured under Queues and Listeners, Topics and Listeners, and those used for invoke activities. If the maximum number 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. Configure one of the following values:
Default is -1. |
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 value of the Maximum Free Connections field is lower than the value of the Maximum Total Connections field. Default is 15. |
Delivery Mode | This option 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 option. Enable this option 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. Default is Persistent. |
Time To Live (ms) | Specifies the amount of time an unconsumed message remains on a queue. If a message will become obsolete after a certain period, you might want to set an expiration time. The expiration of obsolete messages conserves storage and computing resources. Default is 0 milliseconds, which means that the default for the provider is used. This means that messages never expire and remain on the queue forever. |
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 option. JMS defines a 10-level priority value with 0 as the lowest and 9 as the highest. Clients must consider 0-4 as gradients of normal priority and 5-9 as gradients of expedited priority. Priority is set to 4, by default. |
Maximum Reconnect Attempts | Specifies the maximum number of reconnection attempts that the JMS Manager must make when it tries to connect to the JMS provider. Enter -1 for unlimited reconnection attempts. Default is 20. When you stop the JMS Manager, the reconnection attempt is also stopped. |
Reconnect Interval (ms) | Specifies the number of milliseconds to wait between each connection retry attempt. For example, to retry to connect up to 10 times with a 10000 millisecond delay between retries, set the Maximum Reconnect Attempts field to 10 and the Reconnect Interval (ms) field to 10000. Default is 30000 milliseconds. |
Property | Description |
|---|---|
JNDI Location | Location name used for JNDI look-ups. |
Listener Class | Message listener class name. The listener class dispatches messages to Process Server. To deploy processes created with Process Developer, use the listener class name as com.activee.rt.mom.jms.transport.AeJmsBpelListener. If needed, you can create a custom listener class that extends the default listener class to include custom behavior. Specify the custom listener in this field. Default is com.activee.rt.mom.jms.transport.AeJmsBpelListener. |
Listener Count | 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. Default is 15. |
Selector | JMS message selector string. |
Default Service | 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 following JMS message property in the incoming message: JmsTargetService = "myRoleServiceName" 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 | 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.xml. 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 | If enabled for a supported platform, and if the required setup has been performed, indicates that a JMS read from the queue and the process engine must participate in the same transaction. |
Rollback On Error | Select the Rollback On Error option 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 this option, you must configure how the message server must handle failed messages. For example, you can configure the message server to redeliver failed messages for a specified number of times. Or, you can configure the server to move failed messages to a dead letter queue and take action later. 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. |
Option | Description |
|---|---|
To start a JMS Manager | Select Start from the Actions list, and then click Execute. |
To stop a JMS Manager | Select Stop from the Actions list, and then click Execute. |
To restart a JMS Manager | Select Restart from the Actions list, and then click Execute. |
To delete a JMS Manager | Select Delete from the Actions list, and then click Execute. |