| 2024-04-03 18:57:27 |
Jason Stephenson |
description |
Evergreen: main, 3.11.5, 3.12.3
A bug slipped through testing of STFP EDI fixes in bug 2040514.
When sending the ORDERS message (.EPO file), the wrong value gets recorded in the remote_file column of the acq.edi_message table. Instead of the remote file name, the return value of the SFTP put operation gets stored in the remote_file column. This is usually the value "1" when the put was successful.
The correct file is sent to the correct location on the remote server, and it appears to be processed correctly otherwise, including subsequent messages being picked up and processed.
This appears to be another case of the implementation of the Net::FTP functions not working quite right with Net::SFTP::Foreign.
C/W MARS, Inc. noticed this after trying the code in production. It also turns up in the database that was used for testing this feature, but was overlooked at the time, since the bug reporter focused his attention on if the file made it to the other server or not and didn't notice the database anomaly.
A patch will be forthcoming once it has been tested. |
Evergreen: main, 3.11.5, 3.12.3
A bug slipped through testing of SFTP EDI fixes in bug 2040514.
When sending the ORDERS message (.EPO file), the wrong value gets recorded in the remote_file column of the acq.edi_message table. Instead of the remote file name, the return value of the SFTP put operation gets stored in the remote_file column. This is usually the value "1" when the put was successful.
The correct file is sent to the correct location on the remote server, and it appears to be processed correctly otherwise, including subsequent messages being picked up and processed.
This appears to be another case of the implementation of the Net::FTP functions not working quite right with Net::SFTP::Foreign.
C/W MARS, Inc. noticed this after trying the code in production. It also turns up in the database that was used for testing this feature, but was overlooked at the time, since the bug reporter focused his attention on if the file made it to the other server or not and didn't notice the database anomaly.
A patch will be forthcoming once it has been tested. |
|
