Jump to content
View in the app

A better way to browse. Learn more.

FMForums.com

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

using 360Works Email plugin to parse inbound HTML email

Featured Replies

We have a client that is sending email to us from their ServiceDesk help desk system.  The issue is that the email is laced with HTML tags, so much so that the 360Works Email plugin script step to read the email doesn't find any body to insert in a FileMaker field.  The script step is of the form:

Set Field[ImportedMessage::body ; EmailReadMessageValue( "body" )]

The field ImportedMessage::body is empty, even though we know there is content because a cc copy of the same email can be read, for example, by Apple Mail.  Any ideas how to parse the content out of an email that a bunch of HTML junk embedded throughout the body of the email?

Hello,

 

EmailReadMessageValue("body") is the equivalent to the documented value "text" so passing in that value will only return the plaintext version of an email, if one is available. I suspect since you are getting a blank result then the email you are parsing does not have a plain text body version. I think you will get better results by using one of the following values:

 

"html" (The HTML body part, if one is available. If attachments are set to download, inline attachment images will be converted to base64 data URLs automatically. If you don't want this behavior, use htmlRaw instead, or set attachments=false when fetching messages.)

"htmlRaw" (The HTML body part unaltered, if one is available.)

 

  • Author

Thanks very much, Ryan.  I'll give that a try.  I think you are correct:  these emails must contain HTML exclusively.

A few questions, however:  it is very possible that inline attachments will be included in emails that are processed this way and it is likely we will also receive plain text emails.  If I switch from "body" to "html" ...

  1. Will plain text emails still have their contents inserted into a FileMaker text field as before?
  2. Will attachments at the end of emails still be able to be downloaded and placed in container fields in FileMaker the same way?
  3. Will attachments that are inline (with possible images that, as you say, will be converted to base 64) still be able to be downloaded and placed in container fields in FileMaker the same way?  (Will converting to base 64 make a difference in how the container field is able to display its contents?)

Thanks!

Martin

 

Hi Martin,

1. For emails that only contain plaintext and no html counterpart, you will probably see the same behavior you were seeing with "body" and emails with only an HTML body, an empty result.  To make the script dynamic, I would recommend that you have a field for plain text content and a field for HTML and then call EmailReadMessageValue with both "text"(or "body") and "html". 

2. Yes

3. You should still be able to parse inline attachments the same way. This just gets the base64 representation of the inline attachment and puts it in HTML being requested, it doesn't convert the actual inline attachment file that gets downloaded with EmailReadMessages. 

 

Create an account or sign in to comment

Important Information

By using this site, you agree to our Terms of Use.

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.