Les développeurs peuvent recourir à l'automatisation dans Microsoft Office pour créer des solutions personnalisées qui tirent profit des capacités et fonctionnalités intégrées dans le produit Office. Toutefois, si ce type de développement par programmation peut être implémenté relativement facilement sur un système client, un certain nombre de complications peuvent apparaître lorsque l'automatisation s'exécute à partir d'un code côté serveur tel que Microsoft ASP (Active Server Pages), DCOM ou un service Windows NT.

Cet article décrit les complications auxquelles les développeurs peuvent être confrontés, offre des alternatives à l'automatisation susceptibles d'accélérer les performances et suggère des étapes de configuration d'Office si l'automatisation côté serveur est incontournable. Toutefois, les développeurs doivent savoir que les suggestions présentées ci-dessous sont offertes uniquement à titre d'information. Microsoft ne recommande pas et ne prend pas en charge l'automatisation côté serveur de Microsoft Office.

Remarque Dans ce contexte, le terme « côté serveur » s'applique également à un code exécuté sur une station de travail Microsoft Windows NT ou Microsoft Windows 2000, à condition que la station Windows ne soit pas celle sur laquelle l'utilisateur a ouvert une session interactive. Par exemple, un code démarré par le Planificateur de tâches sous le compte SYSTEM est exécuté dans le même environnement qu'un code ASP ou DCOM « côté serveur » et est donc confronté pour la plupart aux mêmes problèmes. Pour plus d'informations sur les stations Windows et COM, reportez-vous aux sections « Plus d'informations » et « Références ».

Retour au début

Toutes les versions actuelles de Microsoft Office ont été conçues, testées et configurées pour être exécutées par l'utilisateur final sur une station de travail cliente. Elles requièrent un Bureau interactif et un profil utilisateur et n'offrent pas le niveau de sécurité ou de réentrée nécessaire pour répondre aux besoins des composants côté serveur conçus pour s'exécuter sans assistance.

À l'heure actuelle, Microsoft ne recommande pas et ne prend pas en charge l'automatisation des applications Microsoft Office à partir d'une application ou d'un composant client non interactif et sans assistance (y compris ASP, DCOM et les services NT), car Office peut présenter un comportement instable ou entraîner un blocage lorsqu'il est exécuté dans ce type d'environnement.

Si vous créez une solution fonctionnant dans un contexte côté serveur, vous devez dans la mesure du possible tenter de recourir à des composants ayant été conçus pour être exécutés sans assistance de manière fiable ou trouver des solutions de remplacement permettant à au moins une partie du code de s'exécuter côté client. Si vous choisissez d'utiliser une application Office à partir d'une solution côté serveur, vous pouvez constater qu'il lui manque de nombreuses capacités pour s'exécuter correctement et vous risquez de compromettre la stabilité de l'ensemble de votre solution.

Retour au début

Problèmes liés à l'utilisation de l'automatisation côté serveur de Microsoft Office

Les développeurs qui tentent d'utiliser Office dans une solution côté serveur doivent tenir compte de cinq éléments majeurs pour lesquels l'environnement entraîne un comportement imprévu d'Office. Si vous souhaitez exécuter votre code sans problème, ces situations doivent être corrigées et leurs effets minimisés autant que possible. Lorsque vous créez votre application, examinez ces problèmes avec la plus grande attention car il n'existe pas de solution globale capable de tous les traiter. Chaque type de conception vous oblige à les hiérarchiser différemment.

?	Identité de l'utilisateur : l'exécution des applications Office nécessite l'identité d'un utilisateur, même si elles sont démarrées par l'automatisation. Elles tentent d'initialiser les barres d'outils, les menus, les options, les imprimantes et certains compléments en fonction de paramètres figurant dans la ruche du Registre de l'utilisateur qui lance l'application. De nombreux services sont exécutés sous des comptes qui ne sont associés à aucun profil utilisateur (tels que les comptes SYSTEM ou IWAM_[nom_serveur]) ; par conséquent, Office risque de ne pas s'initialiser correctement au démarrage et de renvoyer une erreur sur la méthode CreateObject ou CoCreateInstance. Même si l'application Office démarre, d'autres fonctions risquent de ne pas fonctionner correctement sans profil utilisateur. Si vous envisagez d'automatiser Office à partir d'un service, vous devrez configurer soit votre code, soit Office de manière à ce que le programme s'exécute avec un profil utilisateur chargé.
?	Interactivité avec le Bureau : les applications Office nécessitent d'être exécutées sur un Bureau interactif et doivent parfois être rendues visibles pour que certaines fonctions d'automatisation fonctionnent correctement. En cas d'erreur inattendue ou lorsqu'un paramètre non spécifié est requis pour une fonction, Office invite normalement l'utilisateur à sélectionner un mode d'action à l'aide d'une boîte de dialogue modale. Sur un Bureau non interactif, les boîtes de dialogue modales ne peuvent pas être fermées, ce qui provoque le blocage du thread pour une durée indéterminée. Bien que certaines méthodes de codage puissent contribuer à réduire la probabilité d'occurrence de ce problème, elles ne peuvent pas l'éliminer entièrement. Ce fait, à lui seul, explique pourquoi l'exécution d'applications Office à partir d'un environnement côté serveur est une opération risquée et non prise en charge.
?	Réentrée et évolutivité : les composants côté serveur doivent être des composants COM multithreads particulièrement réentrants, capables de fournir une charge minimale et un débit élevé à plusieurs clients. Sous pratiquement tous les rapports, les applications Office présentent des caractéristiques inverses. Ce sont des serveurs d'automatisation STA, non réentrants, conçus pour fournir différentes fonctionnalités, exigeantes en ressources, à un client unique. En tant que solution serveur, elles offrent un faible niveau d'évolutivité et sont en outre soumises à des contraintes fixes, notamment en termes de mémoire, qui ne peuvent pas être modifiées par le biais de la configuration. Qui plus est, elles utilisent des ressources globales (telles que des fichiers de mémoire mappés, des compléments ou modèles globaux et des serveurs d'automatisation partagés) susceptibles de limiter le nombre d'instances pouvant être exécutées simultanément et de provoquer des situations de concurrence si elles sont configurées dans un environnement multiclient. Les développeurs qui envisagent d'exécuter simultanément plusieurs instances d'une application Office doivent prévoir un accès par le biais d'un regroupement ou d'une sérialisation pour éviter les risques de blocage et de détérioration des données.
?	Résilience et stabilité : Office 2000, Office XP, Office 2003 et Office 2007 utilisent la technologie MSI (Microsoft Windows Installer) pour simplifier les tâches d'installation et de réparation automatique pour l'utilisateur final. MSI introduit le concept d'« installation lors de la première utilisation », qui permet d'installer ou de configurer des fonctionnalités de façon dynamique lors de leur exécution (en fonction du système ou, le plus souvent, d'un utilisateur particulier). Dans un environnement côté serveur, MSI diminue les performances et augmente la probabilité de l'affichage d'une boîte de dialogue invitant l'utilisateur à approuver l'installation ou à insérer le disque d'installation approprié. Bien qu'elles soient conçues pour accroître la résilience d'Office en tant que produit destiné à l'utilisateur final, les capacités MSI sont contre-productives lorsqu'elles sont implémentées dans un environnement côté serveur. De plus, Office n'ayant pas été conçu ou testé pour ce type d'utilisation, sa stabilité globale ne peut être garantie lorsqu'il est exécuté côté serveur. Le fait d'utiliser Office en tant que composant de service sur un serveur réseau risque de compromettre la stabilité de l'ordinateur et, par conséquent, celle de l'ensemble du réseau. Si vous envisagez d'automatiser Office côté serveur, tentez d'isoler le programme sur un ordinateur dédié incapable d'affecter les fonctions critiques et pouvant être redémarré si nécessaire.
?	Sécurité côté serveur : les applications Office n'ont jamais été conçues pour être utilisées côté serveur. Elles ne tiennent donc pas compte des problèmes de sécurité auxquels sont confrontés les composants distribués. Office n'authentifie pas les demandes entrantes et ne vous protège pas contre l'exécution accidentelle de macros ou le démarrage d'un autre serveur qui pourrait exécuter des macros à partir de votre code côté serveur. N'ouvrez aucun fichier téléchargé sur le serveur à partir d'un site Web anonyme ! En fonction des derniers paramètres de sécurité définis, le serveur peut exécuter des macros sous le contexte Administrateur ou Système et compromettre votre réseau en disposant de tous les privilèges ! Par ailleurs, Office utilise de nombreux composants côté client (tels que Simple MAPI, WinInet, MSDAIPP) qui peuvent mettre en cache les informations d'authentification des clients afin d'accélérer le traitement. Si Office est automatisé côté serveur, une même instance peut desservir plusieurs clients. De plus, comme les informations d'authentification correspondant à cette session ont été placées dans un cache, il est possible pour un client d'utiliser les références en cache d'un autre client et d'obtenir ainsi illégalement des autorisations en usurpant l'identité d'autres utilisateurs.

Outre les problèmes techniques, vous devez réfléchir à la faisabilité de ce type de conception du point de vue des accords de licence. Les directives actuelles concernant les licences interdisent l'utilisation des applications Office sur un serveur en vue de traiter des demandes des clients, à moins que les clients ne disposent eux-mêmes de copies sous licence d'Office. L'utilisation de l'automatisation côté serveur pour fournir des fonctionnalités Office à des stations de travail qui ne disposent pas de licence n'est pas conforme aux Termes du contrat de licence logiciel.

Outre ces problèmes majeurs, de nombreux clients constatent que, sans modifier leurs paramètres d'installation par défaut d'Office, l'un des messages d'erreur suivants peut s'afficher lorsqu'ils tentent d'automatiser l'application côté serveur :

?	La fonction CreateObject/CoCreateInstance retourne l'un des messages d'erreur d'exécution suivants et ne peut pas être démarrée pour l'automatisation. Dans Microsoft Visual Basic (VB) ou ASP : ? Message 1 Erreur d'exécution '429' : Le composant ActiveX ne peut pas créer l'objet ? Message 2 Erreur d'exécution '70' : Autorisation refusée Dans Microsoft Visual C ou Visual C++ : ? Message 1 CO_E_SERVER_EXEC_FAILURE (0x80080005) : Échec de l'exécution du serveur ? Message 2 E_ACCESSDENIED (0x80070005) : Accès refusé Ces erreurs se produisent car le code côté serveur est exécuté sans profil utilisateur ou l'identité d'utilisateur spécifiée pour le contexte de démarrage ne possède pas les autorisations DCOM appropriées.
?	L'ouverture d'un document Office provoque l'une des erreurs suivantes : ? Message 1 Erreur d'exécution '5981' (0x800A175D) : Impossible d'ouvrir la macro de stockage ? Message 2 Erreur d'exécution '1004' : La méthode '~' de l'objet '~' a échoué En règle générale, ces erreurs sont dues à l'échec de l'initialisation de VBA en raison d'autorisations insuffisantes ou de composants VBA non inscrits dans le Registre ; ces deux problèmes sont courants lorsqu'un utilisateur exécute du code à partir d'un compte sans profil utilisateur (problème 1) et que le jeton d'utilisateur ne contient pas l'identificateur de sécurité (SID) interactif (problème 2).
?	CreateObject/CoCreateInstance se bloque et ne se termine pas ou accuse un délai de retour important. Sur certains serveurs, le processus de création est rapide, mais des erreurs 1004 s'affichent dans le journal des événements de Windows NT. Le problème est souvent dû à une boîte de dialogue modale affichée sur le Bureau non interactif qui exécute le code côté serveur (problème 2). Si la boîte de dialogue s'affiche à la suite d'un problème d'installation d'un composant MSI (une entrée de Registre manquante ou une image de fichier endommagée), le programme d'installation affiche un message invitant à insérer le CD-ROM d'installation s'il ne peut pas trouver le point d'installation, puis réinstalle un ou plusieurs composants (problème 4).
?	Certaines fonctions échouent de façon inattendue ou se bloquent indéfiniment. Sur un Bureau non interactif (problème 2), certaines ressources telles que des imprimantes, des lecteurs mappés, des objets incorporés OLE et le Presse-papiers peuvent ne pas être disponibles ou leur état peut être indéfini. De même, sans profil utilisateur (problème 1), les ressources réseau ne sont pas disponibles et les autorisations sont minimales.
?	L'exécution de plusieurs requêtes ou les tests de contrainte peuvent provoquer l'échec, le blocage ou l'arrêt du code lors de la création ou de l'arrêt d'une application Office. Lorsque cela se produit, le processus continue de s'exécuter en mémoire et ne peut pas être arrêté, ou toutes les instances de l'application automatisée échouent à partir de ce point. Étant donné que les applications Office partagent des ressources globales (problème 3), l'accès à une application Office doit être sérialisé lors d'opérations spécifiques, notamment au cours d'événements tels que le démarrage, la fermeture, l'impression, l'exportation et la mise à jour des liaisons OLE (y compris les notifications DDE).

D'autres problèmes ou messages peuvent apparaître outre ceux répertoriés ici, mais ils découlent généralement des cinq problèmes répertoriés plus haut. Pour résoudre ce type d'erreurs, les développeurs doivent configurer l'environnement d'exploitation d'Office pour simuler un état côté client ou supprimer l'application Office des codes côté serveur et utiliser à la place des composants plus évolutifs (ou recourir à l'automatisation côté client).

Retour au début

Utilisation de solutions alternatives à l'automatisation lors de l'exécution côté serveur

Microsoft recommande vivement aux développeurs de trouver d'autres méthodes que l'automatisation d'Office s'ils doivent élaborer des solutions côté serveur. En raison des limitations liées à la conception d'Office, tous les problèmes ne peuvent être résolus en modifiant sa configuration. Microsoft recommande un certain nombre de méthodes alternatives qui ne requièrent pas l'installation côté serveur d'Office et qui peuvent effectuer les tâches les plus courantes plus rapidement et de manière plus efficace que l'automatisation. Avant d'inclure Office en tant que composant côté serveur dans votre projet, envisagez d'autres solutions.

La plupart des tâches d'automatisation côté serveur impliquent la création de documents. Étant donné qu'Office 2000 et versions ultérieures prennent en charge HTML comme format de document natif, la plupart des documents peuvent être créés en HTML, en utilisant le cas échéant des balises XML (Extensible Markup Language). Ils peuvent ensuite être transmis à un client à l'aide d'un type MIME (Multipurpose Internet Mail Extensions) en vue d'afficher le texte résultant dans Office. Le document peut être modifié, enregistré et même renvoyé au serveur si nécessaire, en utilisant simplement ASP sur le serveur. Dans les versions d'Office antérieures, d'autres formats de texte faciles à manipuler (tels que RTF) peuvent être utilisés aux mêmes fins.

Certains formats binaires natifs peuvent être modifiés à l'aide de composants OWC (Office Web Components) ou de ADO (ActiveX Data Objects) avec une rapidité et une souplesse supérieures. Les propriétés de documents peuvent être affichées et modifiées sans avoir recours à l'automatisation. Par ailleurs, la gestion des fichiers et le contrôle des versions peuvent s'effectuer à l'aide des extensions serveur FrontPage (FPSE) ou du protocole DAV (Distributed Authoring and Versioning). Lorsque l'automatisation est incontournable, la plupart des tâches peuvent être déléguées au client, ce qui améliore la stabilité et l'évolutivité du système dans la mesure où chaque utilisateur exécute la tâche dans son propre contexte, avec ses propres paramètres.

Pour plus d'informations sur ces rubriques et pour consulter des exemples de leur implémentation, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft. Si votre activité nécessite la création côté serveur de fichiers Office binaires, il existe des fournisseurs tiers proposant des composants qui peuvent vous aider. La liste ci-dessous répertorie certains fournisseurs réputés offrant ces services. La liste n'est fournie qu'à titre indicatif. Elle n'est pas exclusive. Il se peut que d'autres fournisseurs assurent des services similaires mieux adaptés à vos besoins. Vous devez examiner toutes les solutions tierces disponibles afin de choisir le fournisseur qui répond le mieux aux impératifs de votre activité. Les fournisseurs ci-dessous proposent certaines solutions qui autorisent la création et la modification par programme de formats de fichiers Office natifs. Pour plus d'informations (en anglais) sur les fournisseurs tiers, reportez-vous à leurs sites Web aux adresses suivantes :

Aia Software B.V.Polar SoftArtisans SyncFusion Keylogix Les produits tiers mentionnés dans le présent article proviennent de sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

Retour au début

Configuration d'Office pour une exécution côté serveur

Si aucune autre solution ne convient et que vous décidez de procéder à l'automatisation d'Office côté serveur, vous devez résoudre une grande partie des problèmes répertoriés plus haut pour mener à bien l'exécution dans ce type d'environnement. La plupart des problèmes étant liés à la configuration, il est impossible de fournir un ensemble de procédures qui permettraient à l'automatisation d'Office de fonctionner côté serveur dans toutes les situations et sur tous les systèmes. Certains paramètres de configuration peuvent entrer en conflit avec d'autres options et chaque approche présente des avantages et des inconvénients. Vous devrez peut-être procéder à des essais pour rechercher la configuration la plus adaptée à votre environnement.

Pour automatiser Office à partir d'un code côté serveur, vous devez généralement procéder comme suit :

?	Concevoir votre projet de manière à isoler et encapsuler Office.
?	Coder votre projet pour prévoir les problèmes et tenter de les résoudre de façon dynamique.
?	Attribuer à votre projet une identité et un profil utilisateur spécifiques destinés à Office.

La conception de votre projet doit tenir compte des problèmes de sécurité côté serveur et de non-réentrance des produits Office lorsque vous tentez d'exécuter l'automatisation d'Office. Limitez l'utilisation d'Office à une instance spécifique, contrôlée par un objet de sérialisation (un mutex ou une primitive de verrouillage personnalisée), ou regroupez un jeu d'instances étroitement contrôlé à partir d'un gestionnaire d'objets personnalisés (broker) pouvant créer des objets d'application si nécessaire, mais contrôlant les aspects du processus qui requièrent une sérialisation. Office peut adopter un certain nombre d'états. Par conséquent, l'exécution simultanée de certaines opérations (démarrage, arrêt, impression, etc.) par plusieurs clients risque de provoquer un conflit et éventuellement de bloquer un ou plusieurs threads appelants en affichant un message d'erreur qui invite l'utilisateur à fournir des informations ou en refusant de libérer une ressource globale utilisée par toutes les instances.

La première étape consiste donc à limiter l'utilisation de l'automatisation d'Office dans votre conception côté serveur et à isoler le processus sur un ordinateur ne contenant aucune donnée vitale et pouvant être redémarré le cas échéant. Isolez également le contexte appelant, de sorte que le blocage d'un client appelant n'affaiblisse pas les performances d'un service essentiel du système. Par exemple, n'effectuez pas l'automatisation directement à partir des services Internet (IIS) à l'aide d'un thread système ; isolez plutôt le code pour qu'il s'exécute sur son propre thread. Ainsi, en cas d'échec, il n'affecte pas les fonctionnalités globales des services Internet. Par ailleurs, réfléchissez à la manière dont votre conception met en oeuvre la sécurité et l'authentification. Étant donné qu'Office n'assure pas la sécurité côté serveur, votre code doit garantir que seuls les modules de code « approuvés » tels que les pages ASP, les fichiers de script etc. peuvent créer une instance d'automatisation d'une application Office et appeler ses méthodes. Le code doit également s'assurer que tous les documents sont sécurisés avant que vous ne demandiez à Office de les ouvrir. Les applications Office installées sur un serveur doivent toujours être exécutées avec un niveau élevé de sécurité. Si votre conception ne garantit pas la sécurité, vous faites courir des risques à votre serveur !

Lorsque la conception est en place, vous devez créer des codes défensifs pour tenter de prévenir l'apparition de problèmes et gérer les erreurs lorsqu'elles se présentent. Vérifiez que votre code passe des valeurs pour les paramètres facultatifs, car des valeurs manquantes ou contradictoires peuvent parfois obliger Office à demander à l'utilisateur de lui fournir d'autres informations. Utilisez la récupération d'erreur pour traiter progressivement les anomalies et consignez-les à l'aide d'un code de journalisation pouvant être activé ou désactivé par un paramètre personnalisé (dans le Registre ou le fichier INI). Si vous exécutez une action susceptible de provoquer l'affichage d'une boîte de dialogue d'erreur indépendante d'Office (par exemple, le pilote d'imprimante peut afficher une boîte de dialogue si l'imprimante manque de papier), soyez prêt à gérer d'éventuels blocages en recourant à un délai d'attente ou à un deuxième thread afin de contrôler la progression. Pour plus d'informations, reportez-vous à l'article suivant dans la Base de connaissances Microsoft : Utilisez votre code de journalisation pour rechercher les problèmes et déboguer votre programme. Si vous utilisez un pool d'objets personnalisés, vous pouvez ajouter des tests de performance et d'évolutivité afin de contrôler les problèmes d'usage et enregistrer les problèmes qui affectent tous les clients. Un contrôleur central peut également vous permettre de fermer les instances errantes d'Office et, le cas échéant, de les recréer pour renforcer la stabilité globale.

Lorsque le programme est prêt à être déployé, vérifiez qu'Office est configuré correctement sur le serveur pour pouvoir exécuter un contexte utilisateur approprié. Office nécessitant un profil utilisateur, pour exécuter l'automatisation vous devez inclure un profil lors du chargement. Pour ce faire, vous disposez de trois options dans un environnement côté serveur :

?	Configurez toutes les instances de l'application Office démarrée par l'automatisation afin qu'elles s'exécutent en tant qu'utilisateur interactif.
?	Configurez toutes les instances de l'application Office démarrée par l'automatisation afin qu'elles s'exécutent en tant qu'utilisateur spécifique.
?	Configurez votre code afin qu'il s'exécute en tant qu'utilisateur spécifique en utilisant un package MTS/COM+ et en permettant à l'application Office d'hériter de l'identité de l'utilisateur qui lance l'application.

La première option offre à Office à la fois l'identité et l'interactivité avec un Bureau spécifique et constitue l'option de choix lors du débogage (car Office peut être rendu visible et toutes les boîtes de dialogue ou erreurs de protection générale peuvent être affichées et enregistrées par l'utilisateur connecté localement). Toutefois, elle oblige l'utilisateur interactif à rester connecté pour fonctionner correctement. Cette solution peut donc ne pas être adaptée à certaines situations. Pour plus d'informations, reportez-vous à l'article suivant dans la Base de connaissances Microsoft : La deuxième option attribue un utilisateur spécifique, mais ne permet pas l'interactivité. Office démarre en tant qu'utilisateur assigné dans une nouvelle station Windows sur un Bureau invisible. Cette option nécessite des procédures de configuration supplémentaires pour garantir le chargement de la ruche du Registre utilisateur, car COM/DCOM ne s'en charge pas par défaut. Le paramètre s'applique à l'ensemble du système et peut donc entrer en conflit avec d'autres programmes. Pour plus d'informations sur ce mode de configuration d'Office, reportez-vous à l'article suivant dans la Base de connaissances de Microsoft : La troisième option vous permet d'attribuer une identité à un site Web ou à un module de code spécifique et vous évite de définir une identité fixe globale pour Office. Office s'exécute sous cette identité et se charge correctement si l'identité a été préalablement configurée pour cet ordinateur et que la ruche du Registre a été chargée. Cette option est généralement la plus souple et la plus sécurisée mais, comme l'option précédente, elle n'offre pas l'interactivité par le biais d'un Bureau visible et requiert une configuration complémentaire. Pour plus d'informations sur ce mode de configuration d'Office, reportez-vous à l'article suivant dans la Base de connaissances de Microsoft : Vous devez évaluer laquelle des options ci-dessus est adaptée à vos besoins et réfléchir à la meilleure méthode pour déployer votre solution. Nous ne pouvons pas garantir que les informations présentées ici pourront résoudre tous les problèmes pour tous les clients. Nous vous encourageons à procéder à des tests approfondis avant de commencer le déploiement.

Retour au début

Pour plus d'informations sur l'automatisation côté serveur, reportez-vous aux articles suivants dans la Base de connaissances Microsoft :

Retour au début