Considérations sur l’automatisation côté serveur de Microsoft Office

S’applique à : Produits OfficeAccess 2010Excel 2010

Résumé


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), ASP.NET, DCOM ou un service Windows NT.

Cet article décrit les complications auxquelles les développeurs peuvent être confrontés. L’article propose également des méthodes alternatives à l’automatisation qui permettent d’améliorer les performances. Toutefois, les développeurs doivent savoir que les suggestions présentées dans cet article 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 pilote système Microsoft Office 2007 et le moteur de base de données Access 2010 sont considérés comme des composants de Microsoft Office. Le terme « côté serveur » s’applique également à un code exécuté sur une station de travail Microsoft, à condition que celle-ci 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 « côté serveur » ou DCOM. Par conséquent, de nombreux problèmes décrits dans cet article peuvent se produire. Pour plus d’informations sur les stations de travail Windows et sur COM, reportez-vous aux sections « Informations supplémentaires » et « Références ».

Informations supplémentaires


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, ASP.NET, 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 exécutée dans un contexte côté serveur, essayez d’utiliser des composants approuvés pour une exécution sans assistance. Sinon, recherchez d’autres méthodes permettant d’exécuter au moins une partie du code côté serveur. Si vous utilisez une application Office à partir d’une solution côté serveur, de nombreuses fonctionnalités nécessaires à son exécution ne seront pas présentes. En outre, la stabilité de la solution globale sera menacée.

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

Les développeurs qui tentent d’utiliser Office dans une solution côté serveur doivent tenir compte de cinq domaines majeurs dans lesquels l’environnement entraîne un comportement imprévu d’Office. Si vous souhaitez exécuter votre code sans problème, vous devez résoudre ces problèmes et minimiser leurs effets autant que possible. Soyez attentif à ces problèmes lorsque vous générez votre application. Une solution ne permet pas de résoudre tous les problèmes. Chaque conception nécessite un classement particulier des éléments par ordre de priorité.

  • 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. Les applications 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 dans des comptes ne possédant aucun profil utilisateur (comme le compte SYSTEM ou IWAM_[nom_serveur]). Par conséquent, Office risque de ne pas s’initialiser correctement au démarrage. Dans ce cas, Office renvoie une erreur pour la fonction CreateObject ou CoCreateInstance. Même si l’application Office peut être démarrée, d’autres fonctions risquent de ne pas fonctionner correctement s’il n’existe aucun profil utilisateur.
  • Interactivité avec le Bureau : L’exécution des applications Office nécessite un Bureau interactif. Dans certaines circonstances, les applications doivent être visibles pour que certaines fonctions d’automatisation puissent fonctionner correctement. En cas d’erreur inattendue ou lorsqu’un paramètre non spécifié est requis pour une fonction, Office invite 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éentrance et extensibilité : 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. Il s’agit de serveurs d’automatisation STA non réentrants conçus pour fournir différentes fonctionnalités, exigeantes en ressources, à un client unique. Les applications sont peu extensibles en tant que solution côté serveur. En outre, elles ont des limites fixes en ce qui concerne des éléments importants tels que la mémoire. Il est impossible de modifier ces limites dans la configuration. Plus important encore, les applications utilisent des ressources globales telles que les fichiers mappés en mémoire, les compléments ou modèles globaux et les serveurs d’automatisation partagés. Cet aspect peut limiter le nombre d’instances pouvant être exécutées simultanément et peut entraîner des conditions de concurrence si les applications sont configurées dans un environnement constitué de plusieurs clients. 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 d’altération 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 les fonctionnalités de manière dynamique lors de l’exécution pour le système ou plus fréquemment pour un utilisateur particulier. Dans un environnement côté serveur, MSI diminue les performances et augmente la probabilité d’affichage d’une boîte de dialogue invitant l’utilisateur à approuver l’installation ou à insérer un disque d’installation. 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 réduire la stabilité de l’ordinateur et, par conséquent, celle de l’ensemble du réseau.
  • Sécurité côté serveur : les applications Office ne sont pas conçues pour une utilisation côté serveur. Par conséquent, elles ne tiennent pas compte des problèmes de sécurité auxquels les composants distribués sont confronté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 Simple MAPI, WinInet et 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 instance peut couvrir plusieurs clients. Si les informations d’authentification sont mises en cache pour cette session, un client peut utiliser les informations d’identification mises en cache d’un autre client. Par conséquent, le client peut usurper l’identité d’autres utilisateurs pour obtenir des autorisations d’accès non octroyées.

Outre les problèmes d’ordre technique, vous devez également être attentif aux problèmes liés aux licences. 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 Contrat de Licence Utilisateur Final (CLUF).

En plus de ces problèmes, l’une des erreurs courantes suivantes peut se produire lorsque vous essayez d’automatiser Office côté serveur :

  • Les fonctions CreateObject et CoCreateInstance retournent l’un des messages d’erreur d’exécution suivants et ne peuvent pas être démarrées pour l’automatisation.
     
    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
    Message 3
    CO_E_SERVER_EXEC_FAILURE (0x80080005) : Échec de l’exécution du serveur
    Message 4
    E_ACCESSDENIED (0x80070005) : Accès refusé
  • Lorsque vous ouvrez un document Office, l’un des messages d’erreur suivants s’affiche :
     
    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é
  • Les fonctions CreateObject et CoCreateInstance cessent de répondre et ne se terminent pas ou accusent un délai de retour important. Sur certains serveurs, le processus de création est rapide, mais des erreurs 1004 apparaissent dans le journal des événements Windows pour signaler que l’application s’est arrêtée.
  • Certaines fonctions échouent de manière inattendue ou cessent de répondre pour une durée indéterminée en raison d’une alerte utilisateur ou d’une autre boîte de dialogue nécessitant l’attention de l’utilisateur.
  • L’exécution de plusieurs requêtes ou les tests de contrainte provoquent 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.

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 principaux répertoriés plus haut dans cet article. 

Méthodes alternatives à l’automatisation 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 vivement 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 ou la modification de documents. Office 2007 prend en charge les nouveaux formats de fichiers Open XML qui permettent aux développeurs de créer, modifier, lire et transformer le contenu des fichiers côté serveur. Ces formats de fichiers utilisent l’espace de noms System.IO.Package.IO dans Microsoft .NET Framework 3.x pour modifier les fichiers Office sans utiliser les applications clientes Office elles-mêmes. Il s’agit de la méthode recommandée et prise en charge pour la gestion des modifications apportées aux fichiers Office à partir d’un service.

Les formats de fichiers Open XML sont une norme publique. 


Microsoft fournit un Kit de développement logiciel (SDK) pour manipuler les formats de fichiers Open XML de .NET Framework 3.x. Pour plus d’informations sur le SDK et sur son utilisation pour créer ou modifier des fichiers Open XML, reportez-vous aux sites web de Microsoft Developer Network (MSDN) aux adresses suivantes :

Lorsque vous diffusez en continu des fichiers Open XML à partir d’ASP ou d’ASP.NET, vous devez fournir le type MIME (Multipurpose Internet Mail Extension) correct pour le contenu diffusé. Pour obtenir la liste des types MIME pour les fichiers Office 2007, reportez-vous au site web à l’adresse suivante :

Si vous ciblez des clients antérieurs à Office 2007 uniquement et ne souhaitez pas exiger l’utilisation du format Open XML dans la solution, vous pouvez utiliser d’autres formats de fichiers Office non binaires, comme HTML, XML et RTF. Vous pouvez diffuser ces fichiers en continu vers un client à l’aide d’un type MIME afin d’afficher le texte résultant dans Office. Le document peut être modifié, enregistré et même renvoyé au serveur en utilisant ASP sur le serveur.

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 :

198703 Comment automatiser Excel à partir d’un script VBScript côté client
278973 ExcelADO montre comment utiliser ADO pour lire et écrire des données dans des classeurs Excel
286023 Comment utiliser un composant ActiveX Visual Basic pour l’automatisation de Word à partir d’Internet Explorer
 

Si votre activité nécessite la création côté serveur de formats de fichiers binaires Office 97, Office 2000, Office XP et Office 2003, il existe des fournisseurs tiers proposant des composants qui peuvent vous aider. Étant donné que Microsoft ne fournit pas ces composants, vous devez créer une solution vous-même ou en acheter une auprès d’un fournisseur tiers. Il existe de nombreux produits tiers différents. Vous devez examiner chaque solution disponible afin de choisir le fournisseur qui répond le mieux aux impératifs de votre activité.

Si vous souhaitez créer votre propre solution pour modifier directement les formats de fichiers binaires Office 97, Office 2000, Office XP et Office 2003, vous pouvez vous procurer gratuitement les spécifications des formats de fichiers conformément aux conditions du programme Open Specification Promise (OSP) de Microsoft. Aucun support technique n’est disponible pour la documentation ou les produits que vous créez, mais de la documentation est disponible. 


Les solutions côté serveur peuvent également autoriser les utilisateurs à charger des fichiers que le serveur doit afficher sur le web ou sur d’autres supports. Microsoft développe actuellement des fonctionnalités de ce type et propose une version anticipée de cette fonctionnalité dans Microsoft Excel Services.

Excel Services est une nouvelle technologie serveur intégrée dans Microsoft Office SharePoint Server 2007 qui permet de charger, de calculer et d’afficher des classeurs Excel dans Office SharePoint Server 2007. Pour plus d’informations sur Excel Services, reportez-vous aux sites web MSDN (Microsoft Developer Network) aux adresses suivantes :

Word Automation Services est une nouvelle application de service intégrée à SharePoint Server 2010. Word Automation Services fournit une conversion de documents sans assistance côté serveur dans des formats pris en charge par l’application cliente Microsoft Word.Vous devez évaluer laquelle des options présentées dans cet article 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 dans cet article pourront résoudre tous les problèmes pour tous les clients. Nous vous encourageons à procéder à des tests approfondis de votre solution avant de la déployer.