Skip to main content

Hi all,

Requirement : Send an email with all the attachments added in a Purchase Order / Purchase Order Line.

The files are stored in FTP, therefore I cant use the edm_file_storate_tab to get the BLOB.

So, I tried to use  Batch_Transfer_Handler_Api.Download_From_Ftp method  to get the files, and attach to email.

And it worked for one particular document, but its failling with the below error for other documents, which are in same class, same ftp location, attached to same Purchase Order Line. Details/setup in the Document Revision screen for both are also same.

 

The failling documents are viewable on the application without any error.

Debug information also showing the same path/fileName as in edm_file_tab for these failling documents.

Could you please advise on any possible reasons to failing the ftp download? or please suggest another option to attach these docs in FTP to an email.

Appreciate your help.

Thank you!

 

Hi,

Were you able to sort this out? How are you triggering the PL/SQL code/method that you attached?

 

Hi @Mathias Dahl ,

Yes, I got this solved.

I was triggering the attached code via a PL/SQL test block for the testing purpose, and it should be added to a background job for a RMB menu.

The issue was with the FTP password, 

it contained some characters like square, once we update the password to get rid of those characters, the document got succesfully downloaded and attached to email.

It seems that the one document that was successfully emailed, before was there in the directory somehow, so that it got through with no issue.

 

Thank you!

Hi @Mathias Dahl ,

Yes, I got this solved.

I was triggering the attached code via a PL/SQL test block for the testing purpose, and it should be added to a background job for a RMB menu.

The issue was with the FTP password, 

it contained some characters like square, once we update the password to get rid of those characters, the document got succesfully downloaded and attached to email.

Good to hear it was sorted out. And yes, "special" characters in passwords can be tricky to handle in certain cases. FYI, the password most probably did not contain "squares", it contained characters with a low ASCII code (below 32), which the font and many programs cannot display (some programs use question marks instead). So, to avoid problems it's good to avoid them...

Thanks for reporting back!

 

 

Reply


Terms & ConditionsCookie settings