Skip to main content
  • EN

We've got a real head scratcher here. We are collecting data in Survey123 for ArcGIS and are using FME to listen for the submissions. Everything works perfectly for receiving the JSON. We've taken that JSON and built a workspace around looking at the data as it is pulled from ArcGIS Online without any issue. We even deal with repeats associated with Survey123. Here's the part we can't seem to get past. We have set up all of the attachment parameters and the job clearly pulls the attachments and it saves them in our specified directory. We even have it saving under FME Server in the resources-data directory. So there is no issue with the attachments being pulled. Our issue is we cannot get them to properly attach to the email being sent.

 

When we remove the attachment parameters from the FMEServerEmailGenerator (Leaving attachments blank) the email comes through perfectly. It contains all of the HTML formatting we set up. But the second we reference the attachment the email will not send and the logs (Located under Resources/Logs/core/current/subscribers/email.log) generate a very strange message. Here's the message we get:

 

Tue-11-Feb-2020 09:02:53.274 AM WARN main 801012 : Skipped sending email because no recipients were specified

 

When we run the job with the attachment field blank here's the message in the logs (Resources/Logs/core/current/subscribers/email.log). NOTE: the "#" signs directly below are used to cover up potentially sensitive data:

 

Tue-11-Feb-2020 09:00:28.744 AM INFORM pool-2-thread-4 801007 : Sending email with subject "Sump Inspection Issue(s) - ######: (######)" to recipient(s) "######@#########.com" ...

Tue-11-Feb-2020 09:00:28.987 AM INFORM pool-2-thread-4 801019 : Successfully sent email.

 

We've tried referencing the attachments using the FME_SHARED_RESOURCE_DATA location on FME Server and we've also tried referencing the attachments locally using the UNC path as well. Again these attachments exist perfectly after the job runs, and can be viewed if we go to their directories. We just cannot get them to attach to the email.

 

Here's how we have the FME_SHARED_RESOURCE_DATA parameter set up:

 

"\\\\########\\##\\ProgramData\\Safe Software\\FME Server\\resources\\data

 

Then the Attachments field is populated with this:

 

$(FME_SHAREDRESOURCE_DATA)/#####.zip (NOTE: The images are zipped)

 

Any ideas? We have exhausted everything in our search to make this work and we are so close!!!! Thanks in advance if you can help us.

 

Tony

I'll leave this question and answer up in the off chance anyone else encounters this issue. I'm going to mark it solved and give the credit to our resident FME expert Tyson M because he figured it out. Here's what causes what I described. The attachment cannot handle any HTML formatting that has a curly bracket in it "{" or "}". When it comes across the closing bracket in the HTML (as it creates the JSON using an attachment) it inserts the attachment after that closing bracket. Which in this case was dead center of the JSON (Also putting the attachment at the end of the JSON too). As you probably know, this ends up corrupting the JSON formatting and causes the email to not generate. So be very careful using this type of style formatting in the body of the email you want sent.

Here's the formatting we removed from the styling associated with the body of the email:

{

border: 1px solid black;

border-collapse: collapse;

background-color: #e0e0eb;

}

Tagging Rylan Maschak since he made the last 5 updates (2016-02-23 through 2017-06-28) to the FMEServerEmailGenerator so he is aware of the issue it creates.

@rylanatsafe

History of FMEServerEmailGenerator Transformer

Date User Comment

2016-02-23 Rylan Maschak Updated for FME Hub; Revised JSON formatting of text_line_data attribute

2016-03-23 Rylan Maschak Documentation clarification and rearranged input parameter order

2016-05-03 Rylan Maschak Fixed attachment handling

2017-03-08 Rylan Maschak Updated for FME 2017; Added Bcc field

2017-06-28 Rylan Maschak Added Bcc field for Single attachment stream

 

I'll leave this question and answer up in the off chance anyone else encounters this issue. I'm going to mark it solved and give the credit to our resident FME expert Tyson M because he figured it out. Here's what causes what I described. The attachment cannot handle any HTML formatting that has a curly bracket in it "{" or "}". When it comes across the closing bracket in the HTML (as it creates the JSON using an attachment) it inserts the attachment after that closing bracket. Which in this case was dead center of the JSON (Also putting the attachment at the end of the JSON too). As you probably know, this ends up corrupting the JSON formatting and causes the email to not generate. So be very careful using this type of style formatting in the body of the email you want sent.

Here's the formatting we removed from the styling associated with the body of the email:

{

border: 1px solid black;

border-collapse: collapse;

background-color: #e0e0eb;

}

Tagging Rylan Maschak since he made the last 5 updates (2016-02-23 through 2017-06-28) to the FMEServerEmailGenerator so he is aware of the issue it creates.

@rylanatsafe

History of FMEServerEmailGenerator Transformer

Date User Comment

2016-02-23 Rylan Maschak Updated for FME Hub; Revised JSON formatting of text_line_data attribute

2016-03-23 Rylan Maschak Documentation clarification and rearranged input parameter order

2016-05-03 Rylan Maschak Fixed attachment handling

2017-03-08 Rylan Maschak Updated for FME 2017; Added Bcc field

2017-06-28 Rylan Maschak Added Bcc field for Single attachment stream

 

I had ran into some issues before with the FMEServerEmailGenerator, but I replaced those transformers with the Emailer transformer directly in the workspace.

Reply


Community Stats

30,159
Posts
114,479
Replies
37,802
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.