Quelle technologie utiliser pour développer des solutions de messagerie Outlook/Exchange ?

Le développement autour d’Exchange/Outlook fait appel à de nombreuses technologies différentes : CDO, CDOEX, CDOEXM, WebDav, WebServices, Automation, etc… Comment s’y retrouver ? Voici un rapide résumé de la situation :

Note : les informations présentées ici sont quasiment uniquement liées à Exchange 2003. Nous verrons la plateforme Exchange 2007 dans un post séparé un peu plus tard.

Présentation des technologies d’accès aux boîtes aux lettres sous Exchange 2003

Commençons par faire un point sur les technologies disponibles pour accéder aux boîtes aux lettres d’Exchange. Il existe à ce jour plusieurs technologies disponibles pour accéder, par code, au serveur Exchange. Voici le point d’entrée sur l’ensemble d’entre elles : https://msdn2.microsoft.com/en-us/library/aa142515.aspx .

Vous y trouverez également un comparatif des différentes technologies. Je vous invite à parcourir cette documentation car elle contient vraiment tous les critères possibles pour établir une décision sur le chemin à suivre en fonction de ses besoins.

Par ailleurs, je vous invite également fortement à télécharger le SDK d’Exchange 2003 ici : https://www.microsoft.com/downloads/details.aspx?FamilyID=5ca18d40-5a37-4a20-94ae-6a6cf6cb846d&displaylang=en

Ensuite, on peut considérer que 5 technologies sont disponibles pour accéder au store :

- Extended MAPI : c’est la couche de base utilisée notamment par Outlook. Cependant, cette dernière doit uniquement être utilisée en C++. Outre l’éventuelle difficulté liée au langage en lui-même, Extended MAPI nécessite surtout un travail important d’investissement et de formation. Même chez Microsoft, les compétences sur le sujet sont rares et les ingénieurs ont eu besoin d’une longue période de formation avant d’en maîtriser tous les aspects. Il faut donc vraiment se poser la question avant d’investir sur cette voie. Si votre application en cours n’est pas le cœur de votre business, je vous conseillerais plutôt d’investir dans une autre des technologies. Malgré tout, Extended MAPI reste aujourd’hui la technologie permettant le plus de possibilités du fait que c’est également celle de plus bas niveau. C’est la seule par exemple capable de créer les règles Outlook.

- CDO 1.21 : Sur-ensemble de MAPI prévu pour les développeurs VB 6.0 et script. Simple d’utilisation, il permet presque de tout faire comme Outlook. Cependant, il ne sera pas supporté en .NET et est relativement lent pour traiter de nombreuses boîtes aux lettres. En effet, il faut alors créer une session par utilisateur et cette opération est couteuse.

- WebDAV : technologie utilisée par OWA (Outlook Web Access). C’est bien souvent la meilleure technologie à utiliser pour accéder, à distance, aux informations du store d’Exchange. Disponible à partir d’Exchange 2000, c’est définitivement ce modèle de programmation que nous vous conseillons si la cible est minimum une plateforme 2000. Mais bien entendu, cela dépend également de ce que vous souhaitez faire. WebDAV permet virtuellement de tout faire comme le propose OWA (Outlook Web Access). C’est un sur-ensemble du protocole http et il est extrêmement performant. Par contre, il nécessite plus de temps d’apprentissage pour un développeur CDO par exemple. Il est notamment très verbeux car il s’appuie sur le XML.

- CDOEX (CDO for Exchange) : Sur-ensemble de CDOSYS, il expose de nouvelles interfaces comme IPerson pour gérer un utilisateur, etc. Il est aussi simple d’utilisation que CDO 1.21 mais souffre d’une grosse limitation : son accès est supporté et limité uniquement sur le serveur Exchange même. On ne peut donc pas l’utiliser depuis une machine distante (serveur applicatif par exemple). Par contre, c’est définitivement une technologie à envisager à l’intérieur d’un Store Event Sink avec l’utilisation d’ADO également.

- Outlook Automation: comme vous le savez sûrement déjà, chaque application Office est livrée avec un modèle objet COM permettant de piloter telle ou telle application. L’automation Outlook consiste donc simplement à utiliser ce modèle COM pour piloter Outlook. Ce qu’Outlook propose dans son interface peut alors quasiment entièrement être fait par code. Cependant, la grosse limitation ici est que ce modèle est uniquement prévu pour une logique d’application cliente pure avec une interaction utilisateur. Oubliez donc tout de suite l’idée même d’utiliser cet objet COM dans une application de type Service NT, ASP.NET, Task Scheduler, etc. Cela ne sera pas supporté par Microsoft et vous conduira sous aucun doute à une situation instable.

Filtrage - conclusion

Résumons. Pour commencer, on peut filtrer en fonction du type de langage de développement retenu. Si on utilise un langage managé, on ne peut pas utiliser CDO 1.21 ni MAPI (ce n’est pas supporté) : https://support.microsoft.com/kb/813349/en-us.

Donc, en .NET, il nous reste WebDAV et CDOEX pour les solutions côté serveur. Pour un code côté client, on peut également envisager l’automation Outlook (en effet n’oublions pas que l’automation d’application Office n’est pas supporté coté serveur !).

CDOEX doit être utilisé impérativement sur le serveur Exchange lui-même. C’est donc une grosse limitation. En effet, on peut rechigner à installer des solutions personnalisées sur le serveur Exchange.

Si on part sur un développement en .NET, le meilleur choix sera donc WebDAV. On trouvera des exemples dans la KB et dans MSDN, comme par exemple https://msdn2.microsoft.com/en-us/library/ms877306.aspx.

Et coté Exchange 2007 ? Si l’on parle de la version 2007 d’Exchange, le must du must reste l’utilisation des Web services. Les Web services sont apparus avec Exchange 2007, et concurrence WebDAV. A terme, WebDAV devrait même disparaître… Exchange 2007 fera certainement l’objet d’un post séparé.

Attention, si vous souhaitez pouvoir accéder à plusieurs boîtes aux lettres pour créer les rendez-vous ou autres éléments, il faudra faire attention à créer un compte ayant les droits suffisants. Et par ces temps de hotfix de sécurité dans tous les sens, il faut bien y réfléchir avant…

Pour terminer, voici quelques liens utiles :

- D’une manière générale, le meilleur exemple de code qui existe autour d’Extended MAPI est MFCMAPI : https://support.microsoft.com/kb/291794/en-us livrée avec son code source

- Introduction à CDOEX pour Microsoft Exchange 2000 : https://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/dntaloc/html/introcdoexch2k.asp

- Une excellente compilation de l’ensemble des ressources disponible autour de MAPI : https://www.outlookcode.com/archive0/d/mapi.htm

- Outlook Object Model Overview : https://msdn2.microsoft.com/en-us/library/ms268893(VS.80).aspx . Cet article vous donnera un rapide aperçu du modèle objet Outlook à manipuler un l’Add-in ou depuis une application externe

- Outlook Tasks : https://msdn2.microsoft.com/en-us/library/ms268731(VS.80).aspx . Vous y retrouverez pas mal d’exemples sur ce que l’on peut faire avec Outlook par programmation (comment ajouter de nouveaux menus, comment réagir à l’arrivée d’un nouvel email, etc.)

-= David =-