# Modify a file system pickup or delivery

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

## File system settings tab (pickup)

• 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 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 transfer; receiving messages from partners or sending messages to partners. For example, for outbound you could name the pickup directory \data\out; for inbound \data\in.

## File system 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 exchanges, receiving messages from partners or sending messages to partners. For example, for outbound you could name the pickup directory \data\out; for inbound \data\in.

## Filenames tab (delivery)

### Delivery file name definition

• Preserve original filenames – (default) Select this option if you want the original file names to be preserved when Activator delivers messages.
• Preserving original file names enables your back-end application to process binary messages based on their file names.
• Generate unique filenames – Select this option to have the system provide a unique file name (instead of using the original name).
• Automatically generate unique filenamesActivator appends to the file name a hex representation of a monotonically increasing file name counter that is maintained in the database. Names are 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.
• Example with the original file extension:
• dabeed45_4cb.edi
• Example without the original file extension:
• z47e4120_4ce
• Define custom filename constructionActivator generates a file name using a pattern that you specify. Enter the pattern in the Pattern field.
• For additional information about entering renaming patterns, see File renaming patterns.

### Duplicate file name handling

• Overwrite duplicate filenames – If Activator detects a duplicate file name, it overwrites the existing file, replacing it with the duplicate file.
• Sequentially number duplicate filenames – (default) When you select this option you must also select a name generation option:
• Automatically generate unique filenames – (default). If Activator detects a duplicate file name, it generates a sequentially-numbered file name. Activator appends a number to the new file in the format: filename_c4.
• Define custom filename constructionActivator generates a file name using a pattern that you specify. Enter the pattern in the Pattern field.
• For additional information about entering renaming patterns, see File renaming patterns.
• Append to existing files – Append the duplicate file content to the content of the original file.

• Maximum concurrent connections – Default = 100. The maximum number of concurrent connections Activator can open to a partner or to a back-end application.
• For example, if the value is 100 connections and there are 150 messages to send, Activator opens only 100 connections. 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.
• The default value is suitable in most cases, however, if a partner or administrator reports that your Activator configuration is overrunning the receiving system, decrease the value.
• Retries – The number of times Activator retries 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 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 sends to the back end or to 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.
• Post-processing script – The full path to an executable file that contains post-processing commands.

• Maximum concurrent connections – The maximum number of concurrent connections Activator can accept from a trading partner or a back-end application.
• 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.
• If you are operating in a cluster environment, this is the total number across the entire cluster, no matter how many nodes are running.
• Enable file filtering – Select this option if you want to enable filtering on the files that are consumed by this pickup. When you select this option you must then enter a filter pattern to apply to consumed file names, and indicate if the filter acts inclusively (only pick up files that have names that match the filter) or exclusively (ignore only files that have names that match the filter and pick up all others).
• 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.
• Maximum file per polling interval – The highest number of messages the system can retrieve each time it polls.
• Polling interval – The interval in seconds Activator waits before polling for messages to retrieve.

## Directories tab (pickup and delivery)

On this tab you configure a directory associated with an SFTP user account. The path begins from the home directory of the SFTP account. Activator places messages in these directories for the back-end system to download.

If the back-end system uses the same account to upload messages, you must con figure a separate directory for that purpose on a pickup exchange.

If no account exists, click Add to add an account and associated directory.