locked
Message Tracking for EWS Managed API RRS feed

  • Question

  • I have not been able to find the EWS operations (FindMessageTrackingReport and GetMessageTrackingReport) counter-parts for Message Tracking on EWS Managed API 1.0
    Is EWS Managed API really missing those two operations or have I somehow skipped over them?
    If they are really missing, any plans to include them on EWS Managed API? When?
    Alfred Myers - MVP Visual Developer - Visual C#, MCT, MCPD Enterprise Applications Developer, MCSD .NET
    • Edited by Alfred Myers Friday, January 15, 2010 7:43 PM Deleted "mysterious" extra text that wasn't typed by me
    Friday, January 15, 2010 7:37 PM

Answers

  • Yes, those methods are indeed missing from the client API.  We may add those to the client API in the future (very vague, non-commital type comment, eh?)

    Regarding using them, your best bet is to keep an ExchangeServiceBinding (proxy object) around and use that when you need to call the message tracking methods.
    David Sterling | Microsoft Exchange Web Services | http://www.microsoft.com/MSPress/books/10724.aspx
    • Marked as answer by Alfred Myers Tuesday, January 19, 2010 1:06 PM
    Monday, January 18, 2010 6:23 PM

All replies

  • Yes, those methods are indeed missing from the client API.  We may add those to the client API in the future (very vague, non-commital type comment, eh?)

    Regarding using them, your best bet is to keep an ExchangeServiceBinding (proxy object) around and use that when you need to call the message tracking methods.
    David Sterling | Microsoft Exchange Web Services | http://www.microsoft.com/MSPress/books/10724.aspx
    • Marked as answer by Alfred Myers Tuesday, January 19, 2010 1:06 PM
    Monday, January 18, 2010 6:23 PM
  • I searched ExchangeService (Managed API) for a member exposing a proxy object (ExchangeServiceBinding) and haven't found any.

    From what I understood, ExchangeService does not expose one - making it necessary to instantiate and setup correctly two objects:

    - An EWS Managed API ExchangeService and;
    - An auto-generated web service proxy ExchangeServiceBinding

    Is that correct?

    If that is the case, I'd like to suggest that ExchangeService exposed means to invoke methods on EWS for which it does not currenty have a strongly typed method.

    That could be done either by exposing an Invoke method (similar to SoapHttpClientProtocol.Invoke) or by exposing a member that would return an auto-generated proxy properly configured with its properties matching those of ExchangeService.

    Something similar to the prototype below.

    public class ExchangeService {
        public object[] Invoke(string methodName, object[] parameters) {
            // Invoke the web service
        }
    
        public T CreateProxy<T>() where T : SoapHttpClientProtocol {
            T proxy = default(T);
            proxy.CookieContainer = this.CookieContainer;
            proxy.Credentials = null; //Convert ExchangeCredentials to ICredentials
            proxy.Url = this.Url.ToString();
            proxy.UseDefaultCredentials = this.UseDefaultCredentials;
    // you get the idea...
    return proxy; } }

    The "Invoke" approach may bring some trouble when having to deal with serializing complex types. I haven't stopped to think that through.
    The CreateProxy approach would resolve the potential problem of serializing complex types and would guarantee that both ExchangeService and the auto-generated proxy configurations match each other.

    Both approaches may have other cons I haven't thought through, but I'll leave the idea here anyway.


    Alfred Myers | MVP Visual Developer - Visual C# | http://twitter.com/AlfredMyers
    Monday, January 18, 2010 8:53 PM
  • Yes, you are correct.  Currently it would require you to create two bindings (one via the client API and one via the autogenerated proxy stuff).

    The "Extensible" client API is certainly an interesting concept with pros and cons as you suggest.
    David Sterling | Microsoft Exchange Web Services | http://www.microsoft.com/MSPress/books/10724.aspx
    Tuesday, January 19, 2010 3:47 AM