Was bei der serverseitigen Automatisierung von Office zu beachten ist

Gilt für: Office ProductsAccess 2010Excel 2010

Zusammenfassung


Entwickler können die Automatisierungsfunktion in Microsoft Office einsetzen, um benutzerdefinierte Lösungen zu erstellen, bei denen die Möglichkeiten und Features des jeweiligen Office-Produkts bestmöglich genutzt werden. Eine solche programmgesteuerte Entwicklung kann relativ einfach auf einem Clientsystem implementiert werden. Dennoch können diverse Komplikationen auftreten, wenn die Automatisierung über serverseitigen Code erfolgt, wie zum Beispiel Microsoft Active Server Pages (ASP), ASP.NET, DCOM oder einen Windows NT-Dienst.

In diesem Artikel werden die Komplikationen erläutert, mit denen Entwickler konfrontiert sein können. Darüber hinaus werden Alternativen zur Automatisierung aufgezeigt, durch die die Leistung gesteigert werden kann. Entwickler werden jedoch ausdrücklich darauf hingewiesen, dass die Vorschläge in diesem Artikel nur Informationszwecken dienen. Eine serverseitige Automatisierung von Office wird von Microsoft weder empfohlen noch unterstützt.

Hinweis In diesem Kontext werden der Microsoft 2007 Office System-Treiber und das 2010 Access-Datenbankmodul als Microsoft Office-Komponenten betrachtet. Darüber hinaus bezieht sich der Begriff „serverseitig“ auch auf Code, der auf einer Windows-Arbeitsstation ausgeführt wird, sofern dieser Code von einer Windows-Arbeitsstation aus ausgeführt wird, bei der es sich nicht um die interaktive Arbeitsstation handelt, an der der Benutzer angemeldet ist. So wird beispielsweise ein durch den Taskplaner unter dem Systemkonto gestarteter Code im gleichen Umfeld ausgeführt wie „serverseitiger“ ASP- oder DCOM-Code. Viele der in diesem Artikel beschriebenen Probleme können deshalb auftreten. Weitere Informationen zu Windows-Arbeitsstationen und COM finden Sie in den Abschnitten „Weitere Informationen“ und „Informationsquellen“.

Weitere Informationen


Alle aktuellen Versionen von Microsoft Office wurden entwickelt, getestet und konfiguriert, um als Endbenutzerprodukte auf einer Clientarbeitsstation ausgeführt zu werden. Bei diesen Produkten werden ein interaktiver Desktop und das Vorhandensein eines Benutzerprofils vorausgesetzt. Sie bieten daher nicht den erforderlichen Grad an Ablaufinvarianz und Sicherheit, um die Anforderungen an serverseitige Komponenten zu erfüllen, die darauf ausgelegt sind, unbeaufsichtigt ausgeführt zu werden.

Die Automatisierung von Microsoft Office-Anwendungen unter Verwendung unbeaufsichtigter, nicht interaktiver Clientanwendungen oder Clientkomponenten (wie ASP, ASP.NET, DCOM und NT-Dienste) kann von Microsoft zum jetzigen Zeitpunkt weder empfohlen noch unterstützt werden, weil Office bei einer Ausführung in einer solchen Umgebung instabil werden kann und/oder sich die Anwendungen eventuell gegenseitig sperren.

Wenn Sie eine Lösung erstellen, die in einem serverseitigen Kontext ausgeführt wird, sollten Sie Komponenten verwenden, die auch bei unbeaufsichtigter Ausführung sicher sind, oder nach Alternativen suchen, bei denen zumindest ein Teil des Codes clientseitig ausgeführt werden kann. Wenn Sie eine Office-Anwendung von einer serverseitigen Lösung aus verwenden, werden Sie feststellen, dass der Anwendung viele der Fähigkeiten fehlen, um erfolgreich ausgeführt werden zu können. Außerdem gehen Sie dabei erhebliche Risiken in Bezug auf die Stabilität Ihrer Gesamtlösung ein.

Probleme bei der serverseitigen Automatisierung von Office

Wenn Entwickler Office in einer serverseitigen Lösung verwenden möchten, gibt es fünf Hauptproblembereiche, in denen sich Office wegen der Serverumgebung anders als erwartet verhält. Wenn Ihr Code erfolgreich ausgeführt werden soll, müssen Sie sich um diese Probleme kümmern und deren negative Auswirkungen auf ein Minimum begrenzen. Achten Sie beim Erstellen Ihrer Anwendung sorgfältig auf diese Probleme. Mit einer einzigen Lösung können nicht alle Probleme behoben werden. Verschiedene Designs erfordern eine unterschiedliche Priorisierung der Elemente.

  • Benutzeridentität: Office-Anwendungen nehmen eine Benutzeridentität an, wenn sie ausgeführt werden. Dies gilt auch dann, wenn Sie mithilfe der Automatisierung gestartet werden. Die Anwendungen versuchen, Symbolleisten, Menüs, Optionen, Drucker und bestimmte Add-Ins auf Basis der Einstellungen zu initialisieren, die in der Registrierungsstruktur für den Benutzer festgelegt sind, der die Anwendung startet. Viele Dienste werden unter Konten ausgeführt, für die keine Benutzerprofile definiert sind (z. B. unter den Konten SYSTEM oder IWAM_[Servername]). Daher wird Office beim Start eventuell nicht korrekt initialisiert. In diesem Fall meldet Office einen Fehler für die Funktion CreateObject oder CoCreateInstance. Selbst wenn die Office-Anwendung gestartet werden kann, werden andere Funktionen ohne Benutzerprofil eventuell nicht korrekt ausgeführt.
  • Interaktivität mit dem Desktop: Office-Anwendungen sind darauf ausgelegt, unter einem interaktiven Desktop ausgeführt zu werden. In bestimmten Situationen müssen Anwendungen sichtbar gemacht werden, damit bestimmte Automatisierungsfunktionen einwandfrei funktionieren. Für den Fall, dass ein unerwarteter Fehler auftritt oder ein nicht angegebener Parameter benötigt wird, um eine Funktion erfolgreich auszuführen, ist Office darauf ausgelegt, dem Benutzer ein modales Dialogfeld anzuzeigen, in dem der Benutzer gefragt wird, was er tun möchte. Ein modales Dialogfeld auf einem nicht interaktiven Desktop kann nicht geschlossen werden. Dies hat zur Folge, dass der Thread nicht mehr reagiert (hängt). Die Wahrscheinlichkeit, dass dieses Problem eintritt, kann zwar durch bestimmte Codierungsverfahren reduziert werden, völlig ausschließen können Sie ein solches Problem jedoch nicht. Schon diese Tatsache allein hat zur Folge, dass die Ausführung von Office-Anwendungen in einer serverseitigen Umgebung riskant ist und nicht unterstützt wird.
  • Ablaufinvarianz und Skalierbarkeit: Serverseitige Komponenten müssen hochgradig ablaufinvariante Multithread-COM-Komponenten mit minimalem Overhead und hohem Durchsatz für mehrere Clients sein. Office-Anwendungen sind in nahezu jeder Hinsicht das exakte Gegenteil. Office-Anwendungen sind nicht ablaufinvariante, STA-basierte Automatisierungsserver, die dafür konzipiert wurden, eine Vielzahl ressourcenintensiver Funktionen für einen einzelnen Client zu ermöglichen. Als serverseitige Lösungen sind sie daher nur begrenzt skalierbar. Darüber hinaus gelten für die Anwendungen in Bezug auf wichtige Elemente wie etwa Arbeitsspeicher feste Grenzwerte. Diese Grenzwerte können nicht durch Konfiguration geändert werden. Noch wichtiger ist, dass die Anwendungen globale Ressourcen verwenden, wie beispielsweise im Arbeitsspeicher zugeordnete Dateien, globale Add-Ins oder Vorlagen und gemeinsam genutzte Automatisierungsserver. Auf diese Weise kann die Anzahl der gleichzeitig ausführbaren Instanzen begrenzt werden und es können Racebedingungen auftreten, falls die Anwendungen in einer Umgebung mit mehreren Clients konfiguriert sind. Wenn Entwickler mehr als eine Instanz einer beliebigen Office-Anwendung gleichzeitig ausführen lassen möchten, müssen sie ein „Pooling“ in Erwägung ziehen oder eine bestimmte Reihenfolge für den Zugriff auf die Office-Anwendung festlegen, um ein mögliches gegenseitiges Blockieren oder Beschädigungen von Daten zu verhindern.
  • Flexibilität und Stabilität: Office 2000, Office XP, Office 2003 und Office 2007 verwenden Microsoft Windows Installer-Technologie (MSI-Technologie), um Installation und Selbstreparatur für den Endbenutzer einfacher zu machen. Mit MSI wurde das Konzept „Bei erster Verwendung installieren“ eingeführt. Diese Funktion ermöglicht ein dynamisches Installieren oder Konfigurieren von Features zur Laufzeit (entweder für das gesamte System oder, was häufiger vorkommt, für einen bestimmten Benutzer). In einer serverseitigen Umgebung verlangsamt dies die Ausführung und erhöht die Wahrscheinlichkeit, dass Dialogfelder angezeigt werden, durch die der Benutzer aufgefordert wird, die Installation zu genehmigen oder einen Installationsdatenträger einzulegen. Die in Office implementierten MSI-Funktionen erhöhen zwar die Flexibilität von Office als Endbenutzerprodukt, sind in einer serverseitigen Umgebung jedoch kontraproduktiv. Außerdem kann auch die allgemeine Stabilität von Office bei einer serverseitigen Ausführung nicht garantiert werden, da Office für diese Art der Verwendung weder konzipiert noch getestet wurde. Die Verwendung von Office als Dienstkomponente auf einem Netzwerkserver kann die Stabilität dieses Computers und somit auch die Ihres Netzwerks insgesamt beeinträchtigen.
  • Serverseitige Sicherheit: Office-Anwendungen waren nie für den serverseitigen Einsatz gedacht. Die Sicherheitsprobleme, die bei verteilten Komponenten zu beachten sind, wurden bei ihrer Entwicklung daher auch nicht berücksichtigt. Office authentifiziert eingehende Anforderungen nicht und bietet auch keinen Schutz vor dem unbeabsichtigten Ausführen von Makros oder dem Starten eines anderen Servers, der Makros ausführen könnte, über Ihren serverseitigen Code. Öffnen Sie keine Dateien, die von einer anonymen Website auf den Server geladen wurden. Auf der Basis der zuletzt festgelegten Sicherheitseinstellungen kann der Server Makros im Kontext des Administrator- oder Systemkontos mit umfassenden Berechtigungen ausführen und Ihr Netzwerk kompromittieren. Außerdem verwendet Office eine Vielzahl clientseitiger Komponenten (wie Simple MAPI, WinInet und MSDAIPP), die Informationen zur Clientauthentifizierung zwischenspeichern können, um die Verarbeitung zu beschleunigen. Wenn Office serverseitig automatisiert wird, bedient eine Instanz eventuell mehr als einen Client. Wenn Authentifizierungsinformationen für die diese Sitzung zwischengespeichert wurden, kann ein Client die zwischengespeicherten Anmeldeinformationen eines anderen Clients verwenden. Der Client kann auf diese Weise ihm nicht gewährte Zugriffsberechtigungen erlangen, indem er die Identität eines anderen Benutzers annimmt.

Neben den technischen Problemen müssen Sie auch Lizenzierungsprobleme bedenken. Die aktuellen Lizenzierungsrichtlinien verbieten die Verwendung von Office-Anwendungen auf einem Server zur Bearbeitung von Clientanforderungen, sofern nicht die Clients selbst über lizenzierte Versionen der jeweiligen Office-Produkte verfügen. Die Bereitstellung von Office-Funktionalität für nicht lizenzierte Arbeitsstationen mithilfe der serverseitigen Automatisierung ist durch den Endbenutzer-Lizenzvertrag (EULA) nicht abgedeckt.

Neben diesen Problemen kann beim Versuch, Office serverseitig zu automatisieren, einer der folgenden häufigen Fehler auftreten:

  • Die Funktion CreateObject bzw. CoCreateInstance gibt eine der folgenden Laufzeitfehlermeldungen zurück und kann nicht für die Automatisierung gestartet werden.
     
    Fehlermeldung 1
    Laufzeitfehler '429': Objekterstellung durch ActiveX-Komponente nicht möglich
    Fehlermeldung 2
    Laufzeitfehler '70': Zugriff verweigert
    Fehlermeldung 3
    CO_E_SERVER_EXEC_FAILURE (0x80080005): Starten des Servers fehlgeschlagen
    Fehlermeldung 4
    E_ACCESSDENIED (0x80070005): Zugriff verweigert
  • Beim Öffnen eines Office-Dokuments wird eine der folgenden Fehlermeldungen angezeigt.
     
    Fehlermeldung 1
    Laufzeitfehler '5981' (0x800A175D): Makrospeicher konnte nicht geöffnet werden
    Fehlermeldung 2
    Laufzeitfehler '1004': Die Methode '~' für das Objekt '~' ist fehlgeschlagen
  • Die Funktionen CreateObject und CoCreateInstance reagieren nicht mehr und werden entweder nie erfolgreich abgeschlossen oder benötigen lange Zeit, um ein Ergebnis zurückzugeben. Auf manchen Servern erfolgt die Erstellung zwar schnell, es werden jedoch Fehler des Typs 1004 im Windows-Ereignisprotokoll gespeichert, die darauf hinweisen, dass die Anwendung beendet wurde.
  • Manche Funktionen schlagen aufgrund einer Benutzerwarnung oder eines sonstigen Dialogfelds, das eine Eingabe des Benutzers erfordert, unerwartet fehl oder reagieren auf unbestimmte Zeit nicht mehr.
  • Das Ausführen mehrerer Anforderungen oder eines Belastungstests kann dazu führen, dass der Code fehlschlägt, nicht mehr reagiert oder beim Erstellen bzw. beim Beenden einer Office-Anwendung abstürzt. Wenn dies geschieht, wird der Prozess entweder weiterhin im Arbeitsspeicher ausgeführt und kann nicht beendet werden, oder es schlagen von diesem Punkt an alle Instanzen der automatisierten Anwendung fehl.

Andere Probleme oder Meldungen können zusätzlich zu den hier aufgelisteten auftreten. Diese Probleme treten jedoch in der Regel aufgrund der fünf Hauptprobleme auf, die zuvor in diesem Artikel aufgeführt wurden. 

Alternativen zur serverseitigen Automatisierung

Microsoft empfiehlt Entwicklern dringend, Alternativen zur Automatisierung von Office zu suchen, wenn sie serverseitige Lösungen entwickeln müssen. Wegen der grundlegenden Beschränkungen des Designs von Office können nicht alle geschilderten Probleme durch Änderungen der Office-Konfiguration behoben werden. Microsoft empfiehlt nachdrücklich eine Reihe von Alternativen, bei denen Office nicht serverseitig installiert werden muss, und die häufigsten Aufgaben effizienter und schneller als bei der Automatisierung erledigt werden können. Bevor Sie Office als serverseitige Komponente in Ihr Projekt einbeziehen, sollten Sie Alternativen in Betracht ziehen.

Bei den meisten serverseitigen Automatisierungsaufgaben geht es um das Erstellen oder Bearbeiten von Dokumenten. Office 2007 unterstützt neue Open XML-Dateiformate, mit denen Entwickler Dateiinhalte serverseitig erstellen, bearbeiten, lesen und transformieren können. Diese Dateiformate verwenden den Namespace System.IO.Package.IO im Microsoft .NET 3.x Framework, um Office-Dateien zu bearbeiten, ohne die Office-Clientanwendungen selbst zu verwenden. Dies ist die empfohlene und unterstützte Methode für Änderungen an Office-Dateien über einen Dienst.

Bei den Open XML-Dateiformaten handelt es sich um einen öffentlichen Standard. 


Microsoft stellt ein SDK für die Bearbeitung von Open XML-Dateiformaten in .NET Framework 3.x bereit. Weitere Informationen zu dem SDK und dessen Verwendung zum Erstellen oder Bearbeiten von Open XML-Dateien finden Sie auf den folgenden MSD-Websites (Microsoft Developer Network):

Beim Streamen von Open XML-Dateien von ASP oder ASP.NET müssen Sie den korrekten MIME-Typ (Multipurpose Internet Mail Extension) für die Inhalte, die Sie streamen möchten, angeben. Eine Auflistung der MIME-Typen für Office 2007-Dateien finden Sie auf folgender Website:

Wenn Sie nur ältere Clients als Office 2007 verwenden möchten und Open XML in der Lösung nicht erforderlich sein soll, können Sie andere nicht binäre Office-Dateiformate wie z. B. HTML, XML und RTF verwenden. Anschließend können Sie diese Dateien mithilfe eines MIME-Typs an einen Client streamen, sodass der resultierende Text in Office angezeigt wird. Dieses Dokument kann auf dem Server mithilfe von ASP bearbeitet, gespeichert und sogar an den Server zurückgesendet werden.

Weitere Informationen zu diesen Themen und entsprechende Implementierungsbeispiele finden Sie in den folgenden Artikeln der Microsoft Knowledge Base:

198703 Automatisieren von Excel von einem clientseitigen VBScript
278973 ExcelADO zeigt, wie ADO zum Lesen und Schreiben von Daten in Excel-Arbeitsmappen verwendet wird
286023 Verwenden einer Visual Basic-ActiveX-Komponente zur Automatisierung von Word in Internet Explorer
 

Wenn in Ihrem Unternehmen die serverseitige Erstellung der Office 97-, Office 2000-, Office XP- und Office 2003-Binärdateiformate erforderlich ist, gibt es Fremdanbieter, die entsprechende hilfreiche Komponenten anbieten. Microsoft bietet keine solchen Komponenten an, weshalb Sie entweder eine Lösung selbst erstellen oder eine Lösung von einem Fremdanbieter erwerben müssen. Viele verschiedene Produkte von Fremdanbietern sind verfügbar. Sie sollten alle Lösungen prüfen, um den für Ihre Geschäftsanforderungen am besten geeigneten Anbieter zu finden.

Wenn Sie Ihre eigene Lösung erstellen möchten, mit der die Office 97-, Office 2000-, Office XP- und Office 2003-Binärdateiformate direkt bearbeitet werden können, können Sie die Dateiformatspezifikationen im Rahmen der Microsoft Open Specification Promise (OSP) kostenlos beziehen. Für die Dokumentation oder die Produkte, die Sie erstellen, ist kein technischer Support verfügbar, aber Dokumentation ist erhältlich. 


Serverseitige Lösungen sollten Benutzern möglicherweise auch das Hochladen von Dateien erlauben. Der Server rendert dann die Dateien für die Anzeige im Web oder auf anderen Medien. Microsoft arbeitet derzeit daran, derartige Features anzubieten, und stellt eine Vorabversion dieser Komponente in Microsoft Excel Services bereit.

Excel Services ist eine neue in Microsoft Office SharePoint Server 2007 enthaltene Servertechnologie, mit der Sie Excel-Arbeitsmappen in Office SharePoint Server 2007 laden, berechnen und anzeigen können. Weitere Informationen zu Excel Services finden Sie auf den folgenden MSDN-Websites (Microsoft Developer Network):

Word Automation Services ist eine neue Dienstanwendung in SharePoint Server 2010. Word Automation Services bietet die unbeaufsichtigte, serverseitige Konvertierung von Dokumenten in Formate, die von der Microsoft Word-Clientanwendung unterstützt werden.Sie müssen sorgfältig abwägen, welche der in diesem Artikel beschriebenen Optionen Ihre Anforderungen bestmöglich erfüllt und wie Sie Ihre Lösung bereitstellen können. Es kann keine Gewähr dafür gegeben werden, dass mithilfe der Informationen aus diesem Artikel alle Probleme für alle Clients behoben werden können. Microsoft empfiehlt, vor der Bereitstellung der Lösung ausführliche Tests durchzuführen.