Jitterbit

Jitterbit Harmony can use Files.com folders as sources and targets for integration operations. Its FTP connector supports SFTP: a Read activity collects an input file, an operation transforms or submits its data to another application, and a Write activity publishes output. Files.com supplies the managed file endpoint around that application work.

This is useful when partners have different delivery methods but an existing Jitterbit project should process their files consistently. Partners receive their own Files.com accounts and folders. The Jitterbit connection receives access to the prepared input and the output it needs, independently of those partner accounts.

Connection and Agent

Create a dedicated Files.com machine account, enable SFTP, and assign the necessary folder permissions.

In Jitterbit Studio, create an FTP connection with the Files.com hostname, select SFTP under Security options, and use its default port 22. Configure the username and authentication for that Files.com account. The connector's name does not mean the connection must use FTP or FTPS.

Select the Jitterbit agent group that will execute the operation and allow its network to reach the Files.com hostname. A test from a person's workstation does not establish connectivity from that runtime. The Files.com SFTP settings explain network and account requirements.

For key authentication on a private agent, follow Jitterbit's SSH configuration. The private key and its configuration belong on the Jitterbit agent; register the matching public key on the Files.com user. Configure each agent that may run the operation. The account's SFTP root and home folders determine which paths the activities see.

Read and Write Activities

An FTP Read activity is an operation source; an FTP Write activity is a target. Configure their directories and filenames separately from the shared connection.

For example, Read can collect a supplier's prepared order file, a transformation maps it into the receiving application's structure, and a later Write publishes an acknowledgment. Keep the acknowledgment in an output folder that the input selection does not read. Give the supplier access to its response without exposing the integration's other input files.

Review Read's handling after processing before enabling the operation's schedule. Moving or deleting a source requires corresponding Files.com permissions. It also changes the source available to an archive or recovery step, so plan those steps as part of the operation rather than assuming the original remains accessible.

Write's Use FTP Rename option uploads with a temporary name and then renames the file. When using it, grant the required rename access and keep downstream consumers from selecting the temporary name. Jitterbit's Write activity documentation identifies agent requirements for this option. Create and verify the destination folders during setup rather than relying on automatic folder creation to establish the exchange structure.

Operation Results and Recovery

Test both an actual Read and Write, as applicable, after testing the connection. A login can succeed while a path, file selection, or permission still prevents the operation.

Check the operation log for the application step that determines success, then inspect the resulting file. Files.com SFTP Logs show the file operations. They cannot establish whether another application's records were accepted.

Jitterbit's Success/Error Folder options for private agents refer to locations on that agent, rather than folders on Files.com. If the recoverable copy must remain in Files.com, make that a deliberate file step with its own destination and permissions. Before retrying a failed operation, check completed application actions and the surviving input so the recovery does not repeat successful work.