Table of Contents
EDI with SFTP
Evergreen supports sending and receiving EDI files via SFTP. As of April 15, 2024, SFTP is required for EDI file transmissions with Ingram.
Known Issues
Because of differences in supported Linux distributions, Evergreen's original EDI SFTP implementation did not always work. It was known to fail on Ubuntu 20.04, but work on Ubuntu 22.04, for instance. A bug was opened on Launchpad to come up with an implementation that works everywhere Evergreen is supported.
Soon after the patch was deployed and tested, it became apparent that an additional fix was required.
If you plan to use SFTP for EDI, ensure that the patches for the following bugs are applied on your Evergreen installation:
If you are unsure, contact your Evergreen administrator, host or support vendor.
Set up
To switch an account from FTP to SFTP, simply edit the host field of the EDI account so that the leading "ftp:" is changed to "sftp:". For Ingram, you do not need to do anything else, and should NOT change any other instances of "ftp" to "sftp."
A screenshot would be useful here.
Some Caveats
Testing and production use has turned up some weak spots in the SFTP implementation, keep these in mind during your set up.
Change All Similar Accounts at the Same Time
Evergreen does not currently delete downloaded files from the vendor's server upon retrieval. It detects duplicate files using he names of files already downloaded in the edi_message database table. Duplicate messages are checked for by matching accounts. Matching accounts are determined using the host, username, password, and in_dir fields of the edi_account entries. This means that when you have multiple accounts with a vendor using the same host, username, password, and in_dir, you MUST update them all to SFTP at the same time, or the duplicate detection will fail and old files could be downloaded and reprocessed by Evergreen. This may cause unwanted side effects adjusting line-items on closed purchase orders.
Bad Credentials/Accounts Cause a Hang
Experience has shown that some accounts are no longer used, but never deactivated. In some cases these account no longer exist on the vendor's side. These accounts will cause retrieval via SFTP to hang or go into a loop of trying to login over and over again. If you think the EDI fetcher is running too long, you should check for these accounts.
One way to check for these account is to manually login to each account using your favorite SFTP program. When you attempt to login with an account that no longer exists or has the wrong password, you will be prompted repeatedly to enter a new password. When you find such an account, you can prevent it from being checked again by setting the active field of the corresponding provider to false.
Another screenshot would be useful here.
Other Bad Accounts Cause a Crash
Some accounts may still exist and allow you to login but have other issues on the remote server that will cause the SFTP software on the Evergreen side to crash. A common example of this is an old account that was never removed but that has no "home" directory to place files in.
If the EDI fetcher crashes unexpectedly, you can check for these accounts in a similar manner to those with bad credentials. The difference is that once you get logged in, your SFTP tool should report a message about a nonexistent directory, and in the case of the command line SFTP used by Evergreen and Linux, the program will likely crash. The solution for these accounts is the same as for those with bad credentials: set the provider's active field to a false value.
Trouble Shooting
The best way to trouble shoot issues with the switch to SFTP is to get the full output from the EDI fetcher program. This can be done by your server administrator or hosting provider. If the scheduled jobs service (usually "cron") can send emails, then configure it to email someone and remove any redirects or other filters on the entry for the edi_fetcher.pl program.
If the fetcher hangs, as in the case of the bad credentials caveat above, then it may be necessary to remove it from the scheduled jobs, stop the running fetcher, and run it manually to see exactly which account causes the hang.