Modify an SFTP (external) pickup

After you create an external SFTP pickup, you can view and modify the fields that define the object.

An external SFTP pickup resides outside of Activator.

SFTP settings tab

• SFTP server – The name of the SFTP server.
• Port – The port on which the server listens for incoming connections. The default is 22.
• Current public key – The RSA or DSA public key for the SFTP server. Activator uses the key to authenticate the server.
• New public key – Select this check box to display options for designating a new RSA or DSA public key for the SFTP server. Activator uses the key to authenticate the server. If the server is modified to use a new public-private key pair, the public key must be updated.
  • Retrieve public key from server – Click Get Key to have Activator retrieve the public key for the SFTP server. The server name and port number entered on this page must be correct for this option to work.
  • Server public key file – Type the path to the file containing the public key for the SFTP server or click Browse to locate the file. You may have to ask the server administrator for the file path. See Public-private key and password authentication.
• Use public/private key pair authentication – Public-private key pair authentication requires entering the user name of the server here.
• If this exchange is for a community, add the private key to the community. If this exchange is for a partner, add the public key to any community that will be trading with the partner.
• To add a key, click Certificates in the navigation graphic at the top of the community summary page. Select the SSH keys tab. Click Add an SSH key, follow the prompts and click Add. Select the key as the default SSH key after it has been added. For more information see Public-private key and password authentication.

• Use host-based authentication – This is not used.

Directories tab

• Pickup directory – Type the path of the directory on your server where messages are picked up. When Activator polls the server for files, it only looks in the pickup directory, not an inbox directory.
• Use temporary files to avoid read/write collisions – We recommend using this option to prevent Activator from attempting to retrieve partially written files. When this is selected, you must select one of the two following options.
  • Use separate directory for temporary files – Type the full path of an inbox directory (for example, c:\data\inbox). Files are uploaded to this directory. When fully written, files are moved to the pickup directory for retrieval.
  • Do not put the inbox under the pickup directory unless you use a period at the beginning of the inbox name. Activator and other applications ignore directories and files that begin with periods.
  • For example, do not use the following directory structure:
  • c:\data\pickup\inbox
  • But you can use the following because a period is the first character of the inbox directory name:
  • c:\data\pickup\.inbox
  • When receiving files from a partner, we recommend that your partner write files to the inbox directory first and then move them to the pickup directory when they are ready to be retrieved. This process is automatic if your partner also uses Axway products B2Bi, Interchange or Activator. If the partner uses other software to upload files to your server, the software should be configured to initially upload the files to the inbox directory and move them to the pickup directory when they are ready to be retrieved.
  • For outbound integration, the back-end system must write the message to the inbox and then move it to the pickup directory.
  • For inbound integration and sending outbound to partners, Activator writes to the inbox and then moves the message to the pickup directory.
  • Use special extension in pickup directory for temporary files – If you prefer not to use an inbox, select this option. While a file is being written to the pickup directory, a temporary extension is added so the system knows not to retrieve it because the file is only partially written. Once fully written, the temporary extension goes away and the file can be retrieved.

Filenames tab

• 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 community integration 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, Activator 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 to have the system provide a unique file name instead of using the original name. This field applies to community integration 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. 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

Advanced tab

• Maximum concurrent connections (for trading pickups only) – The number of total open connections Activator server can make to a partner.
• 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.
• Read timeout (seconds) – How long in seconds that Activator waits to read data from the delivery exchange before terminating the connection.
• Override SSH ciphers – Select this check box to specify, using the Add and Remove buttons, the specific ciphers supported for the server. If not selected, all ciphers are supported by default. The default is less secure than specifying only certain ciphers. This check box is available for production delivery exchanges.
• The default order in the Available column is the preferred order of use. Once ciphers are moved to the Selected column, you can arrange the order. Activator uses the ciphers in the order listed.
• Maximum block size per downloading packet – Sets the maximum size of the packets that can be downloaded from an external SFTP server by the SFTP client within Activator. The client downloads messages in a series of data packets. By default the maximum size is 32768 data packet units. The default value is compatible with most SFTP servers. But when handling messages of a certain size (2-3 megabytes or larger), some servers cannot process many packets of the default size and downloading hangs. If this occurs, reduce the packet size maximum. Adjusting the value is a trial-and-error process. You may have to test several values depending on the size of the messages being processed. For example, when messages are approximately 3 MB in size, the maximum packet size can be set at 4096. This field is available only on the pickup exchange for receiving messages from partners and integration pickup.

• Enable file filtering – Available for some exchanges used for application pickups and for receiving from partners, file filtering allows Activator to discriminate which files to consume based on file names. In the file name filter pattern field, type the formats of the files you want the transport to consume or ignore. Use conventional wildcard characters for file names or extensions or both. The following describes the supported characters and symbols:

• *	One or more characters.
  ?	Any single character.
  [ ]	Matches any single character within the brackets. For example, r[aou]t matches rat, rot and rut.
  ,	Commas can be used as and/or operators within brackets (for example, r[a,o,u]t).
  -	Use hyphens within brackets to specify ranges of letters or numbers. For example, [0-9] is for any number between 0 and 9, and [A-Za-z] is for any upper- or lower-case letter.
  .	Use the character dot to separate the file name and extension. For example, *.txt.
  |	Use the pipe character to separate multiple file-name formats. For example, *.edi|*.txt|[a,b,c]?.xml.

• Specify with the radio buttons whether the filter pattern is inclusive or exclusive. If inclusive, only files matching the pattern are consumed. If exclusive, files matching the pattern are ignored, but all other files are consumed.
• Activator ignores files that do not meet filtering conditions. Ignored files are not reported in Message Tracker. Such files also do not generate log messages unless the following property is set to debug in conf\log4j.properties:
• log4j.category.com.cyclonecommerce.tradingengine
• 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 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 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 \<install directory>\common\data\backup, unless you specify otherwise.
• 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.
• Post-processing script – The full path to an executable file that contains post-processing commands. This field is available for community integration delivery exchanges and partner trading delivery exchanges.
• 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.