Modify an MQSeries pickup or delivery

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

IBM MQSeries settings tab (pickup and delivery)

  • MQSeries connection type:
    • Client connection – select this option to use a channel connection, on the local machine or via the network, to connect to a queue manager.
    • Server binding – Select this option to use an API connection, via shared memory, to a local queue manager.
  • MQSeries server – The fully qualified domain name or IP address of the MQSeries host.
  • Multi-instance queue manager – In the case where you have a multi-instance MQSeries queue manager, you can select this option, and then select the MQSeries manager instance to use as the standby server. See WebSphere MQ multiple instances .
  • Port – The port where the application listens for incoming documents. The default is 1414.
  • Channel – The name of the communications channel.
  • Queue name – The name of the MQSeries queue that receives incoming documents.
  • Queue manager – The name of the MQSeries queue manager.
  • Character set – The character set used by the queue manager. This number should match the number used by the queue manager. The default is 819.
  • Convert data – Select this option to convert the characters set of messages received from a queue to the set specified in the Characters set field. Clear the check box to turn off data conversion. This setting does not apply to messages outbound to a queue.
  • Characters set (delivery only) – The character set used by the queue manager. This number should match the number used by the queue manager. The default is 819.
  • Message segmentation – Select this option to enable message segmentation on this transport. Then complete the related sub-fields:
  • Use application segmentation when queue manager segmentation does not suffice because messages are too large to be handled by the application in a single buffer. Or, when data conversion must be performed by sender channels and the format is such that the putting application must specify the segment boundaries to make possible the conversion of individual segments.
    • MQSeries segmentation – Select this option to segment messages into chunks that together equal the maximum message length value of the queue as set by the queue administrator.
    • Application segmentation – Select this option to segment messages into chunks equal to the value you specify in the Segmentation size field. Each segment must be equal to or less than the maximum message length value of the queue
  • Use application segmentation if:
    • Messages are too large to be handled by the application in a single buffer,
    • Data conversion must be performed by sender channels and the format is such that the putting application must specify the segment boundaries to make possible the conversion of individual segments.
  • This server requires a user name and password – If selected, enter a user name and password to connect to the server.
  • Use SSL to connect to the IBM MQSeries server – If this option is not selected, you can select this option and then select a cipher suite from the list of available suites. If this option is already selected (because it was selected when the exchange was added), you cannot deselect it. If you want to deactivate SSL on this exchange you must delete the exchange and then create a new exchange without the SSL option.
  • Note: If you select this option you must add a trusted certificate for access to the IBM MQSeries server after completing the configuration of this delivery exchange. For information about required certificates, see SSL certificates for MQSeries transports.
  • When you select this option you must also complete the Select the SSL cipher suite field. From the drop down list, select the SSL cipher suite to use for the connection. The value must match the cipher suite that is configured for the channel on the MQSeries server. The following cipher suites are displayed, however not all of these suites are currently supported. For a list of currently supported cipher suites for MQSeries SSL connections, see the related Activator "Known Limitations" entry.
  • Activator JSSE cipher suite Cipher specification (MQSeries name)
    SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA DES_SHA_EXPORT1024
    SSL_RSA_EXPORT1024_WITH_RC4_56_SHA RC4_56_SHA_EXPORT1024
    SSL_RSA_EXPORT_WITH_RC4_40_MD5 RC4_MD5_EXPORT
    SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 RC2_MD5_EXPORT
    SSL_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA
    SSL_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA
    SSL_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA
    SSL_RSA_WITH_DES_CBC_SHA DES_SHA_EXPORT
    SSL_RSA_WITH_NULL_MD5 NULL_MD5
    SSL_RSA_WITH_NULL_SHA NULL_SHA
    SSL_RSA_WITH_RC4_128_MD5 RC4_MD5_US
    SSL_RSA_WITH_RC4_128_SHA RC4_SHA_US
  • Message persistence – Applicable only for outbound messages. Select a message persistence mode:
    • Non-persisted – No persistence. Messages may be lost.
    • Persisted – Messages survive failures or restarts. This overrides the persistence configured for the queue.
    • As defined by the queue – Messages are persisted according to the queue configuration.

Advanced tab (pickup)

  • Maximum concurrent connections – Default = 10. The maximum number of concurrent connections Activator can open to the MQ Series server to download messages.
  • For example, if the value is 10 connections and there are 15 messages to consume, Activator opens only 10 connections to the server. The remaining 5 messages are queued on the server 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.
  • Sequence consumed messages based on their delivery exchange – Select this option if you want messages that are consumed by this pickup to be delivered in their original consumption order per resolved destination delivery. When Activator consumes messages on this pickup that are delivered over multiple delivery exchanges, the messages are filtered and ordered in their consumed sequence for each delivery, and processed in parallel per delivery. For details about this functionality, see Sequential message delivery.
    • Timeout to apply for out of sequence messages (seconds) – Default = 60 seconds. Enter a time limit for Activator to wait for missing messages of a sequence before taking the appropriate action. This feature avoids the blocking of processing when a sequenced message is not available.
  • Back up the files that go through this transport – Indicates whether the system backs up copies of the messages it consumes from MQ Series. 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_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.
  • Post-processing script – The full path to an executable file that contains post-processing commands. This field applies to both application and partner deliveries.
  • See Post-processing of consumed messages.
  • 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 trading engine node is configured.

Advanced tab (delivery)

  • Maximum concurrent connections – Default = 100. The maximum number of connections Activator can open to an MQ Series server to upload messages.
  • For example, if the value is 100 connections and there are 150 messages to upload, Activator opens only 100 connections to the 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 will retry connecting to the MQ Series server 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’ 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 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.
  • 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.
  • Back up the files that go through this transport – Indicates whether the system backs up copies of the messages it uploads.. 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 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_directory_>\data\backup, unless you specify otherwise.
  • Post-processing script – The full path to an executable file that contains post-processing commands. This field is available for both application and trading deliveries.
  • See Post-processing of consumed messages.

Related Links