Trading configuration > Community trading pickups and partner deliveries > Fields for modifying community pickups and partner deliveries > Modify a JMS pickup or delivery

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 provider class. 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 trading pickups only)– The number of total open connections Activator server can make to a partner.
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 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 retrieves from integration or receives from partners. Backing up files. 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 stops or restarts. Backups are needed to resubmit messages to back-end applications or resend messages to partners. Backup files are stored in \<install directory>\common\data\backup, unless you specify otherwise.
Process consumed messages using community collaboration settings – Apply the community collaboration settings to the messages that are consumed by this pickup.
Perform content processing on consumed messages – Select this option if you want to apply specific processing to the messages that you consume through this pickup. If you select this option you can then select a service to supply the processing.
- Services – From the drop-down list, select the service to use for message processing.
Restrict maximum file size for this transport – Optionally lets you specify the maximum size of files a transport can handle.
If Activator receives a file larger than the maximum, the file is rejected and a message is written to the events log. If received via HTTP, a 413 response also is sent and the connection is closed. A 413 message is Request Entity Too Large. The maximum size must be expressed in bytes. Do not use commas. For instance, 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. This control is available only for transports used for picking up messages from integration or receiving messages from partners.

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.

Specify preferred nodes – If there are one or more nodes for Activator, you can select one or more as the preferred nodes for consuming messages. If the preferred nodes are running, these are used to process messages. If the preferred nodes are stopped, work is distributed among the remaining running available nodes. Selecting preferred nodes lets you manage work distribution among nodes. This option is available for integration pickup and trading delivery exchanges that poll for messages. In general, this setting should not be used. Usually it is best to let Activator automatically determine which node should be responsible for initiating the polling of which exchange point. This setting is useful if you have a cluster that spans geographical locations and each location has its own local transport servers. In this situation, you would use this setting to ensure the exchange points associated with the transport servers are assigned to nodes in the vicinity of the transport servers.

Advanced tab (delivery)

The following are all possible fields for polled and listener modes.

Retries – This is the number of times Activator will retry connecting to the partner’s transport if the initial attempt to connect and send 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 HTTP server took longer than the response timeout interval to return a 200 OK response indicating the message was successfully received. A 200 OK response is a transport response, separate from a message protocol response such as an AS2 receipt.
Note that in the last case, the 200 OK response also will include the receipt if synchronous receipts were requested. Otherwise, it will be a simple 200 OK response with no payload. And if an asynchronous receipt was requested, the partner will connect later to send it. 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 retrying to send related 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.
Message Type – Specifies the JMS message class. This field applies only to JMS when used for receiving messages from partners or integration delivery.
- 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 retrieves from integration or receives from partners. Backing up files. 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 stops or restarts. Backups are needed to resubmit messages to back-end applications or resend messages to partners. Backup files are stored in \<install directory>\common\data\backup, unless you specify otherwise.
Post Processing script – The full path to an executable file that contains post-processing commands. .