Question

FME Server 2021.0: Email attachments are not found in automations with names containing certain characters?

  • 30 December 2021
  • 6 replies
  • 21 views
J
Badge

I believe automations with names containing for examlple commas (',') are not able to use incoming email attachments. The email attachment is downloaded to a temporary folder like the example below where the name of the automation becomes a part of the path:

C:\\ProgramData\\Safe Software\\FME Server\\resources\\system\\temp\\emailattachments\\20211230112047-<Name_of_automation>-<Email_Subject>-7ac8a779-9ea4-4ab3-a228-c880ec539c95\\data_562_1715_20211013_0933.xml

 

Spaces in the automation name is replaced by underscore but a comma sign is not.

 

I am not using the option to download the attachment to a specified folder.

I got this error (with the triple dots added by me):

XML Parser error: 'unable to open primary document entity 'C:\\ProgramData\\Safe Software\\FME Server\\resources\\system\\temp\\emailattachments\\... analys,_uppdate...data_562_1715_20211013_0933.xml

 

Note the bold part with a comma in the path.

I renamed the automation and the problem was solved.

6 replies

H
Badge +2

Hi @jonas.persson​ ,

 

I'm sorry that you encountered this problem. I have done some testing to try and reproduce the problem but I've not had any luck. When I include a comma in the Automation Name I can see that this is included in the email attachment file path, however, the translation completes successfully testing on Windows OS and with various formats.

 

I was able to reproduce the error once, but that was when I made a mistake and the XML file wasn't actually present in the attachment folder. How are you specifying the attachment, - are you using the 'Email Attachment' or 'Email Attachment Folder' and then specifying the file name in the published parameter?

 

Note: I will be filing an issue to strip the comma from the attachment file path because this is already the behaviour for other special characters e.g. apostrophe/question mark

J
Badge

Hi @hollyatsafe​ 

I'm using the 'Email Attachment' as input to the published parameter for source file.

H
Badge +2

Hi @hollyatsafe​ 

I'm using the 'Email Attachment' as input to the published parameter for source file.

Thanks @jonas.persson​. Are you sending any other files through with the email, e.g. an .xsd file?

J
Badge

No, only a single .xml file.

H
Badge +2

No, only a single .xml file.

Hi @jonas.persson​ ,

 

Are you able to share your workspace and an example XML file for me to test with? If you'd prefer not to share over the Community you can email this to holly.coxon@safe.com.

P
Rank
Badge +1

Hello,

I think i have a relative issue.

I’m sending an email containing a .xml and a .pdf to an automation.

The server gets the attachments and download them to : {FME_SHAREDRESOURCE_TEMP}\ 

And generates a subfolder names in this way : [Date]-[user]-[mail_subject]-[some automated generated unique id].

 

The thing is that my mail subject is containing some special characters such as “[“ , “éè@” etc. and the final attachment folder path contains this special chars, which, i assume is causing some troubles.

 

Then, the automation executes a workspace containing a xml Reader, this reader fails to open the xml. This xml is well uploaded on the server, and the whole workspace is working well on this .xml when the mail_subject isn’t containing any special chars.

 

As i can’t control the way my users are writing there mail subjects i was considering 2 solutions :

  • Modify the way FME server is generating the mail_attachment folder by deleting the [mail_subject] part.
  • Parsing the attachment folder path send to the reader to escape special chars

Reply


Community Stats

28,724
Posts
109,518
Replies
36,564
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.