Modify a pluggable server pickup or delivery

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

Pluggable server settings tab (pickup)

• Server name – This field displays the name of the pluggable server.
• Server class – This field displays the server class of the pluggable server.
• Add custom settings for this pluggable server – Enter name/value pairs as custom parameters.

Pluggable server settings tab (delivery)

• Directory name – Use the Browse button or type the full path for a unique directory where Activator picks up or routes messages, depending on whether the transport is used for sending or receiving. If the directory does not exist, Activator creates it for you. Use a unique directory name. When adding a file system transport, the delivery exchange wizard suggests a name. You may want to give the directory a name that indicates whether the transport is being used for inbound or outbound integration, receiving messages from partners or sending messages to partners. For example, for outbound messages from a back-end application you could name the pickup directory \data\out; for inbound messages to the back end, \data\in.
• Preserve original filenames – Select this if you want original file names to be preserved when Activator delivers messages. For binary messages, we recommend that you preserve original file names. Otherwise, Activator assigns a unique file name that does not readily identify the contents of the file. Preserving original file names also allows your back-end application to process binary messages based on their file names. This field applies to application delivery exchanges and partner delivery exchanges only.
• Overwrite duplicate filenames – An option when you choose to preserve original file names. If duplicate file names are detected, Activator overwrites the existing file.
• Sequentially number duplicate filenames – An option when you choose to preserve original file names. If duplicate file names are detected, the trading engine appends a number to the new file. For most transports, the appended number is consecutively numbered. For FTP and SFTP, however, the appended number is hexadecimal and looks like this: filename_c4.
• Generate unique filenames – Select this option to have the system provide a unique file name instead of using the original name. This field applies to application delivery exchanges and partner delivery exchanges only. When selected, files are given arbitrary names. The names always have less than 30 characters and often have less than 20 characters.
• Appended to the file name is a hex representation of a monotonically increasing file name counter that is maintained in the database and guaranteed to be unique across all nodes in a cluster. In addition, if the original file name had an extension, the same extension is appended to the unique name the system generates.
• The following are examples of unique file names generated by the system, one with the original file extension and one without:
• dabeed45_4cb.edi
• z47e4120_4ce

• Maximum concurrent connections – The number of total open connections Activator can make to a partner. If you are operating in a cluster environment, this is the total number across the entire cluster, no matter how many JVM nodes are running. For example, if the value is 100 connections and there are 150 messages to consume, Activator opens only 100 connections to that partner. The remaining 50 messages are queued until connections become available.
• Back up the files that go through this transport – Indicates whether the system backs up copies of the messages it consumes from back-end applications or from partners.
• Backing up files is strongly recommended. 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 also are needed if you want the ability 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.
• Post-processing script – The full path to an executable file that contains post-processing commands.
• 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 – Default = 1. 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 effects load balancing. Depending on your message volume and the load on each node, this value can be modified to control the overhead associated with reconnecting to the transport server.
• This setting is applicable in clustered environments when more than one trading engine node is configured.

• Backup files are stored in <Activator_shared_directory>\data\backup, unless you specify otherwise.