Skip to main content
Question

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

  • December 30, 2021
  • 6 replies
  • 61 views

Forum|alt.badge.img

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

Forum|alt.badge.img+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


Forum|alt.badge.img

Hi @hollyatsafe​ 

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


Forum|alt.badge.img+2
jonas.persson wrote:

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?


Forum|alt.badge.img

No, only a single .xml file.


Forum|alt.badge.img+2
jonas.persson wrote:

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.


Forum|alt.badge.img+1
  • Participant
  • February 27, 2024

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

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings