1
votes

I am writing a addin that requires the email content in MIME format. Now I am using the ewsurl(), getCallBackTokenAsync(), and Office.context.mailbox.itemId api's to find out the EWS url, access token, message id and sending it to my back-end via Ajax. My back-end sends a SOAP request to EWS and downloads the email message. Is this approach correct?

My main concern is will there be any throttling if the EWS endpoint sees too many request coming from the same machine. For example, several users(say couple of hundreds) in an organisation could use the add-in concurrently. In this case , the add-in back-end could send several concurrent requests to EWS. Would EWS implement some throttling if it sees too many requests coming from the same add-in / the same back-end machine

Are there any alternative approaches?

2

2 Answers

0
votes

This is the only approach at the moment. Neither Office.js nor Graph supports getting the raw email message. Given that add-ins run within the context of a single email, I can't imagine this would result in more than a couple of calls per second at most so I wouldn't be too concerned with throttling.

0
votes

I am writing a addin that requires the email content in MIME format.

You will not be able to get original MIME message. Exchange doesn't store MIME content. You may get generated MIME content which done on the fly by Exchange and this conversion is expensive. Resieved MIME message has nothing to do with original MIME received by Exchange, so why bother? The maximum you will be able to get with EWS requests is original message headers (PR_TRANSPORT_MESSAGE_HEADERS), but not entire original MIME message.

Limits: If you would use EWS requests from the client (makeEwsRequestAsync ) you would be limited to 3 asynchronous calls and 1 Mb of response. If you do this from your server you will be able by pass those limits. More on this: Limits for activation and JavaScript API for Outlook add-ins