edi_pusher.pl handle some sending errors automatically
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Confirmed
|
Medium
|
Unassigned |
Bug Description
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/
2018-11-05 14:06:06 virt-egutil1 /openils/
2018-11-05 14:06:06 virt-egutil1 /openils/
I followed the procedures in LP#1218423 to resend the PO
https:/
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
tags: | added: acq edi |
Changed in evergreen: | |
status: | New → Confirmed |
summary: |
- edit_pusher.pl handle some sending errors automatically + edi_pusher.pl handle some sending errors automatically |
Changed in evergreen: | |
importance: | Undecided → Medium |
tags: |
added: acq-edi removed: edi |
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/RemoteAcc ount.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.