We have several Windows Services that have the ability to add an entry to people's Outlook Calendars or Task Lists. This cannot be done using Outlook Automation, because that requires Outlook to be accessible to run which it cannot be from a Windows Service. Furthermore, it mandates that Outlook is installed on the PC or Server which is not something we can guarantee.
The alternative I started using years ago was Collaboration Data Objects, CDO, a Microsoft library that basically gives you a great deal of access to the Exchange Server, without ever having to know anything about Outlook, which is, after all, just a client for Exchange Server.
CDO is available in Delphi by simply importing the "Microsoft CDO 1.21 Library" type library.
Despite being complicated to set up (necessarily so due to mailbox security), this works very well, and is what Microsoft use for their Outlook Web Access software. Reading on the subject, I see that Symantec and Blackberry are also users of this API.
Now, Microsoft being Microsoft, CDO has not been on-developed for quite some time, although it continues to work just fine. It is no longer installed as standard on the OS when Outlook (2007 onwards) is installed, but they now allow you to install it yourself by releasing an MSI that installs the CDO and MAPI DLLs.
Microsoft state in their Knowledgebase Article 2028411 that:
Programs that use CDO should be re-designed to use other Application Programming Interfaces (APIs) instead of CDO. Starting with Outlook 2007, the Outlook object model was greatly expanded to provide functionality that was previously available only by using CDO 1.2.1. The Outlook 2010 object model includes some new features to expand on this more...The Outlook object model also works for both 32-bit and 64-bit versions of Outlook. Developers should use the Outlook 2010 object model instead of CDO 1.2.1. Also, developers can still use Extended MAPI (which requires unmanaged C++) in some scenarios where CDO was required. However, if it is possible, we generally recommend that the Outlook object model be used instead of Extended MAPI.
The question is, what are developers supposed to use instead of CDO? It fills a gap that the Outlook Object Model cannot fill, namely, use in web applications and Windows Services. It appears they are not providing an alternative, and yet are encouraging developers away from it towards a tool that cannot work unless running as a standard Windows application.
6 comments:
I would use RDO (Redemption Data Objects, see http://dimastr.com/redemption/ and click "RDO" in the top frame) in combination with the standalone MAPI DLLs. It's a great library that takes away a lot of the complexity of Extended MAPI, while offering an interface that is very similar to CDO, but without its limitations.
Thanks Oliver, I looked into Redemption a few years ago but went with CDO because it was the native Microsoft choice. I'll look at it again. But you'd think MS would need to provide an alternative to their API, wouldn't you?
Well, Extended MAPI *is* an alternative of sorts... if you're a masochist, that is... ;)
This is not the most timely reply, but I think they are wanting you to use Exchange Web Services (EWS). I have been able to use them successfully with C# but I am still struggling with integrating it into Delphi. My plan was to create a dll wrapper with C# and then call that from my Delphi app but I haven't gotten it to work yet... so, not an entirely helpful post.
Thanks Tony, I'll look into that. I'm tempted to go with Redemption, as he appears to be keeping it up to date. I'd just like to know how he's overcome all the issues that I appear to be facing with CDO!
Thanks for that Jason!
Post a Comment