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. Bien que ce développement programmatique puisse être implémenté sur un système client avec une relative facilité, un certain nombre de complications peuvent se produire si Automation a lieu à partir de code côté serveur, tel que Microsoft Active Server Pages (ASP), 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, les composants Redistribuable du moteur de base de données Access et Access Runtime sont considérés comme des composants 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 s’exécuter en tant que produits d’utilisateur final sur une station de travail cliente. Ils supposent un bureau interactif et un profil utilisateur. Ils ne fournissent pas le niveau de réentrance ou de sécurité nécessaire pour répondre aux besoins des composants côté serveur conçus pour s’exécuter sans assistance.
Actuellement, 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 sans assistance et non interactif (y compris ASP, ASP.NET, DCOM et NT Services), car Office peut présenter un comportement instable et/ou un blocage lorsque Office est exécuté dans cet environnement.
Si vous créez une solution qui s’exécute dans un contexte côté serveur, vous devez essayer d’utiliser des composants qui ont été sécurisés pour une exécution sans assistance. Vous devez également essayer de trouver des alternatives qui permettent au moins une partie du code d’exécuter côté client. Si vous utilisez une application Office à partir d’une solution côté serveur, l’application n’aura pas la plupart des fonctionnalités nécessaires pour s’exécuter correctement. En outre, vous prendrez des risques avec la stabilité de votre solution globale.
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 : les applications Office supposent qu’elles sont exécutées sous un bureau interactif. Dans certains cas, il peut être nécessaire de rendre les applications visibles pour que certaines fonctions Automation fonctionnent correctement. Si une erreur inattendue se produit ou si un paramètre non spécifié est nécessaire pour terminer une fonction, Office est conçu pour inviter l’utilisateur à entrer une boîte de dialogue modale qui lui demande ce qu’il souhaite faire. Une boîte de dialogue modale sur un bureau non interactif ne peut pas être ignorée. Par conséquent, ce thread cesse de répondre (se bloque) indéfiniment. Bien que certaines pratiques de codage puissent aider à réduire la probabilité de ce problème, ces pratiques ne peuvent pas empêcher entièrement le problème. Ce seul fait rend l’exécution d’applications Office à partir d’un environnement côté serveur 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 Microsoft Windows Installer (MSI) pour faciliter l’installation et la réparation automatique pour un utilisateur final. MSI introduit le concept d’installation lors de la première utilisation. Cela permet aux fonctionnalités d’être installées ou configurées dynamiquement au moment de l’exécution pour le système, ou plus souvent pour un utilisateur particulier. Dans un environnement côté serveur, cela ralentit les performances et augmente la probabilité qu’une boîte de dialogue demande à l’utilisateur d’approuver l’installation ou de fournir un disque d’installation. Bien que ce soit conçu pour augmenter la résilience d’Office en tant que produit utilisateur final, l’implémentation des fonctionnalités MSI par Office est contre-productive dans un environnement côté serveur. En outre, la stabilité d’Office en général ne peut pas être assurée quand Office est exécuté côté serveur, car il n’a pas été conçu ou testé pour ce type d’utilisation. L’utilisation du composant Office en tant que service sur un serveur réseau peut réduire la stabilité de cet ordinateur et, par conséquent, la stabilité de l’ensemble de votre réseau.
-
Sécurité côté serveur : les applications Office n’ont jamais été conçues pour une utilisation côté serveur. Par conséquent, les applications Office ne prennent pas en compte les problèmes de sécurité auxquels les composants distribués sont confrontés. Office n’authentifie pas les demandes entrantes. Office ne vous protège pas non plus contre l’exécution involontaire de macros ou le démarrage d’un autre serveur susceptible d’exécuter des macros à partir de votre code côté serveur. N’ouvrez pas les fichiers chargés sur le serveur à partir d’un site Web anonyme. En fonction des paramètres de sécurité qui ont été définis pour la dernière fois, le serveur peut exécuter des macros sous un contexte Administrateur ou Système avec des privilèges complets et peut donc compromettre votre réseau. En outre, Office utilise de nombreux composants côté client (tels que SIMPLE MAPI, WinInet et MSDAIPP) qui peuvent mettre en cache les informations d’authentification client pour accélérer le traitement. Si Office est automatisé côté serveur, un instance peut traiter plusieurs clients. Si les informations d’authentification ont été 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 obtenir des autorisations d’accès non accordées en empruntant l’identité d’autres utilisateurs.
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 d’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, vous recevez l’un des messages d’erreur suivants.
Message 1
Erreur d’exécution « 5981 » (0x800A175D) : Impossible d’ouvrir le stockage de macros
Message 2
Erreur d’exécution « 1004 » : échec de la méthode « ~ » de l’objet « ~ »
-
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 en plus de ceux répertoriés ici, mais ces problèmes se produisent généralement en raison des cinq problèmes main 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 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 Automation 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 fichier Open XML sont une norme publique.
Microsoft fournit un KIT de développement logiciel (SDK) pour manipuler les formats de fichiers Open XML à partir du .NET 3.x Framework. 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 :
Documentation du Kit de développement logiciel (SDK) Open XML
Guide pratique pour manipuler des documents au format Open XML Office
Manipulation de fichiers Word 2007 avec le modèle objet Open XML (partie 1 sur 3)
Manipulation de fichiers Word 2007 avec le modèle objet Open XML (partie 2 sur 3)
Manipulation de fichiers Word 2007 avec le modèle objet Open XML (partie 3 sur 3)
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 :
Types MIME au format de fichier Office 2007 pour la diffusion en continu de contenu HTTP
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 obtenir des exemples qui montrent comment les implémenter, cliquez sur les numéros d’article suivants pour afficher les articles de la Base de connaissances Microsoft :
198703 Comment automatiser Excel à partir d’un script VBScript côté client
Comment interroger et mettre à jour des données Excel à l’aide d’ADO à partir d’ASP
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, puis à demander au serveur de les afficher sur le web ou sur d’autres supports. Microsoft travaille actuellement à proposer de telles fonctionnalités et fournit une version préliminaire de cette fonctionnalité dans Microsoft Excel Services.
Excel Services est une nouvelle technologie de serveur incluse dans Microsoft Office SharePoint Server 2007 et qui vous permet de charger, de calculer et d’afficher des classeurs Excel sur Office SharePoint Server 2007. Pour plus d’informations sur Excel Services, reportez-vous aux sites web MSDN (Microsoft Developer Network) aux adresses suivantes :
Vue d’ensemble de Excel Services
Procédure pas à pas : développement d’une application personnalisée à l’aide d’Excel Web Services
Création d’applications métier à l’aide des formats Excel Services et Office Open XML 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.
Vue d’ensemble de Word Automation Services
Présentation de Word Automation Services 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.
