Modify a JMS pickup or delivery

After you create a JMS pickup or delivery, you can view and modify certain fields that define the object.

JMS settings tab (pickup and delivery)

  • JMS queue – The name of the queue. Example: XMLQueue@router1
  • This queue requires a user name and password – Select this if the queue requires a user name and password. When selected, fields appear for entering the information.
    • User name – A user name for the JNDI provider. This value could be blank and is typically provided for in the JNDI URL. However, this depends on the JNDI provider and how it is configured.
    • Password – A password for the JNDI provider. This value could be blank and is typically provided in the JNDI URL. However, this depends on the JNDI provider and how it is configured.
    • Confirm password – Type the password again for confirmation.
  • Use JNDI – Select this if a Java Naming and Directory Interface (JNDI) provider. When selected the applicable fields display.
  • JNDI URL – The network URL used to obtain access to the JNDI service provider for your JMS service. Example: smqp://localhost:4001/timeout=10000
  • JNDI factory – The name for the JNDI service Java provider class used to create the JMS session. Example: com.swiftmq.jndi.InitialContextFactoryImpl
  • This provider requires a user name and password – Select this if JMS requires a user name and password. When selected, fields appear for entering the information.
    • User name – A user name for the JMS provider. This can be the same as your JNDI user name. However, this depends on your JMS provider and how it is configured.
    • Password – A password for the JMS provider. This can be the same as your JNDI password. However, this depends on your JMS provider and how it is configured.
    • Confirm password – The password again for confirmation.
  • JMS connection factory – The connection factory as defined within the JMS provider. This value can be either in the form factoryname@routername or the JNDI public symbol for the QueueConnectionFactory. Examples: plainsocket@router1 or QueueConnectionFactory22. This depends on your JMS provider and how it is configured.
  • Use a custom Java implementation – Select this for a JMS provider that does not require a JNDI implementation. For example, Oracle Advanced Queuing facility (Oracle AQ). When selected the applicable fields display.
    • Class name – The name of the Java class for implementing the connection to the message queue. A Java class for Oracle AQ is available. The class name is:
      com.cyclonecommerce.tradingengine.transport.jms.OracleAQQueueUtil
    • If you want a Java class for a provider other than Oracle AQ, you need the help of a professional services consultant. Contact Axway technical support for information.
    • Parameters – There are four parameters required for the Java class for Oracle AQ. These parameters must be in the following order:
      • Host. The name of the computer running Oracle AQ.
      • Database name. The name of the database that contains the message queue.
      • Port. The port Oracle AQ uses to listen for messages. 
      • Driver type. The type of JDBC driver for connecting to the provider. For Oracle AQ, the valid values are thin and oci8
  • Send payload via file system(delivery only)– Select this check box to have payloads sent by a file system. You can specify the size of payloads to send and the path for payload files. The receiver uses the path to retrieve the files.

Advanced tab (pickup)

  • Maximum concurrent connections (for JMS polling trading pickups only) – Default = 10. The maximum number of concurrent connections Activator can open to the JMS server for downloading messages.
  • For example, if the value is 10 connections and there are 15 messages to consume, Activator opens only 10 connections to that partner. The remaining 5 messages are queued until connections become available.
  • If you are operating in a cluster environment, this is the total number across the entire cluster, no matter how many nodes are running.
  • Receive Time Out (seconds) – If your JMS provider is slow to respond to the receive request by Activator, increase the response interval. The default value of 0 is acceptable in the case of most JMS providers. However, if unacceptable for your JMS provider, use trial-and-error to determine a workable interval between 1 and 32767 seconds.
  • Use transacted queue – Select this option only if the provider is Oracle AQ. Otherwise, do not select it.
  • Back up the files that go through this transport – Indicates whether the system backs up copies of the messages it consumes from the back end or from partners. This is required for the system to perform fail-over operations such as attempting to send messages again (retries) in case of a transport connection failure. Without backups, a message in process cannot be recovered if Activator stops or restarts. Backups are needed to resubmit messages to back-end applications or resend messages to partners. Backup files are stored in <Activator_common_directory>\data\backup, unless you specify otherwise.
  • Restrict maximum file size for this transport – Use this option to specify the maximum size of files a transport can handle.
  • If the pickup consumes a file larger than the specified maximum, the file is rejected and a message is written to the events log.
  • Express the maximum size in bytes. Do not use commas. For example, a kilobyte is 1024 bytes, a megabyte is 1048576 bytes, a gigabyte is 1073741824 bytes. The smallest maximum allowed is 1000 bytes. On the opposite extreme, you can enter the largest number the field can accommodate.
  • Maximum files per polling interval – The highest number of messages the system can retrieve each time it polls.
  • Polling interval (seconds) – The interval in seconds Activator waits before polling for messages to retrieve.
  • Maximum messages per connection – This value specifies the maximum number of messages to be consumed over a single connection before the connection is closed and reopened on another processing node. This setting effectively controls load balancing. The default setting of 1 achieves optimal load balancing at the cost of greater overhead per message. Depending on your message volume and the load on each node, this value could be increased to avoid the overhead associated with reconnecting to the transport server, at the cost of a less well-balanced cluster.
  • This setting is applicable in clustered environments when more than one Activator node is configured.

Advanced tab (delivery)

  • Maximum concurrent connections – Default = 100. The maximum number of concurrent connections Activator can open to an external JMS server in order to upload messages.
  • For example, if the value is 100 connections and there are 150 messages to send, Activator opens only 100 connections to the external server. The remaining 50 messages are queued until connections become available.
  • If you are operating in a cluster environment, this is the total number across the entire cluster, no matter how many nodes are running.
  • Retries – This is the number of times Activator tries connecting to the partner’s transport if the initial attempt to connect and upload the message failed. The following are common reasons for triggering retries.
    • The connection attempt failed immediately for a reason such as host not found.
    • The host was found, but the connection process took longer than the connect timeout interval specified on the Advanced tab.
    • The connection was successful, but the partner’s server took longer than the response timeout interval to return a response indicating the message was successfully received.
    Retries occur according to an algorithm that starts at 5 minutes. The interval between retries increases with each subsequent retry in this pattern: 10 minutes, 15 minutes, 30 minutes, 60 minutes. The interval plateaus at 60 minutes. This means if the retry value is greater than 5, the fifth and each subsequent retry occurs at 60 minute intervals. For example, if retries is 3, the system will try connecting again in 5 minutes if the initial connection attempt fails. If this retry attempt also fails, the system attempts a second retry in 10 minutes. The third retry attempt is made 15 minutes later. If the third retry attempt fails, the message is given a failed status. So after four attempts (the first attempt plus 3 retries), the message fails. You can search for and manually resubmit failed messages in Message Tracker. Retries do not occur precisely at these intervals because each connection attempt takes some seconds, which varies by computer. So retries actually occur after the connection attempt time plus the interval. This control applies only to retrying to send messages, not receiving. It applies only to upload failures due to transport issues. It does not apply to successfully sent messages for which receipts have not been received as expected. Another control, resends, determines how many times the system will resend a message when a receipt is not received from the partner. For information about resends, see reliable messaging in the collaboration settings chapter.
  • Use custom retry intervals – Select this option to override the default retry intervals with intervals of your choice for this delivery exchange. Default intervals are 5, 10, 15, 30, and 60 minutes. When you select this option, you must enter at least one interval (in minutes) in the Custom retry intervals field. You can enter as many intervals as you like, separated by commas. Activator applies the intervals between successive retry attempts. If necessary, the last interval you list is repeated until either the delivery is successful or the number of permitted retries is reached.
  • Message Type – Specifies the JMS message class. This field applies only to JMS when used for consuming messages from partners or back-end applications.
    • BytesMessage. A BytesMessage object is used to send a message containing a stream of uninterrupted bytes. It inherits from the Message interface and adds a bytes message body.
    • TextMessage. A TextMessage object is used to send a message containing a java.lang.String. It inherits from the Message interface and adds a text message body.
  • Use transacted queue – Select this option if the provider is Oracle AQ. Otherwise, do not select it.
  • Back up the files that go through this transport – Indicates whether the system backs up copies of the messages it uploads to the JMS server. This is required for the system to perform fail-over operations such as attempting to send messages again (retries) in case of a transport connection failure. Without backups, a message in process cannot be recovered if the server or a processing node stops or restarts. Backups are needed to resubmit messages to back-end applications or resend messages to partners. Backup files are stored in <Activator_common\data\backup, unless you specify otherwise.
  • Post Processing script – The full path to an executable file that contains post-processing commands.
  • See Post-processing of consumed messages.

Related Links