Was bei der serverseitigen Automatisierung von Office zu beachten ist

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 gehen bei der Ausführung der Anwendungen von einer Benutzeridentität aus, auch wenn die Anwendungen von Automation gestartet werden. Die Anwendungen versuchen, Symbolleisten, Menüs, Optionen, Drucker und einige Add-Ins basierend auf Den Einstellungen in der Benutzerregistrierungsstruktur für den Benutzer zu initialisieren, der die Anwendung startet. Viele Dienste werden unter Konten ohne Benutzerprofile ausgeführt (z. B. das SYSTEM-Konto oder die IWAM_[Servername]-Konten). Aus diesem Grund wird Office beim Start möglicherweise nicht ordnungsgemäß initialisiert. In diesem Fall gibt Office einen Fehler für die CreateObject-Funktion oder die CoCreateInstance-Funktion zurück. Selbst wenn die Office-Anwendung gestartet werden kann, funktionieren andere Funktionen möglicherweise nicht ordnungsgemäß, wenn kein Benutzerprofil vorhanden ist.

• 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 die serverseitige Verwendung vorgesehen. Daher berücksichtigen Office-Anwendungen nicht die Sicherheitsprobleme, mit denen verteilte Komponenten konfrontiert sind. Office authentifiziert eingehende Anforderungen nicht. Office schützt Sie auch nicht davor, aus Ihrem serverseitigen Code unbeabsichtigt Makros auszuführen oder einen anderen Server zu starten, auf dem Möglicherweise Makros ausgeführt werden. Öffnen Sie keine Dateien, die von einer anonymen Website auf den Server hochgeladen werden. Basierend auf den zuletzt festgelegten Sicherheitseinstellungen kann der Server Makros unter einem Administrator- oder Systemkontext mit vollständigen Berechtigungen ausführen und somit Ihr Netzwerk gefährden. Darüber hinaus verwendet Office viele clientseitige Komponenten (z. B. Simple MAPI, WinInet und MSDAIPP), die Clientauthentifizierungsinformationen zwischenspeichern können, um die Verarbeitung zu beschleunigen. Wenn Office serverseitig automatisiert wird, kann eine instance mehr als einen Client bedienen. Wenn 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.

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.

Zusätzlich zu diesen Problemen kann einer der folgenden häufigen Fehler auftreten, wenn Sie versuchen, Office serverseitig zu automatisieren:

• Die Funktion CreateObject bzw. CoCreateInstance gibt eine der folgenden Laufzeitfehlermeldungen zurück und kann nicht für die Automatisierung gestartet werden.  

  Meldung 1

  Laufzeitfehler '429': ActiveX-Komponente kann kein Objekt erstellen

  Meldung 2

  Laufzeitfehler "70": Berechtigung 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.

  Meldung 1

  Laufzeitfehler "5981" (0x800A175D): Makrospeicher konnte nicht geöffnet werden

  Meldung 2

  Laufzeitfehler "1004": Fehler bei Methode "~" des Objekts "~"

• 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 Belastungstests führt dazu, dass der Code fehlschlägt, nicht mehr reagiert oder beim Erstellen oder Beenden einer Office-Anwendung abstürzt. In diesem Fall wird entweder der Prozess im Arbeitsspeicher ausgeführt und kann nicht beendet werden, oder alle Instanzen der Anwendung, die automatisiert wird, schlagen ab diesem Zeitpunkt fehl.

Zusätzlich zu den hier aufgeführten Problemen können weitere Probleme oder Meldungen auftreten, aber diese Probleme treten in der Regel aufgrund der fünf Standard Probleme auf, die weiter oben in diesem Artikel aufgeführt sind. 

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 Beschränkungen des Designs von Office können nicht alle geschilderten Probleme durch Änderungen der Office-Konfiguration behoben werden. Microsoft empfiehlt dringend eine Reihe von Alternativen, bei denen eine serverseitige Installation von Office nicht erforderlich ist, und mit denen die Ausführung der gebräuchlichsten Aufgaben schneller und effizienter möglich ist als bei der Automatisierung. Bevor Sie Office als serverseitige Komponente in Ihr Projekt einbeziehen, sollten Sie mögliche Alternativen erwägen.

Die meisten serverseitigen Automatisierungsaufgaben umfassen die Dokumenterstellung oder -bearbeitung. 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 in Microsoft .NET Framework 3.x zum Bearbeiten von Office-Dateien, ohne die Office-Clientanwendungen selbst zu verwenden. Dies ist die empfohlene und unterstützte Methode für Änderungen an Office-Dateien über einen Dienst.

Die Open XML-Dateiformate sind ein öffentlicher Standard. 

Microsoft bietet ein SDK zum Bearbeiten von Open XML-Dateiformaten aus .NET 3.x Framework. 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):

Open XML SDK-Dokumentation

Vorgehensweise: Bearbeiten von Office Open XML-Formatdokumenten

Bearbeiten Word 2007-Dateien mit dem Open XML-Objektmodell (Teil 1 von 3)

Bearbeiten von Word 2007-Dateien mit dem Open XML-Objektmodell (Teil 2 von 3)

Bearbeiten Word 2007-Dateien mit dem Open XML-Objektmodell (Teil 3 von 3)

Bearbeiten von Excel 2007- und PowerPoint 2007-Dateien mit dem Open XML-Objektmodell (Teil 1 von 2)

Bearbeiten von Excel 2007- und PowerPoint 2007-Dateien mit dem Open XML-Objektmodell (Teil 2 von 2)

Erstellen Server-Side Lösungen zur Dokumentgenerierung mithilfe des Open XML-Objektmodells (Teil 1 von 2)

Erstellen Server-Side Lösungen zur Dokumentgenerierung mithilfe des Open XML-Objektmodells (Teil 2 von 2)

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:

Office 2007-Dateiformat-MIME-Typen für HTTP-Inhaltsstreaming

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 Beispiele für deren Implementierung finden Sie in den folgenden Artikeln, um die Artikel in der Microsoft Knowledge Base anzuzeigen:

198703 Automatisieren von Excel von einem clientseitigen VBScript

Abfragen und Aktualisieren von Excel-Daten mithilfe von ADO aus ASP

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 möchten benutzern möglicherweise auch das Hochladen von Dateien ermöglichen und dann vom Server die Dateien zur Anzeige im Web oder auf anderen Medien rendern lassen. Microsoft arbeitet derzeit daran, solche Features anzubieten, und stellt eine frühe Version dieser Funktion in Microsoft Excel Services bereit.

Excel Services ist eine neue Servertechnologie, die in Microsoft Office SharePoint Server 2007 enthalten ist und es Ihnen ermöglicht, Excel-Arbeitsmappen in Office SharePoint Server 2007 zu laden, zu berechnen und anzuzeigen. Weitere Informationen zu Excel Services finden Sie auf den folgenden Msdn-Websites (Microsoft Developer Network):

Excel Services Übersicht

Exemplarische Vorgehensweise: Entwickeln einer benutzerdefinierten Anwendung mit Excel Web Services

Erstellen von Geschäftsanwendungen mit Excel Services- und Office Open XML-Formaten 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.

Übersicht über Word Automation Services

Einführung in Word Automation Services 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.