edi_pusher.pl handle some sending errors automatically

[Josh Stompro]

Hello, we just ran into a situation where a network error or a remote site ftp error caused an edi order to fail.

2018-11-05 14:06:06 virt-egutil1 /openils/bin/edi_pusher.pl: [ERR :8734:RemoteAccount.pm:553:] OpenILS::Utils::RemoteAccount : new Net::FTP('ftp.baker-taylor.com, ...) FAILED: Net::FTP: connect: Connection timed out

2018-11-05 14:06:06 virt-egutil1 /openils/bin/edi_pusher.pl: [ERR :8734:RemoteAccount.pm:586:] OpenILS::Utils::RemoteAccount : put to ftp.baker-taylor.com failed with error: Can't call method "put" on an undefined value at /usr/local/share/perl/5.20.2/OpenILS/Utils/RemoteAccount.pm line 584.

2018-11-05 14:06:06 virt-egutil1 /openils/bin/edi_pusher.pl: [ERR :8734:EDI.pm:331:] (S)FTP put to EDI send to edi_account 1897 (ftp://ftp.baker-taylor.com) FAILED: put to ftp.baker-taylor.com failed with error: Can't call method "put" on an undefined value at /usr/local/share/perl/5.20.2/OpenILS/Utils/RemoteAccount.pm line 584.

I followed the procedures in LP#1218423 to resend the PO
https://bugs.launchpad.net/evergreen/+bug/1218423

I think it would be preferable to have the edi_message marked for retry in this situation, and try sending again for the next run. Maybe with a certain number of retries to avoid unnoticed errors from continuing forever?

Thanks
Josh

[Jason Stephenson (jstephenson)]

The entire process for handling EDI, both pushing and fetching, could benefit from more robust error handling. As it is, any errors with pushing are pretty much ignored and require manual intervention on the part of an administrator with access to the database and/or production servers. This could be avoided with some sensible code in the EDI processes.

Errors when fetching aren't so bad, since they will be retried the next time that the fetcher runs, but the fetcher should still not attempt to run commands if it fails to connect, or to login, to the remote server. Messages like "Can't call method "ls" on an undefined value at /usr/local/share/perl/5.22.1/OpenILS/Utils/RemoteAccount.pm line 648." should not show up in the log files as a routine thing.

It looks like the new edi_order_pusher.pl will suffer some of the same problems as the current pusher and fetcher because it uses the same infrastructure underneath for sending messages to the vendor: OpenILS::Utils::RemoteAccount. Presently, there's no way for connection errors to be caught by RemoteAccount's clients.

[Lynn Floyd (lfloyd)]

We are running into this also.