Tuesday 16 November 2010

Using CDO to write to Exchange from a Windows Service

Not strictly a Delphi-post this one, but still a programming issue nonetheless.

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.