Überlegungen zur unbeaufsichtigten Automatisierung von Office in der Microsoft 365 für die unbeaufsichtigte RPA-Umgebung

  • Artikel

Obwohl Microsoft 365 für unbeaufsichtigte RPA eine Lizenz bereitstellt, die die Automatisierung von Office ohne anwesende Benutzer ermöglicht, wurden alle aktuellen Versionen von Office so entworfen und getestet, dass sie als Endbenutzerprodukte auf einer Clientarbeitsstation ausgeführt werden, bei der ein Benutzer anwesend ist, um mit der Benutzeroberfläche der Anwendung zu interagieren. Unerwartete Verhaltensweisen, die sich aus der Verwendung von Anwendungen ergeben, ohne dass ein Benutzer anwesend ist, sind keine Mängel. Wenn Sie Office in dieser Konfiguration ausführen möchten, müssen Sie darauf vorbereitet sein, diese unerwarteten Verhaltensweisen in Ihrer Anwendungslogik zu berücksichtigen.

In diesem Artikel werden einige der Überlegungen zur unbeaufsichtigten Automatisierung von Office beschrieben, die Ihnen bei diesem Ansatz helfen. Beachten Sie jedoch, dass die Verwendung von Office in dieser Konfiguration ausschließlich "WIE bemerkt" ist und diese unerwarteten Verhaltensweisen berücksichtigen muss. Die hier bereitgestellten Informationen sind nicht vollständig und können nicht garantiert alle Probleme für alle Clients beheben. Wir empfehlen Ihnen, Ihre Lösung vor der Bereitstellung gründlich zu testen.

Häufige Probleme bei der unbeaufsichtigten Automatisierung

Wenn Sie Office verwenden möchten, ohne dass ein Benutzer anwesend ist, beachten Sie die folgenden Bereiche, in denen sich Office anders als erwartet verhalten kann. Damit Ihre Lösung erfolgreich ausgeführt werden kann, muss sie diese Probleme beheben und deren Auswirkungen so weit wie möglich minimieren. Berücksichtigen Sie diese Probleme sorgfältig, wenn Sie Ihre Anwendung erstellen.

Wichtig

Microsoft empfiehlt derzeit keine Automatisierung von Microsoft Office-Anwendungen von unbeaufsichtigten, nicht interaktiven Clientanwendungen oder -komponenten (einschließlich ASP-, ASP.NET-, DCOM- und NT-Diensten), da Office möglicherweise ein instabiles Verhalten und/oder Deadlock aufweist, wenn Office in dieser Umgebung ausgeführt wird. Weitere Informationen finden Sie unter Überlegungen zur serverseitigen Automatisierung von Office.

Interaktive Ui-Elemente

Office-Anwendungen gehen davon aus, dass sie interaktiv ausgeführt werden. Wenn ein unerwarteter Fehler auftritt oder ein nicht angegebener Parameter erforderlich ist, um eine Funktion abzuschließen, ist Office so konzipiert, dass der Benutzer mit einem Dialogfeld aufgefordert wird, in dem der Benutzer gefragt wird, wie er fortfahren möchte. Bei der unbeaufsichtigten Automatisierung kann dies dazu führen, dass die Anwendung "hängen bleibt", wenn die Anwendung angehalten wird, bis sie diese Eingabe empfängt. Wenn Sie Office über die öffentlichen APIs automatisieren, können Sie viele dieser Warnungen unterdrücken, indem Sie Eigenschaften wie Application.DisplayAlerts und Application.AutomationSecurity entsprechend konfigurieren. Ihr Code sollte so konzipiert sein, dass er Blockierungswarnungen jederzeit identifiziert und verarbeitet.

Benutzeridentität

Office-Anwendungen erfordern eine Benutzeridentität, wenn die Anwendungen ausgeführt werden, auch wenn die Anwendung über Automatisierung gestartet wird. Diese Benutzeridentität kann eine oder alle der folgenden Ursachen verursachen:

  • Das Vorhandensein einer zusätzlichen Anmeldebenutzeroberfläche, die behandelt werden muss.
  • Dateien, die nicht geöffnet und/oder bearbeitet werden können, basierend auf Benutzerzugriffsberechtigungen.
  • Unerwartete Änderungen an den Metadaten der Datei (z. B. werden bestimmte Dateieigenschaften basierend auf der Identität der Benutzeridentität der automatisierten Anwendung instance aktualisiert).

Verschiedene Ansätze können dazu beitragen, diese Probleme zu entschärfen. Beispiel: Ausführen der Dokumentprüfung zum Entfernen von Metadaten. Überlegen Sie, ob diese Ansätze basierend auf Ihrem Szenario geeignet sind.

Serverseitige Sicherheit

Wenn Sie Office unbeaufsichtigt ausführen und beliebige Dateiinhalte verarbeiten, sind keine zusätzlichen Schutzmechanismen verfügbar, die in dieser Umgebung spezifisch sind, um zu verhindern, dass in diesen Dateien gespeicherte Makros geladen und ausgeführt werden. Office schützt Sie nicht vor unbeabsichtigter Ausführung von Makros aus Ihrem Code oder vor dem Starten eines anderen Servers, auf dem Makros ausgeführt werden könnten. Sie können Eigenschaften wie Application.AutomationSecurity verwenden, um dieses Risiko zu minimieren, aber Sie sollten sicherstellen, dass Sie nur vertrauenswürdige Inhalte laden.

Darüber hinaus verwendet Office viele Komponenten (z. B. Einfache MAPI, WinInet und MSDAIPP), die Clientauthentifizierungsinformationen zwischenspeichern können, um die Verarbeitung zu beschleunigen. Wenn Office serverseitig automatisiert wird und mehrere Dateien verarbeitet und Authentifizierungsinformationen für diese Sitzung zwischengespeichert wurden, kann ein Client die zwischengespeicherten Anmeldeinformationen eines anderen Clients verwenden. Daher kann der Client nicht gewährte Zugriffsberechtigungen erhalten, indem er die Identität anderer Benutzer angibt.

Änderungen an der Benutzeroberfläche

Die Benutzeroberflächenelemente in Office sind weitgehend stabil, aber die spezifische Position eines BELIEBIGEN UI-Elements ist nicht garantiert und kann sich ändern, wenn sich das Produktdesign weiterentwickelt, um Benutzerfeedback zu integrieren und die Kundenanforderungen zu erfüllen. Die Logik jeder Automatisierung muss dies berücksichtigen. Diese Änderungen können zu Änderungen bei der Benennung von Schaltflächen oder Gruppenregisterkarten, zum Verschieben von Befehlen zwischen Registerkarten, zum Hinzufügen neuer Registerkarten oder zum Entfernen von Befehlen in Übereinstimmung mit unseren Funktionsveraltungsrichtlinien führen. Diese Änderungen können sowohl auf der Benutzeroberfläche als auch in den von der Anwendung bereitgestellten Barrierefreiheitsinformationen vorgenommen werden, da diese Informationen geändert werden, um die Benutzerfreundlichkeit zu verbessern und fortlaufendes Kundenfeedback zu berücksichtigen, und sie können für verschiedene Benutzer zu unterschiedlichen Zeiten eingeführt werden.

Auch ohne Produktänderungen können Unterschiede zwischen Systemumgebungen (z. B. Bildschirmgröße/Auflösung/DPI) zu Änderungen an der Position der Elemente auf dem Bildschirm führen. Jeder Ansatz, der auf Bildschirmkoordinaten basiert, um Benutzereingaben zu simulieren, muss diese Änderungen berücksichtigen und sich entsprechend anpassen.

Singlethreading

Office-Anwendungen sind nicht reentrant, STA-basierte Anwendungen, die so konzipiert sind, dass sie vielfältige, aber ressourcenintensive Funktionen für einen einzelnen Client bereitstellen. Die Anwendungen verwenden globale Ressourcen wie speicherabbildete Dateien, globale Add-Ins oder Vorlagen und freigegebene Automatisierungsserver. Dies kann die Anzahl der Instanzen begrenzen, die gleichzeitig ausgeführt werden können, und zu Racebedingungen führen, wenn die Anwendungen in einer Umgebung mit mehreren Clients konfiguriert sind. Wenn Sie planen, mehr als eine instance einer Office-Anwendung auszuführen, sollten Sie planen, diese auf der Ebene des virtuellen Computers zu isolieren, um die Stabilität der resultierenden Lösung sicherzustellen.

Resilienz und Stabilität

Selbst wenn die Anwendungen so automatisiert sind, dass Benutzereingaben simuliert werden, oder sitzungslängen, die die interaktive Nutzung erheblich überschreiten, können probleme auftreten, die bei der interaktiven Ausführung nicht vorhanden sind. Lösungen, die Office in diesem Kontext verwenden, sollten proaktiv Mechanismen erstellen, um den Zustand der Anwendung zu überwachen und diese (und/oder den virtuellen Computer, auf dem sie ausgeführt werden) bei Bedarf neu zu starten.

Vorgeschlagene Alternativen

Microsoft empfiehlt dringend einige Alternativen, für die office nicht installiert und serverseitig ausgeführt werden muss und die allgemeine Aufgaben effizienter und schneller ausführen können als die Automatisierung in dieser Konfiguration. Bevor Sie Office als serverseitige Komponente in Ihr Projekt einbeziehen, sollten Sie Alternativen in Betracht ziehen.

Microsoft Graph

Die Microsoft Graph-API bietet Zugriff auf die Dienste, Daten und Informationen, die Benutzern und Lösungen als Teil der Microsoft-Cloud zur Verfügung stehen, einschließlich vieler Dienste, die die Anforderungen der unbeaufsichtigten Automatisierung unterstützen: Zugriff auf E-Mails/ Kalender/Kontakte/Dateien der Benutzer, Dokumentkonvertierung, Excel-Arbeitsmappenberechnung und vieles mehr. Diese Dienste sind für die unbeaufsichtigte Verwendung und den zugriff mit hoher Skalierung konzipiert und verwenden eine standardmäßige RESTful-API-Syntax. Weitere Informationen zu Microsoft Graph und zur Verwendung von Microsoft Graph zum Arbeiten mit Benutzerdaten finden Sie in den folgenden Themen:

Open XML-Dateiformate

Viele Automatisierungsaufgaben umfassen die Dokumenterstellung oder -bearbeitung. Office unterstützt Open XML-Dateiformate, mit denen Entwickler Dateiinhalte mithilfe von XML- und ZIP-Standardtechnologien erstellen, bearbeiten, lesen und transformieren können, die im internationalen Iso 29500-Standard definiert sind. Diese Dateiformate können über beliebige ZIP/XML-Tools bearbeitet werden, einschließlich des System.IO.Package.IO Namespace in Microsoft .NET 3.x Framework. Die direkte Bearbeitung der Dateiformate ist die empfohlene und unterstützte Methode zum Verarbeiten von Änderungen an Office-Dateien von einem Dienst.

Microsoft bietet ein SDK zum Bearbeiten von Open XML-Dateiformaten aus .NET 3.x Framework. Weitere Informationen zum SDK und zur Verwendung des SDK zum Erstellen oder Bearbeiten von Open XML-Dateien finden Sie unter den folgenden Themen: