Problemfall Office Automation

Die Office Automation ist ein sehr mächtiges Werkzeug. Uns steht eine sehr umfangreiche Bibliothek zur Verfügung mit der man praktisch jede Funktionalität der Office Produkte fernsteuern kann. Das ist doch gut, oder? Ja, aber der Nachteil ist natürlich, dass man zur Erstellung eines Office-Dokuments überhaupt ein Office-Paket benötigt. Und das ist nicht gut. Stellen Sie sich folgendes vor: Unser Unternehmen oder unser Kunde setzt voll und ganz auf Service Orientierte Architekturen (nennt man auch SOAs, bestimmt schon mal gehört!). Ja, so was soll es tatsächlich geben! Wir sollen daher einen Server-Prozess programmieren, der auf Anfrage Word-Dokumente generiert (z.B. in fertige Dokumentvorlagen irgendwelche Inhalte automatisiert einfügt). Dann müsste auf der Maschine auf der unser Prozess laufen soll ein Office-Paket installiert sein. Und das wäre wirklich sehr schlecht! Warum?

Alle Versionen von Microsoft Office wurden für den Einsatz auf Client – Maschinen konzipiert und entwickelt. Es ist daher nicht wirklich überraschend, dass Microsoft den Einsatz von Microsoft Office auf einem Serversystem nicht empfiehlt und auch nicht supported. Microsoft listet im Artikel KB257757 die folgenden 5 Punkte, die zu Problemen von Microsoft Office auf einem Server führen können:

  1. Benutzeridentität: Serverprozesse laufen in der Regel unter Accounts, die kein Benutzerprofil haben. Microsoft Office benötigt aber ein Benutzerprofil beim Start der Anwendung um z.B. Toolbars, Menüs, Optionen und Drucker zu initialisieren. Außerdem könnten AddIns aktiviert sein, die ohne Benutzerprofil nicht korrekt arbeiten. All das kann dazu führen, dass eine Office Anwendung beim Starten (d.h. beim Instanzieren des Application Objects) einen Fehlercode produziert. Aber selbst wenn sich die Office Anwendung starten lässt, heißt das noch lange nicht, dass auch alles andere problemlos funktioniert.
  2. Benutzer-Interaktion: Wie Sie (wahrscheinlich) wissen, ist Office in der Regel sehr mitteilsam. D.h. es poppen immer mal wieder modale Dialoge auf. Das führt aber dazu, dass die gesamte Anwendung hängt solange ein Benutzer diesen Dialog nicht beendet. Und darauf kann man in der Regel auf einem Server sehr lange warten. Schon alleine aus diesem Grund sollte man Office Produkte nicht auf einem Server verwenden.
  3. Serverseitige Komponenten sollen skalierbar und ablaufinvariant (siehe Erläuterung weiter unten) sein. Genau das ist Office leider gerade nicht. Office – Anwendungen wurden konzipiert um eine Vielzahl ressourcenintensiver Funktionen für einen einzigen Client zu ermöglichen und sind daher nur begrenzt skalierbar und unterliegen einigen festen Einschränkungen. Außerdem verwenden Office – Anwendungen globale Ressourcen (z.B. im Speicher zugeordnete Dateien, globale AddIns, Vorlagen und gemeinsam genutzte Automatisierungsserver) um die mehrere gestartete Office-Instanzen konkurrieren und sich schlimmstenfalls sogar gegenseitig blockieren.
  4. Flexibilität und Stabilität: Office verwendet die Microsoft Windows Installer-Technologie (MSI), um Installation und Selbstreparatur für den Endbenutzer einfacher zu gestalten. Mit MSI wurde das Konzept des „Installierens bei der ersten Verwendung“ eingeführt, das ein dynamisches Installieren von Features zur Laufzeit ermöglicht. Das aber kann die Stabilität des gesamten Systems negativ beeinflussen. Durch MSI wird zwar die Flexibilität erhöht, auf einem Server verlangsamt das aber manchmal die Ausführung. Außerdem erhöht sich dadurch die Wahrscheinlichkeit, dass weitere Dialoge aufpoppen. Auch das ist ziemlich doof (siehe Punkt 2).
  5. Sicherheit: Da Office-Anwendungen nie für den Einsatz auf einem Server gedacht waren, bietet Office auch nicht die dafür erforderliche Sicherheit. So authentifiziert Office eingehende Anforderungen nicht und bietet auch keinen Schutz vor dem unberechtigten Ausführen von Makros.

(Was bedeutet eigentlich Ablaufinvarianz? Eine Komponente ist ablaufinvariant, wenn es im Ergebnis keinen Unterschied macht, ob Sie nur von einem oder von mehreren Client gleichzeitig aufgerufen wird. Idealerweise verwenden ablaufinvariante Komponenten deshalb keine globalen Ressourcen.)

Schließlich sollte man auch immer an die Lizenzierungsvorschriften denken. Die Lizensierungsrichtlinien von Microsoft verbieten den Einsatz von Office auf einem Server zur Bearbeitung von Clientanfragen wenn nicht alle Clients selber über eine lizensierte Version des eingesetzten Office Produktes verfügen.

Fazit: Office Automation ist definitiv nicht geeignet für den serverseitigen Einsatz!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s