Extend SharePoint to Integrate Other Office Applications

Artikel
08/24/2016

Einblicke in SharePointIntegrieren von Office-Anwendungen

Pav Cherny

Inhalt

Office-Anwendungsintegration
Erweitern der SharePoint-Benutzeroberfläche
Verwenden des Office OpenDocuments-Steuerelements
Kommunizieren mit SharePoint
Implementieren einer benutzerdefinierten OpenControl-Lösung
Schlussbemerkung

Microsoft Windows SharePoint Services (WSS) 3.0 und Microsoft Office SharePoint Server (MOSS) 2007 lassen sich nahtlos mit Desktopanwendungen im Microsoft Office 2007-System integrieren, was die Zusammenarbeit in Dokumenten, Tabellen, Kalendern, Kontaktinformationen und mehr vereinfacht. Tatsächlich ist die Integration so nahtlos, dass

das Office 2007-System als einheitliche Plattform für Office-Lösungen bezeichnet werden könnte.

Dies ist nützlich für Organisationen, in denen die Microsoft® Office-Technologie im Mittelpunkt steht, um die Produktivität von IT-Mitarbeitern zu fördern. Doch Organisationen mit einem vielfältigen Portfolio an Office-Anwendungen kommen nicht in den Genuss derselben standardmäßigen Interoperabilität. Das Office 2007-System bietet die notwendigen Integrationsfunktionen, doch die Benutzeroberflächen und Komponenten sind minimal dokumentiert und funktionieren nicht in allen Situationen. Dies erschwert es Drittanbieteranbietern, die SharePoint®-Technologie in ihre Anwendungen zu integrieren. Für ihre Kunden wird es sogar noch schwieriger, IT-Mitarbeitern eine einheitliche Erfahrung zu bieten.

In diesem Artikel erfahren Sie, wie Office-Anwendungen in SharePoint integriert werden können und mit SharePoint kommunizieren und wie Sie Nicht-Microsoft-Anwendungen in SharePoint auf der Grundlage derselben Prinzipien integrieren können. Doch zuerst folgt eine kurze Erläuterung der Serverkonfigurationseinstellungen, clientseitigen Komponenten und Kommunikationsprotokolle, die zum Erzielen einer nahtlosen Integration verwendet werden.

Nach Klärung dieser Einzelheiten geht es um die Integration von Anwendungen ohne integrierte SharePoint-Unterstützung. Dabei gehe ich über das übliche Maß hinaus, das sich in der Regel auf das Implementieren von IFilter-Komponenten zum Erweitern von Suchfunktionen und Hinzufügen benutzerdefinierter Symbole auf SharePoint-Servern konzentriert. Das Erweitern der Suche und die Rückgabe mit richtigen Symbolen führt nicht zur vollständigen Anwendungsintegration; vielmehr möchten die Benutzer diese Dokumente auch direkt von ihrer SharePoint-Benutzeroberfläche aus öffnen können.

Hier wird es kompliziert. Sie benötigen eine clientseitige Komponente, die nicht sogleich verfügbar ist, wenn Sie Office nicht auf Ihren Arbeitsstationen bereitgestellt haben. Doch selbst wenn Office bereitgestellt wurde, könnten Sie feststellen, dass diese Komponente nicht zuverlässig funktioniert, was von Ihrer SharePoint-Sitetopologie und Konfiguration abhängt.

Zum Lösen dieses Problems habe ich eine benutzerdefinierte Lösung erstellt, mit der beliebige Anwendungen wie Editor, Adobe Reader oder Autodesk AutoCAD integriert werden können, ohne dass Office bereitgestellt werden muss. Diese benutzerdefinierte Lösung zeigt auch, warum die Anwendungsintegration, die auf Office-Standardkomponenten basiert, bisweilen fehlschlägt. Sie finden diese Lösung sowie Anweisungen zur schrittweisen Bereitstellung und Konfiguration im Begleitmaterial zu diesem Artikel, das im Codedownloadbereich von .com zur Verfügung steht.

Office-Anwendungsintegration

Aus der Benutzerperspektive scheinen SharePoint-Menüs wie das Windows®-Startmenü zu funktionieren. Das Erstellen eines neuen Dokuments in einer Dokumentbibliothek ist einfach: Klicken Sie auf „Neu“, dann auf „Neues Dokument“, und Microsoft Office Word 2007 startet. Das Bearbeiten eines vorhandenen Dokuments ist ähnlich einfach. Bewegen Sie den Mauszeiger über das Dokument, öffnen Sie das ECB-Dropdownmenü (Edit Control Box, „Steuerelementfeld bearbeiten“), und klicken Sie dann auf „Bearbeiten“ in Word. Es wird selten bedacht, dass Word 2007 von einer Webseite aus über Javascript gestartet wurde, dass die Anwendung lokal ausgeführt wird, während sich das Dokument weit entfernt in einer SQL Server®-Datenbank befindet, und dass sich ein Webserver innerhalb des Datenzugriffspfads befindet, wie in Abbildung 1 dargestellt.

Abbildung 1 Arbeiten mit einem Word-Dokument in SharePoint (Klicken Sie auf das Bild, um es zu vergrößern)

Trotz dieser Komplexität ist die Benutzererfahrung auf einer Windows-Arbeitsstation, auf der das Office 2007-System installiert ist, nahtlos. Das Arbeiten mit Dokumenten in einer SharePoint-Bibliothek ist sehr ähnlich wie das Arbeiten mit lokalen Dateien oder Dateien auf einer Netzwerkfreigabe.

Doch auf einer Windows-Arbeitsstation ohne Office 2003 oder das Office 2007-System ist die Benutzeroberfläche anders. Wenn Sie in Word auf „Neues Dokument“ oder „Bearbeiten“ klicken, wird nur ein Dialogfeld mit der Information angezeigt, dass eine mit Windows SharePoint Services kompatible Anwendung nicht verfügbar ist.

Dies überrascht nicht weiter. Es gibt mehrere Elemente, die zusammenarbeiten müssen, um die einheitliche Erfahrung zu bieten, wie Office-Benutzer sie kennen. SharePoint muss die Inhaltstypen kennen, die in der Dokumentbibliothek verwaltet werden, um die gewünschten Befehle im Menü „Neu“ und „ECB“ zu rendern. Als Reaktion auf Mausklicks auf diese Befehle muss JavaScript-Code mit dem Ausführen der zugeordneten Anwendung beginnen und den Pfad zu dem Dokument weiterleiten. Dieser Teil ist nicht unabhängig von der Arbeitsstationskonfiguration, da der JavaScript-Code lokal ausgeführt wird. Darüber hinaus muss die zugeordnete Anwendung mit SharePoint kommunizieren, um Dateien zu lesen und möglicherweise zu schreiben. Dies sind die Elemente, die zusammengeführt werden müssen, wenn Sie Ihre Anwendungen in SharePoint integrieren möchten.

Andererseits ist die Kommunikation zwischen SharePoint und dem Datenbankserver für die Anwendung transparent, was auch für die Indizierungsprozesse auf dem Webserver zum Vereinfachen der Suche gilt. Aus diesem Grund werden diese Aspekte in diesem Artikel nicht weiter erörtert, doch Sie sollten sich das Microsoft Filter Pack ansehen, das im Microsoft Knowledge Base-Artikel „Registrieren von Microsoft Filter Pack bei Windows SharePoint Services 3.0“, verfügbar unter support.microsoft.com/kb/946338, dokumentiert wird. Jetzt geht es um das Hinzufügen von Befehlen, das Implementieren notwendiger clientseitiger Komponenten und das Vereinfachen der Anwendungskommunikation.

Erweitern der SharePoint-Benutzeroberfläche

Zum Erweitern der SharePoint-Benutzeroberfläche und -Funktionen steht eine Fülle von Optionen zur Verfügung. Sie können den Entwurf Ihrer Websites ändern, ASP.NET-Seiten anpassen, Webparts entwickeln oder den in WSS und MOSS integrierten JavaScript-Code ändern, um Ihre Anwendungen direkt zu starten.

Sie können die Ows.js-Datei in einem Texteditor öffnen (die Datei befindet sich im Ordner „COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Layouts\1033“ auf Ihren SharePoint-Front-End-Servern) und die Arbeitsweise der Funktionen „createNewDocumentWithProgIDCore“, „editDocumentWithProgIDNoUI“ und „DispDocItem“ ändern. Doch es gibt eine bessere Methode, bei der es nicht erforderlich ist, die WSS-Codebasis auf nicht unterstützte Weise zu ändern: das Verwenden von Inhaltstypen und Dokumenttypzuordnungen.

In meinem Artikel „Standardisieren der Datenverwaltung mit benutzerdefinierten Inhaltstypen“ (siehe TechNet Magazin, Februar 2008, technet.microsoft.com/magazine/cc194408.aspx) wurde erläutert, wie globale und standortspezifische Inhaltstypen zum Verwalten von Dokumenten und anderem Inhalt in SharePoint-Dokumentbibliotheken und Listen erstellt werden können. Sie können sich auch das Arbeitsblatt „Text Content Type.pdf“ im Begleitmaterial zu diesem Artikel ansehen, das zeigt, wie ein neuer Inhaltstyp für .text-Dateien erstellt und dieser Inhaltstyp einer Dokumentbibliothek zugeordnet werden kann. Sie können dann den Befehl „Text Content“ (Textinhalt) im Menü „Neu“ genau wie den Befehl „Dokument“ für Word-Dokumente auswählen (siehe Abbildung 2).

Abbildung 2 Ein benutzerdefinierter Inhaltstyp auf der SharePoint-Benutzeroberfläche (Klicken Sie auf das Bild, um es zu vergrößern)

Das ECB-Menü ist ähnlich erweiterbar. Vielleicht haben Sie erwartet, dass das ECB-Menü Inhaltstypen unterstützt, doch die aktuelle WSS-Version implementiert dieses Menü nicht auf diese Weise. Stattdessen müssen Sie Ihren Dokumenttyp in Docicon.xml registrieren. Sie finden diese Datei im Ordner %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Xml auf jedem SharePoint-Front-End-Server.

Durch Hinzufügen der folgenden Dokumenttypzuordnung zum Bereich <ByExtension> von Docicon.xml beispielsweise wird dafür gesorgt, dass SharePoint den Befehl „Mit Editor bearbeiten“ anzeigt (die Datei „Text Content Type.pdf“ enthält ausführlichere Anweisungen):

<Mapping Key="text" Value="ictxt.gif" 
  EditText="Notepad"
  OpenControl="SharePoint.OpenDocuments"/>

Der Key-Parameter identifiziert die Dateinamenerweiterung, der Value-Parameter definiert das Dokumentsymbol, das auf der Benutzeroberfläche angezeigt wird, der EditText-Parameter definiert die Zeichenfolge, die von SharePoint an den Befahl „Edit in“ (Bearbeiten in) angehängt wird, und der OpenControl-Parameter gibt die ProgID einer clientseitigen COM-Komponente an. Dies ist die ProgID, die von den SharePoint-JavaScript-Funktionen an einen ActiveXObject-Aufruf übergeben wird (Einzelheiten dazu finden Sie in Ows.js), um das COM-Objekt zu instanziieren, bei dem es sich um die Anwendung selbst oder ein Hilfssteuerelement handeln kann, das die Anwendung auf der Grundlage des zugeordneten Dateityps startet.

Website zu SharePoint-Produkten und -Technologien

Sie sollten beachten, dass das als SharePoint.OpenDocuments bezeichnete OpenControl-Steuerelement auf ein ActiveX®-Steuerelement verweist, das in aktuellen Office-Versionen enthalten ist (%PROGRAMFILES%\Microsoft Office\Office12\Owssupp.dll). Wenn diese Datei auf Ihren Arbeitsstationen vorhanden ist und sich das angegebene Dokumentsymbol (Value-Parameter) im Ordner „%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Images“ auf Ihren SharePoint-Servern befindet, dürfte der größte Teil der notwendigen Integrationsarbeit bereits erledigt sein.

Das Windows SharePoint Services 3.0 SDK enthält einige Informationen zu den clientseitigen APIs (einschließlich des OpenDocuments-Steuerelements), die im Office 2007-System enthalten sind. Weitere Informationen finden Sie in dem Abschnitt „Client-Side API Reference“ unter msdn2.microsoft.com/ms440037.

Verwenden des Office OpenDocuments-Steuerelements

Das OpenDocuments-Steuerelement behandelt die wichtigsten Anforderungen an die Anwendungsintegration. Für seine Verwendung ist jedoch das Office 2003- oder das Office 2007-System erforderlich, und seine Funktionen sind begrenzt. Die Befehle im Menü „Neu“ funktionieren möglicherweise nicht immer, und bisweilen werden irreführende Benutzerbenachrichtigungen angezeigt.

Wie in Abbildung 3 dargestellt, informiert das OpenDocuments-Steuerelement den Benutzer, dass die erforderliche Anwendung nicht richtig installiert ist oder dass die Vorlagendatei nicht geöffnet werden kann, doch weder das eine noch das andere trifft zu. Bei der Funktion „Edit in“ gibt es ebenfalls Probleme. Die zweite, im Vordergrund in Abbildung 3 dargestellte Fehlermeldung wird häufig angezeigt. Sie ist mein absoluter Favorit, da sie sogar SharePoint-Experten in die Irre führt, doch dazu gleich mehr.

Abbildung 3 Irreführende Fehlermeldungen des OpenDocuments-Steuerelements (Klicken Sie auf das Bild, um es zu vergrößern)

Dennoch ist das OpenDocuments-Steuerelement nützlich in Umgebungen mit neuen Versionen von Office, die auf allen Arbeitsstationen installiert sind. Unter anderem können Sie Ihre Inhaltstypen aus dem Menü „Neu“ ausblenden (lassen Sie sich die Dokumentbibliothekseinstellungen anzeigen, klicken Sie auf „Reihenfolge der neuen Schaltflächen und Standardinhaltstyp ändern“, und deaktivieren Sie dann das Kontrollkästchen „Visible“ (Sichtbar) für alle betreffenden Inhaltstypen), sodass die Benutzer die erste Fehlermeldung nicht erhalten. Sie können auch Ihre Sitetopologie einfach halten, um WebDAV (Web-based Distributed Authoring and Versioning)-Kommunikationsprobleme zu vermeiden. Dadurch wird diese zweite Fehlermeldung beseitigt.

Kommunizieren mit SharePoint

Bisher wurde die SharePoint-Benutzeroberfläche erweitert und möglicherweise eine Anwendung mithilfe des OpenDocuments-Steuerelements gestartet, doch für meine Anwendung ist immer noch eine Möglichkeit zum Kommunizieren mit SharePoint erforderlich, um auf die Daten zuzugreifen. Wie immer unterstützt SharePoint dazu mehrere Methoden, z. B. Microsoft Office Frontpage®-Servererweiterungen, WSS-Remoteprozeduraufrufe (RPC), WebDAV und Webdienste. Tatsächlich können Office-Anwendungen wie Word 2007 einige oder alle dieser Kommunikationsmethoden verwenden, was davon abhängt, wie Sie auf ein Dokument zugreifen, beispielsweise über Webordner, zugeordnete Netzwerklaufwerke oder die SharePoint-Benutzeroberfläche.

Die SharePoint-Client-/Serverkommunikationsmethoden verlassen sich auf HTTP als das zugrunde liegende Protokoll. Frontpage- und WSS-RPCs beispielsweise verwenden HTTP POST- und HTTP GET-Anforderungen, die an ISAPI-Erweiterungen gerichtet sind, die sich auf SharePoint-Servern innerhalb des Ordners %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\ISAPI und allen seinen Unterordnern befinden.

Eine der wichtigsten ISAPI-Erweiterungen ist Owssvr.dll, die unter anderem Funktionen zur Arbeit mit Listen und Dokumentbibliotheken implementiert. Abbildung 4 zeigt das SharePoint-Dialogfeld „Speichern“ in Word 2007 (links) und in einem Browser (rechts), das direkt über die URL-Anforderung https://sharepoint/HR/Administration/_vti_bin/owssvr.dll?dialogview=FileSave&location=Shared%20Documents&FileDialogFilterValue=*.doc geöffnet wurde. Die Ähnlichkeiten zwischen den beiden Screenshots sind offensichtlich.

Abbildung 4 Das SharePoint-Dialogfeld „Speichern“ in Word 2007 und im Internet Explorer (Klicken Sie auf das Bild, um es zu vergrößern)

Andere wichtige ISAPI-Erweiterungen sind Author.dll zum Implementieren von Frontpage- und WSS-RPCs für clientseitige Bearbeitungsvorgänge wie das Hochladen, Umbenennen und Löschen von Dokumenten, Admin.dll zum Verwalten von Websites und zum Durchführen einiger anderer Verwaltungsaufgaben sowie Shtml.dll zum Unterstützen von HTML-Formularübertragungen.

Es ist im Allgemeinen unmöglich, Frontpage- und WSS-RPC-Unterstützung zu vorhandenen Anwendungen wie Editor oder Adobe Reader hinzuzufügen, ohne Zugriff auf den Quellcode zu haben. Doch Sie könnten die notwendige Kommunikationseinrichtung mithilfe des in Windows enthaltenen Webclient-Features bereitstellen.

SharePoint unterstützt auch WebDAV über Httpext.dll. Diese Datei befindet sich im Ordner %WINDIR%\System32\Inetsrv\, doch wir wollen uns weiter mit der Clientseite befassen. Auf Computern, auf denen Windows Server® 2008 oder Windows Vista® ausgeführt wird, ist das Webclient-Feature standardmäßig installiert. Sie können einen entsprechenden WebClient-Dienst im Applet „Dienste“ in „Verwaltung“ in der Systemsteuerung finden. Bei Windows XP und Windows Server 2003 muss der Webclient explizit installiert werden. Auf jeden Fall ist sicherzustellen, dass der WebClient-Dienst gestartet und der Starttyp auf „Automatisch“ gesetzt wurde.

Abbildung 5 stellt die Architektur des Webclients dar. Der WebClient-Dienst wird in einer Benutzermodus-DLL (Webclnt.dll) implementiert, und der Dienststeuerungs-Manager wird in einem Svchost.exe-Hostprozess geladen. Webclnt.dll stellt die Netzwerkanbieteroberfläche für Nicht-E/A-Vorgänge bereit (z. B. Authentifizieren des Benutzers für WebDAV-Zugriff, Bereitstellen von SharePoint-Sites als Netzlaufwerke, Aufzählungen von SharePoint-Sites, Listen und Dokumentbibliotheken als Netzwerkressourcen und Trennen von bereitgestellten Laufwerken).

Abbildung 5 Die Architektur für die WebDAV-Clientumleitung (Klicken Sie auf das Bild, um es zu vergrößern)

Zum Durchführen dieser Arbeit kommuniziert Webclnt.dll mit einem Dateisystemtreiber im Kernelmodus, der die eigentliche Umleitungsfunktion bereitstellt. Der WebDAV-Clientumleitungstreiber (Mrxdav.sys) basiert auf dem Redirected Drive Buffering Subsystem (RDBSS), das in den E/A-Manager und andere Kernelkomponenten integriert wird, um die Dienste eines Remotedateisystems zu bieten. Mrxdav.sys implementiert die WebDAV-Kommunikationsfunktion zum Unterstützen von Zugriff auf Dateisystemebene auf SharePoint-Sites und -Dokumentbibliotheken.

Die Zugriffsmöglichkeit auf SharePoint-Sites und -Dokumentbibliotheken über einen Netzwerkredirector beseitigt den Bedarf an Frontpage- und WSS-RPC-Unterstützung in Benutzeranwendungen. Netzwerklaufwerke können Dokumentbibliotheken zugeordnet werden (z. B. „net use x:“ http://wss/doclib/Shared%20Documents), und Sie können auf SharePoint-Ressourcen auch über UNC-Pfade zugreifen.

Die URL http://wss/doclib/Shared%20Documents ist \wss\doclib\Shared%20Documents zugeordnet. So haben Sie Auswahlmöglichkeiten zum Öffnen eines Dokuments in einer Anwendung. Sie können beispielsweise ein Dokument im Editor mit dem HTTP-Pfad http://wss/doclib/Shared%20Documents/New%20Text%20Document.txt oder dem UNC-Pfad \\wss\doclib\Shared%20Documents\New%20Text%20Document.txt öffnen.

Leider hat das Webclientfeature mehrere Einschränkungen. Auf benutzerdefinierte Eigenschaften oder Webanwendungen, die benutzerdefinierte TCP-Ports verwenden, kann nicht zugegriffen werden. Der in Windows Vista enthaltene Webclient schlägt ebenfalls fehl, wenn der Benutzer keinen Zugriff auf eine übergeordnete Website in der Hierarchie hat, wie in der Datei WebDAV Access. pdf dargestellt (siehe Begleitmaterial).

Der Pfad https://sharepoint/HR/Administration/Shared%20Documents/ enthält eine nicht vorhandene Stammwebsite (d. h. https://sharepoint), doch ohne Zugriff auf den Stamm kann der Webclient die Funktionen des Webservers nicht ermitteln. Der Webserver weist die OPTIONS-Anforderung des Webclients mit dem Statuscode 401 zurück, welcher besagt, dass der Zugriff nicht autorisiert ist. Folglich fordert der Webclient weiterhin Benutzeranmeldeinformationen an, wie in Abbildung 6 dargestellt, obwohl der Benutzer Administratorzugriff auf die Websitesammlung sharepoint/HR und alle darin enthaltenen Websites hat.

Abbildung 6 Erfolgloser WebDAV-Zugriff (Klicken Sie auf das Bild, um es zu vergrößern)

Beim Verwenden des Steuerelements OpenDocuments erhalten Sie die erste, in Abbildung 3 dargestellte Fehlermeldung, wenn der Webclient ein Dokument nicht öffnet. Die Anwendung ist verfügbar, und die Dokumenttypzuordnung ist korrekt. Es ist das Dokument, auf das über den WebDAV-Redirector nicht zugegriffen werden kann.

Implementieren einer benutzerdefinierten OpenControl-Lösung

Grundsätzlich haben Sie zwei Optionen zum Behandeln von Unzulänglichkeiten des Webclients. Sie können warten, bis Microsoft eine aktualisierte Webclientversion bereitstellt, oder Sie können eine benutzerdefinierte OpenControl-Lösung implementieren, die die aktuelle Situation behandeln kann. Das Implementieren eines benutzerdefinierten OpenControl-Steuerelements ist keine einfache Aufgabe, doch Office muss dann auf Ihren Arbeitsstationen nicht vorhanden sein. Sie können dann den Befehl „Neu“ zusätzlich zum Befehl „Bearbeiten in“ verwenden, und Sie können Situationen behandeln, in denen der Webclient fehlschlägt.

Wenn eins dieser Probleme für Sie interessant ist, sollten Sie sich den AppStart-Quellcode ansehen, der im Begleitmaterial enthalten ist. Er zeigt, wie die OpenControl COM-Schnittstellen in einer Microsoft .NET Framework-Assembly verfügbar gemacht werden können, die vom SharePoint JavaScript-Code aufgerufen werden kann. Der AppStart-Quellcode demonstriert auch eine Möglichkeit zum Prüfen der Dateieingabehilfe und zum Herunterladen einer Datei auf den lokalen Computer über HTTP, wenn der Direktzugriff über WebDAV nicht möglich ist. Schließlich reagiert der AppStart-Quellcode auf den Befehl „Neu“, indem die dem Inhaltstyp zugeordnete Vorlage auf den lokalen Computer heruntergeladen wird, sodass der Benutzer mit der Arbeit an dem Dokument beginnen kann. Die Arbeitsblätter „Text Content Type.pdf“ und „Adobe Reader Support.pdf“ erläutern, wie diese OpenControl-Lösung bereitgestellt wird.

Das in Abbildung 7 dargestellte Diagramm zeigt die AppStart-Architektur. Meine benutzerdefinierte OpenControl-Komponente (Biblioso.dll genannt) macht zwei identische COM-Schnittstellen verfügbar, die von SharePoint JavaScript aufgerufen werden, um neue Dokumente zu erstellen oder vorhandene Dokumente zum Bearbeiten zu öffnen (Biblioso.AppStart.2 und Biblioso.AppStart.3).

Abbildung 7 Die AppStart-Architektur (Klicken Sie auf das Bild, um es zu vergrößern)

Wenn ein Dokument zum Bearbeiten geöffnet wird, überprüft Biblioso.dll, ob die Datei vorhanden ist, und startet die zugeordnete Anwendung zusammen mit dem Pfad zum Dokument, wenn die Datei direkt über WebDAV zugänglich ist. Wenn die Datei nicht zugänglich ist, startet Biblioso.dll einen prozessexternen COM-Server, der wiederum OpenDocsUtility.dll lädt, um die Datei über HTTP herunterzuladen, und die Anwendung zusammen mit dem Pfad zu dem heruntergeladenen Dokument startet.

Der prozessexterne COM-Server ermöglicht der Lösung, den Internet Explorer®-Prozess zu verlassen, der Downloads in den Ordner für temporäre Internetdateien im geschützten Modus einschränkt. Benutzer müssen in der Lage sein, Dateien ohne die Einschränkungen des geschützten Modus herunterzuladen, und ein prozessexterner COM-Server, der als Anwendungs-Broker arbeitet, bietet diese Option.

Das Entwickeln von prozessexternen COM-Servern wird in .NET nicht unterstützt, sodass ich für diese ausführbare Datei zu C/C++ gewechselt bin. Ich habe nur das absolut erforderliche Dialogfeld „Speichern unter“ in C++ implementiert. Um die Lösung möglichst einfach und den Entwicklungsaufwand gering zu halten, wurde der eigentliche Downloadcode in eine .NET-Assembly (OpenDocsUtility.dll) gestellt, die dann über eine andere COM-Schnittstelle aufgerufen wird.

Zum Vereinfachen der Bereitstellung wurde der Lösung ein Setup-Projekt hinzugefügt. Unter anderem registriert die Setuproutine alle COM-Komponenten und schreibt anwendungsspezifische Einstellungen in HKEY_LOCAL_MACHINE\SOFTWARE\Biblioso\AppStart. Die wichtigsten Parameter sind AllowedApps und AllowedFileTypes. Die AppStart-Lösung funktioniert nur mit diesen Anwendungen und Dateitypen, die in diesen Parametern ausdrücklich angegeben werden müssen.

Die Setuproutine erstellt auch eine Erhöhungsrichtlinie für den prozessexternen COM-Server, sodass Biblioso.dll im Internet Explorer-Prozess AppBrokerEngine.exe starten kann, ohne Sicherheitswarnungen auszulösen. Wenn Sie mehr über den geschützten Modus für Internet Explorer und darüber erfahren möchten, wie damit in der Anwendungsentwicklung umgegangen wird, empfehle ich den Artikel „Understanding and Working in Protected Mode Internet Explorer“ von Marc Silbey und Peter Brundrett, der unter msdn2.microsoft.com/bb250462 verfügbar ist

Beim Untersuchen der AppStart-Komponenten sollte bedacht werden, dass diese Lösung entwickelt wurde, um einfach nur Möglichkeiten aufzuzeigen. Sie ist noch nicht in Produktionsumgebungen einsatzbereit. Es war nicht genug Zeit zum Optimieren des Codes und zum gründlichen Testen der Lösung oder zum Dokumentieren der Features mit Ausnahme von Quellcodekommentaren vorhanden.

Sie sollten diese Lösung auf eigenes Risiko verwenden. Wenn Sie den Quellcode untersuchen möchten, um Ihre eigene Lösung zu erstellen, beginnen Sie mit AppStart.cs im Biblioso-Codeprojekt. Diese Datei implementiert die OpenControl COM-Schnittstelle und die Einstiegspunkte für die JavaScript-Aufrufe aus Ows.js.

Schlussbemerkung

WSS 3.0 und MOSS 2007 bieten umfangreiche Funktionen zur Anwendungsintegration für eine nahtlose Benutzererfahrung beim Arbeiten mit Dokumenten und anderen Elementen in SharePoint-Dokumentbibliotheken und -Listen. Die Desktopanwendungen im Office 2007-System veranschaulichen dies sehr gut, und es ist möglich, dasselbe Maß an Integration und Benutzerfreundlichkeit auch mit Nicht-Office-Anwendungen zu erzielen.

Kern der Anwendungsintegrationsarchitektur sind neben dem Dokumentpfad zum Starten der Anwendung COM-Komponenten, die von den SharePoint JavaScript-Funktionen verwendet werden. Das Office 2007-System bietet mehrere dieser COM-Komponenten, die für spezifische Office-Anwendungsanforderungen optimiert wurden, obwohl es auch möglich ist, das Office-OpenDocuments-Steuerelement zum Integrieren von Nicht-Microsoft-Anwendungen wiederzuverwenden. Das OpenDocuments-Steuerelement erfüllt die grundlegendsten Anforderungen. Für erweitertere Anforderungen an die Anwendungsintegration kann ein benutzerdefiniertes Steuerelement implementiert werden.

Das vollständige Integrieren einer Anwendung in SharePoint ist nicht nur mit dem Installieren von IFilter-Komponenten und Dokumentsymbolen zum Erweitern der Such- und Anzeigefunktionen verbunden, sondern umfasst auch das Erstellen benutzerdefinierter Inhaltstypen und Dokumenttypzuordnungen auf den SharePoint-Servern zum Bereitstellen der entsprechenden Befehle „Neu“ und „Bearbeiten in“ auf der SharePoint-Benutzeroberfläche. Diese Befehle rufen JavaScript-Funktionen auf, mit denen Methoden aufgerufen werden, die durch eine OpenControl-Komponente verfügbar gemacht werden. Die OpenControl-Komponente muss ebenfalls auf der Arbeitsstation verfügbar sein.

Ein weiteres wichtiges Stück des Puzzles ist der Webclient, der standardmäßig in Windows Vista enthalten und installiert ist. Der Webclient implementiert einen WebDAV-Redirector und Remotedateisystemtreiber, damit ähnlich wie bei Dateifreigaben auf dem Netzwerk beliebige Anwendungen auf Ressourcen in SharePoint-Listen und -Dokumentbibliotheken zugreifen können. Obwohl der in Windows Vista enthaltene Webclient Mängel hat, ist er wichtiges Bestandteil der Anwendungsintegration.

WebDAV-Unterstützung schließt auch die Lücke zwischen auf Nicht-Windows-Arbeitsstationen ausgeführten Anwendungen und SharePoint. Die COM- und ActiveX-Steuerelementtechnologie ist im Allgemeinen auf diesen Betriebssystemen nicht verfügbar, sodass Sie keine OpenControl-Komponenten zum automatischen Starten von Anwendungen verwenden können, doch die meisten Betriebssysteme enthalten WebDAV-Redirectordienste, sodass Benutzer zumindest auf Dokumente in Dokumentbibliotheken direkt zugreifen können, ohne die Dateien auf die lokale Arbeitsstation herunterladen zu müssen.

WSS 3.0 und MOSS 2007 sind Grundsteine der Erfolgsgeschichte des Office 2007-Systems, und Benutzer von Drittanbieteranwendungen auf der Grundlage von Office können gleichermaßen von SharePoint profitieren. Die Integrationsfunktionen gehen weit über Office hinaus. Durch die umfassende Nutzung von SharePoint können Sie eine einheitliche Plattform von Office-Lösungen erstellen, die dieselbe Benutzererfahrung für Office- und Drittanbietersoftware bietet und somit die Produktivität von IT-Mitarbeitern fördert.

Pav Cherny ist IT-Experte und Autor und ist auf Microsoft-Technologien für die Zusammenarbeit und einheitliche Kommunikation spezialisiert. Seine Veröffentlichungen enthalten Whitepapers, Produkthandbücher und Bücher mit Fokus auf IT-Vorgänge und Systemverwaltung. Pav ist Präsident der Biblioso Corporation. Dieses Unternehmen ist auf verwaltete Dokumentations- und Lokalisierungsdienste spezialisiert.

Zusätzliche Ressourcen