Hi Support, Can you please give some details on how the added "support for email headers" is meant to function? Bugs: 1. Context menu of operations on Google Maps didn't work 2. Render script defined for a content panel in a VP was not executed if panel was refreshed 3. Google Map with many markers was slow even if geo coding was not used 4. Enabling/disabling of Deletes on calendar is always allowed Improvements: 1. CR removed from the output of GET_CHANGES function [b]2. Support for e-mail headers[/b] Thx,

Build 2240

weblike

Hi Support,

Can you please give some details on how the added "support for email headers" is meant to function?

Bugs:

Context menu of operations on Google Maps didn't work
Render script defined for a content panel in a VP was not executed if panel was refreshed
Google Map with many markers was slow even if geo coding was not used
Enabling/disabling of Deletes on calendar is always allowed

Improvements:

CR removed from the output of GET_CHANGES function
2. Support for e-mail headers

Thx,

aware_support

This will be documented soon. In the meantime if you want to add MIME headers to your email you need to add an attribute to your OutgoingEmailNotification called "EHeaders".

You should then populate this attribute at runtime with the headers you want to add. If you have more than one header they should be separated by the "#" delimiter. Each header should have the standard header format:

Name: Value

so for several headers you would have something like this:
Name1: Value1#Name2: Value2 ...

ACDC

support, does this mean we can create our own Message-id which will overwrite the java mail Message-id?

aware_support

Not sure what you are talking about. If Message ID is a header then yes

tford

Exciting news about Email headers. We use Mandrill for outgoing emails and being able to write to email headers will allow me to explore additional tracking that is available in Mandrill:

https://mandrill.zendesk.com/hc/en-us/articles/205583207-What-is-the-format-of-inbound-email-webhooks-

Once we include certain info in the email headers, there will be additional filtering available when I log into our Mandrill account.

Now if we could integrate Mandrill's webhook's to AwareIM, we could receive some very valuable info back into our applications (for example: read receipts and links clicked):
https://mandrill.zendesk.com/hc/en-us/articles/205583217-Introduction-to-Webhooks

RLJB

Tom - that was exactly the purpose for getting this developed, you can now inject a custom header into outgoing email and when using a SMTP sending service like Mandrill or SendGrid or Google Analytics you can use this to track opens/clicks/bounces etc. with a webhook.

FYI - we have set up a AWS Gateway API with a Lambda function to set up the webhook with Sendgrid, we will write the opens/clicks/bounces to an RDS MySQL table which aware connects into, thus pulling the reporting back into Aware.

tford

Sweet Rod! You're my hero!

While I don't have the tech knowledge to achieve the 2nd piece myself, at least now with the email header the door is open for that possibility. Now I just need to find someone who help build the bridge.

I'm thankful that someone else sees how much synergy a transactional email service like SendGrid and Mandrill can have once you have the webhook info fed back back into AwareIM.

tford

Wondering if this might be my answer to building a bridge from Mandrill's webhook to MySql like you built, Rod:

https://zapier.com/zapbook/mandrill/mysql/

RLJB

That Zapier, looks perfect for the job, tell us how you go.

ACDC

Why would you need a bridge ? why not let mandrill post directly back to your awareim app. Having the Message-id embedded in the call back from mandrill makes for a good solution now (BTW, thanks Rod- having the Message-id now completes the puzzle)

here is a call back url example (embedded on Mandrill side)
"http://xxxxxxxxx//xxxxxxxx/logonOp.awsp?Domain=CRM&userName=Mandrill&password=1234&ProcessName=EmailLogMandrill&ObjectName=EmailLogMandrill&EventType=Open&Message-id=646464646464yt6767yy"

This example assumes you have an Object in AwareIM called EmailLogMandrill containing the different result parameters and a Process Named EmailLogMandrill which posts the result data contained in the url call back

tford

Thanks for the tip, ACDC! Anxious to try that next week.

Do you have it working?

hpl123

Very nice and I would also like to know if this works. Thanks

ACDC

Do you have it working?

With regards to the new MIME header feature, no... but the callback concept does work.
I haven't worked with Mandrill but the concept of URL call back should be the same.

If you are going to test it then first create the AwareIM Object and Process and then test it by connecting to your app using a hard coded URL string with the simulated content. Once this is working then go about the setup of the url on the Mandrill side while also adding the mime header to your outgoing email.

The last time I worked on this was way back using Jango Mail who have a similar service to Mandrill. At the time Vladimir assisted me to get it working, that's how this "logonOp.awsp?" function came about - but the Message-id was the missing part of the puzzle and we ended up using it in a "faking" kind of way with intention of one day paying for the Message-id function - but Rod beat us to it 😃

Jaymer

Any updates on this guys?
Any examples of what your new email header (EHeaders) strings look like?
I'd like to alter the header to show the real name of the employee/user who is sending the email, plus a valid return path for that user.

AIM v8 docs only has this:

You can also optionally add the EHeaders attribute to this notification if you want to add special headers to your email. The value of this attribute should be in the following format:
Header1#Header2#Header3…
where each header represents name and value in the standard header format:
Name: value

Here's what I'm trying:

Return-Path: jaymerx@yahoo.com#From: Bulls_CRM#From_Email: tom_smith@bulls.com

What I've found is these new headers are added IN ADDITION TO the headers already there... so even though I use RETURN-PATH, there's a prior RETURN-PATH in the header, so the email client on the Mac doesn't appear to see the 2nd one. So when I reply, its not going to my EHeader one.