Partager via

Considérations relatives à l’automatisation sans assistance d’Office dans Microsoft 365 pour l’environnement RPA sans assistance

  • Article

Bien que Microsoft 365 pour RPA sans assistance fournisse une licence qui permet l’automatisation d’Office sans utilisateur présent, toutes les versions actuelles d’Office ont été conçues et testées pour s’exécuter en tant que produits d’utilisateur final sur une station de travail cliente avec un utilisateur présent pour interagir avec l’interface de l’application. Les comportements inattendus résultant de l’utilisation d’applications sans présence d’un utilisateur ne sont pas des défauts. Si vous souhaitez exécuter Office dans cette configuration, vous devez être prêt à prendre en compte ces comportements inattendus dans votre logique d’application.

Cet article décrit certaines des considérations relatives à l’automatisation sans assistance d’Office pour vous aider si vous utilisez cette approche. Toutefois, notez que l’utilisation d’Office dans cette configuration est strictement « TELLE QUELLE » et doit tenir compte de ces comportements inattendus. Les informations fournies ici ne sont pas exhaustives et ne sont pas garanties pour résoudre tous les problèmes pour tous les clients. Nous vous encourageons à tester minutieusement votre solution avant de la déployer.

Problèmes courants liés à l’automatisation sans assistance

Si vous souhaitez utiliser Office sans qu’un utilisateur soit présent, tenez compte des domaines suivants dans lesquels Office peut se comporter différemment que prévu. Pour que votre solution s’exécute correctement, elle doit résoudre ces problèmes et réduire autant que possible leurs effets. Tenez compte de ces problèmes avec soin lorsque vous générez votre application.

Importante

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. Pour plus d’informations, consultez Considérations relatives à l’automatisation côté serveur d’Office.

Éléments d’interface utilisateur interactive

Les applications Office supposent qu’elles sont exécutées de manière interactive. 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 qui demande à l’utilisateur comment procéder. Dans l’automatisation sans assistance, l’application peut apparaître comme « bloquée » lorsque l’application s’arrête jusqu’à ce qu’elle reçoive cette entrée. Si vous automatisez Office via ses API publiques, vous pouvez supprimer un grand nombre de ces alertes en configurant correctement des propriétés telles que Application.DisplayAlerts et Application.AutomationSecurity . Votre code doit être conçu pour identifier et traiter les alertes bloquantes à tout moment.

Identité de l’utilisateur

Les applications Office nécessitent une identité d’utilisateur lors de l’exécution des applications, même lorsque l’application est démarrée via l’automatisation. Cette identité d’utilisateur peut provoquer tout ou partie des éléments suivants :

  • Présence d’une interface utilisateur de connexion supplémentaire qui doit être gérée.
  • Fichiers qui ne peuvent pas être ouverts et/ou modifiés en fonction des autorisations d’accès par utilisateur.
  • Modifications inattendues apportées aux métadonnées du fichier (par exemple, certaines propriétés du fichier seront mises à jour en fonction de l’identité de l’utilisateur de l’application automatisée instance).

Différentes approches peuvent aider à atténuer ces problèmes ; par exemple, l’exécution de l’inspecteur de document pour supprimer les métadonnées. Déterminez si ces approches sont appropriées en fonction de votre scénario.

Sécurité côté serveur

Lors de l’exécution d’Office sans assistance et du traitement de contenu de fichier arbitraire, aucune protection supplémentaire spécifique à cet environnement n’est disponible pour empêcher le chargement et l’exécution des macros stockées dans ces fichiers. Office ne vous protège pas contre l’exécution involontaire de macros à partir de votre code, ni contre le démarrage d’un autre serveur susceptible d’exécuter des macros. Vous pouvez utiliser des propriétés telles que Application.AutomationSecurity pour atténuer ce risque, mais vous devez vous assurer que vous chargez uniquement du contenu approuvé.

En outre, Office utilise de nombreux composants (tels que MAPI simple, WinInet et MSDAIPP) qui peuvent mettre en cache les informations d’authentification du client pour accélérer le traitement. Quand Office est automatisé côté serveur et traite plusieurs fichiers, 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.

Modifications apportées à l’interface utilisateur

Les éléments d’interface utilisateur dans Office sont en grande partie stables, mais l’emplacement spécifique d’un élément d’interface utilisateur n’est pas garanti et peut changer à mesure que la conception du produit évolue pour incorporer les commentaires des utilisateurs et répondre aux besoins des clients. La logique de toute automatisation doit tenir compte de cela. Ces modifications peuvent entraîner des modifications de nommage des onglets de bouton ou de groupe, le déplacement des commandes entre les onglets, l’ajout de nouveaux onglets ou la suppression de commandes en alignement avec nos stratégies de dépréciation des fonctionnalités. Ces modifications peuvent avoir lieu dans l’interface utilisateur ainsi que dans les informations d’accessibilité fournies par l’application, car ces informations sont modifiées pour améliorer la facilité d’utilisation et tenir compte des commentaires continus des clients, et peuvent être déployées pour différents utilisateurs à des moments différents.

Même sans modification du produit, les différences entre les environnements système (comme la taille/la résolution/la résolution de l’écran) peuvent entraîner des changements dans l’emplacement des éléments à l’écran. Toute approche qui s’appuie sur des coordonnées d’écran pour simuler l’entrée utilisateur doit prendre en compte ces modifications et s’adapter en conséquence.

Monothreading

Les applications Office sont des applications non réentrantes, basées sur STA, conçues pour fournir des fonctionnalités diverses mais gourmandes en ressources pour un seul client. Les applications utilisent des ressources globales telles que des fichiers mappés en mémoire, des compléments ou modèles globaux et des serveurs d’automatisation partagés. Cela peut limiter le nombre d’instances qui peuvent s’exécuter simultanément et peut entraîner des conditions de concurrence si les applications sont configurées dans un environnement multiclient. Si vous envisagez d’exécuter plusieurs instance d’une application Office, vous devez prévoir de les isoler au niveau de la machine virtuelle pour garantir la stabilité de la solution obtenue.

Résilience et stabilité

Même avec les considérations ci-dessus, si les applications sont automatisées de manière à simuler une entrée utilisateur ou pour des durées de session qui dépassent considérablement l’utilisation interactive, elles peuvent rencontrer des problèmes qui ne sont pas présents lors de l’exécution interactive. Les solutions qui utilisent Office dans ce contexte doivent créer de manière proactive des mécanismes pour surveiller l’état de l’application et les redémarrer (et/ou la machine virtuelle sur laquelle elles s’exécutent) si nécessaire.

Alternatives suggérées

Microsoft recommande vivement quelques alternatives qui ne nécessitent pas l’installation et l’exécution d’Office côté serveur, et qui peuvent effectuer des tâches courantes plus efficacement et plus rapidement que l’automatisation dans cette configuration. Avant d’impliquer Office en tant que composant côté serveur dans votre projet, envisagez d’autres solutions.

Microsoft Graph

Microsoft API Graph fournit l’accès aux services, aux données et aux informations disponibles pour les utilisateurs et les solutions dans le cadre du cloud Microsoft, y compris de nombreux services prenant en charge les besoins de l’automatisation sans assistance : accès aux messages/ calendriers / contacts / fichiers des utilisateurs, conversion de documents, calcul de classeur Excel, etc. Ces services sont conçus pour une utilisation sans assistance et un accès à grande échelle, et utilisent une syntaxe d’API RESTful standard. Pour plus d’informations sur Microsoft Graph et sur la façon de l’utiliser pour utiliser les données des utilisateurs, consultez les pages suivantes :

Formats de fichier Open XML

De nombreuses tâches d’automatisation impliquent la création ou la modification de documents. Office prend en charge les formats de fichiers Open XML qui permettent aux développeurs de créer, modifier, lire et transformer du contenu de fichier à l’aide des technologies XML et ZIP standard, définies dans la Norme internationale ISO 29500. Ces formats de fichier peuvent être manipulés via n’importe quel outil ZIP/XML, y compris l’espace de noms System.IO.Package.IO dans Microsoft .NET 3.x Framework. La modification directe des formats de fichiers est la méthode recommandée et prise en charge pour gérer les modifications apportées aux fichiers Office à partir d’un service.

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 Kit de développement logiciel (SDK) et sur la façon d’utiliser le Kit de développement logiciel (SDK) pour créer ou modifier des fichiers Open XML, consultez les rubriques suivantes :