Modify an FTP (embedded) pickup or delivery

After you create an FTP embedded server pickup or delivery, you can view and modify the fields that define the object.

This topic provides information for completing fields in the maintenance pages.

For related information, see the following topics:

FTP (embedded) settings tab (pickup)

  • Embedded FTP server – The name of the server. A link is provided to view the settings for the embedded server. You also can change servers.
  • View settings for this application – Click this link to open the Modify Application Pickup screen for this exchange. For a description of the fields you can view when you click this link, see FTP (embedded) transport configuration.
  • Host – The name used by Activator for the computer running the embedded server. You cannot change this field.
  • Host used by partners – This is the fully qualified domain name or IP address your partners use to send messages to this delivery exchange. When you export your community profile as a partner profile, the host information becomes part of your exported partner profile.
  • You can change this field by clicking View settings for this embedded server and changing the External host or IP address field. If your network uses a load balancer or firewall, contact your network administrator for the correct value. Any change to this field affects all delivery exchanges that reference the server.

FTP (embedded) settings tab (delivery)

  • Embedded FTP server – The name of the server. A link is provided to view the settings for the embedded server. You also can change servers.
  • Host – The name used by Activator for the computer running the embedded server. You cannot change this field.
  • Host used by partners – This is the fully qualified domain name or IP address your partners use to send messages to this delivery exchange. When you export your community profile as a partner profile, the host information becomes part of your exported partner profile.
  • You can change this field by clicking View settings for this embedded server and changing the External host or IP address field. If your network uses a load balancer or firewall, contact your network administrator for the correct value. Any change to this field affects all delivery exchanges that reference the server.

Directories tab (pickup and delivery)

  • FTP user – The name of the user.
  • Directory path – The FTP directory associated with the user. A specific combination of user and directory can be associated with only one exchange.
  • Specify what to do when the back-end system uploads messages to subdirectories of the directories listed above (pickup only)– Select an option:
    • Allow – Enables the user to write files to any subdirectory under the root path.
    • Do not allow – Enables the writing of files to a subdirectory under the root path only when a message attribute is set up for each subdirectory level.

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.

Advanced tab (pickup)

  • Allow FTP clients to add, remove subdirectories – Enable subdirectory management on the client side.
  • 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 sends or consumes via the embedded FTP server.
  • 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 a back-end application 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.

Advanced tab (delivery)

  • Retries – (For partner trading delivery only.) The number of times Activator accepts retries to connect from the trading partner if the initial attempt to connect and download files fails.
  • 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.
  • Delete file after it is downloaded – Select this if you want the embedded server to delete files after they have been downloaded from it.
  • Allow FTP clients to add, remove subdirectories – Enable subdirectory management on the client side.
  • Back up the files that go through this transport – Indicates whether the system backs up copies of the messages it sends or consumes via the embedded FTP server.
  • 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. This field is available for both application and partner deliveries.
  • See Post-processing of consumed messages.

Related Links