Office Integration – Was heißt das eigentlich?

In den vergangenen Wochen habe ich mich sehr darum bemüht mal die ganzheitliche Übersicht über die ganzen Developer-Themen rund um Office zu bekommen. Keine leichte Aufgabe, wie ich feststellen musste. Was ich aber auch festgestellt habe: Kaum jemand hat tatsächlich die komplette Story erfasst. Kaum jemand konnte mir mit wenigen Sätzen den SharePoint beschreiben. Und für nahezu jeden bedeuten die Möglichkeiten was anderes – jeder beginnt mit anderen Dingen, die ihm wichtig erscheinen.

Das bedeutet zwar, dass unsere Tools in dem bereich dermaßen flexibel sind, dass nahezu alles damit machbar ist. Es birgt aber auch das Problem, dass die Kernfunktionalität überhaupt nicht mehr greifbar für den Einzelnen zu sein scheinen.

Office Clients (VBA)

Ich fange mal ganz vorne an. Office Integration. Die erste Sache, die mir dazu einfällt, ist Word und Excel, vielleicht noch Outlook und PowerPoint. Huh! Was hat das denn mit Entwicklern zu tun – das sind doch fertige Produkte. Ja, stimmt. Aber auch irgendwie wieder nicht. Jeder weiß doch, dass man da Makros aufzeichnen kann. Macht man den Quellcode eines solchen Makros mal mit dem Editor auf, so trifft man auf VBA – Visual Basic for Applications. Die einfachste Art Office zu programmieren.

Abb.1: Office und die VBA-Schnittstelle

Was man mit Makro-Aufzeichnungen erreichen kann ist schon ganz ordentlich. Nicht nur, dass man auf praktisch alle Funktionalitäten des entprechenden Office-Produktes zugreifen kann. Man hat auch die volle Power von VB6 wie z.B. COM-Zugriffe, man kann eigene Formulare erstellen und sogar das Office-Menü nach belieben verunstalten. Das ist doch schon mal was. Leider halt VB6.

Office als Service nutzen (COM-Interop)

Die Integration von Office muss nicht immer bedeuten, dass Sie irgendwas in Office integrieren, sondern kann auch den umgekehrten Fall beschreiben. Zum Beispiel dass Sie aus einer anderen Anwendung heraus ein Office-Produkt ansprechen. Die Variante erlaubt dann die Nutzung von Office-Funktionalitäten aus Fremdprodukten – möglicherweise sogar vollkommen unsichtbar im Hintergrund. Das wird gerne genutzt, um auf Word- oder Excel-Dateien zuzugreifen (wobei hier natürlich auf das OpenXML SDK verwiesen werden muss, falls nur der Inhalt von Dateien eigesehen werden muss) oder einzelne Dokumente auszudrucken. Auch über diese Schnittstelle stehen im Grunde alle Funktionalitäten zur Verfügung und kann vollkommen ohne User-Interaktion angesprochen werden.

Abb. 2: Office und die COM-Inerop-Schnittstelle

Managed Office Entwicklung (VSTO)

Wer managed programmieren will, für den gibts seit einigen Office-Generationen VSTO – Visual Studio Tools für Office. Das ist eine Erweiterung für Visual Studio um gezielt für einzelne Office-Produkte Dokumentvorlagen oder Add-Ins zu entwickeln. Diese Art der Entwicklung zeichnet sich durch ein mehr oder minder ordentliches Deployment aus, erlaubt die Nutzung der vollen .NET-Power und ist eben managed. Sehr angenehm – vorallem, wenn das Projekt mal etwas umfangreicher wird und sich nicht nur auf das einzelne Produkt beschränkt, sondern vielleicht eine Anbindung an weitere Anwendungen besteht. Wollen Sie beispielsweise eine Kundenliste, die sie in einem weiteren Programm verwalten, auch in Outlook verfügbar machen oder in Excel importieren, dann ist ein Office Add-In die direkte Lösung dafür.

 
Abb. 3: Office Integration durch Add-Ins

Office als Plattform

Nun ist es ja so, dass Office schon lange nicht mehr nur eine Sammlung von Einzelprogrammen ist, die unabhängig voneinander vor sich hin wurschteln. Schon in frühen Versionen war die Zusammenarbeit unter den Produkten klar zu erkennen. Drag-Drop-Aktionen aus Excel nach Word oder der Import von Visio-Diagramme in Outlook-Emails war kein Problem. Nach und nach sind aber auch eine Reihe von Server-Produkten ins Spiel gekommen, die das Zusammenspiel noch um ein Vielfaches verbessert haben. Angefangen mit dem Exchange-Server, über den Outlook in der Lage war, nicht nur lokal Mails zu verwalten, sondern firmenweit mit anderen Accounts zusammen zu arbeiten. Kalenderfreigaben und öffentliche Ordner sind Beispiele für den Mehrwert solcher Lösungen. Von dieser Sorte Server-Produkte gibt es inzwischen eine ganze Reihe. Ganz vorweg zu nennen ist der SharePoint. Alles in allem muss man sagen, dass Features einzelner Produkte zwischenzeitlich kaum noch den eigentlichen Mehrwert ausmachen. Die Bauteile der Office-Welt bestechen durch ihre perfekte Integration ins Betriebssystem, dem Internet-Explorer und nicht zu vergessen der Verzahnung in sich selbst und Ihresgleichen. Durch die Möglichkeiten der Anprogrammierung all dieser Komponenten, lässt mich dieses große Konstrukt dann bequem als Plattform bezeichnen. Die Basis für Ihre Software-Projekte.

 
Abb. 4: Office-Anbindung an verschiedene Server

SharePoint, das serverseitige Office

Aus diesem wirrwar aus verschiedensten Office-Produkten lässt sich ein zentrales Produkt heraus deuten, das in den vergangenen Jahren extrem an Bedeutung gewonnen hat: Der SharePoint. Angefangen als zentrale Dokumenten-Ablage, oder doch eher als Kolaborations-Werkzeug? Da gibt’s viele Meinungen – ist der SharePoint das flexibelste, dafür aber auch “schwammigste” Produkt, das wir so anbieten. Man stelle sich den SharePoint jetzt einfach mal als CMS (Content Management System) vor, das es erlaubt, verschiedenste Content-Items (seien es Dateien, Links, Texte oder beliebige Datensätze) an zentraler Stelle zu speichern. Versehen mit einem ordentlichen Rechtekonzept hat man nun ein Set an Funktionalitäten, die Grundlage für eine ganze Menge von sinnvollen Anwendungen sein könnte und hat im Grunde schon den Rahmen für die Windows SharePoint Services definiert, die die Basis des SharePoints bilden. Der SharePoint verpasst diesen Funktionalitäten jetzt noch eine ordentliche Weboberfläche und stellt auch noch reichlich Templates für die üblichen Anwendungefälle (Dokumentenlisten, Kalender, Umfragen,…) zur Verfügung. Vergessen wir jetzt nicht noch die Hochskalierbarkeit und fertig ist der Server.

Es ist unnötig zu sagen, dass alle Client-Produkte sich extrem integrieren – oder umgekehrt? Outlook erlaubt die Einbindung der virtuellen Listen in den Navigationsbaum und die Einbindung von SharePoint-Kalendern. Auf dem SharePoint kann man sich über Änderungen in Listen per Email informieren lassen. Excel, Word und Co können auf SharePoint-Listen wie auf Netzwerk-Dateien zugreifen und viele weitere dieser Dinge. Falls mal kein Office am Client installiert sein sollte kann man viele Dinge auch direkt im Browser erledigen. Ja, auch mit Firefox! Die Verlagerung der täglichen Arbeitsdaten vom Client zum Server lässt auch die Überlegung aufkommen, Einbindungen am Client auch zum Server verlagert. So könnte die oben genannte Kundenliste nicht nur am Client für den Import bereit stehen, sondern direkt im SharePoint als Liste aufbereitet werden. So kann man auf die vorhandenen Mechanismen (Outlook-Integration als Kontakliste, Word-Import als Serienbriefquelle, Excel-Import von Kontaktdaten,…) zurück greifen und hat somit viele Integrationen über eine zentrale Stelle geregelt.

Abb. 5: Einbindung der Serverprodukte in die Integration

Solche Szenarien zeigen, dass die Integration von Applikationen in Office bei weitem nicht an den Toren der Client-Produkte endet. Durch das Netzwerk an weiteren, gut verdrahteten Elementen des Kolaborationsnetzwerkes bieten sich viele weitere Integrationsmöglichkeiten, die ihren Impact auch beim Client zeigen.

Die Liste der hier genannten Client- und Server-Produkte sind bei weitem nicht vollständig.