Die Erfahrungen, die wir in vielen SharePoint-Projekten machen zeigen, dass Fragen nach der Datenbasis des SharePoint in den meisten Fällen dann auftauchen, wenn es um die Fähigkeiten der längerfristigen Ablage dieser Daten geht. Ein Beispiel für solch eine Frage lautet: Kann ich die Dokumente bedenkenlos 5 Jahre im SharePoint aufbewahren? Die Antwort auf solch eine Frage muss immer ein „Aber-Satz“ sein. Selbstverständlich können Sie, ein entsprechendes Betriebskonzept vorausgesetzt, Ihre Daten 5 Jahre lang in der Inhaltsdatenbank des SharePoint aufbewahren, aber die einzige (von Microsoft unterstützte) Möglichkeit wieder an die Daten zu kommen, ist der Aufruf entweder der SharePoint Server API, der SOAP oder der SharePoint REST Schnittstelle. D.h. jede weitere Anwendung, die Daten aus den Inhaltsdatenbanken des SharePoint benötigt, muss zwingend durch die Applikationsschicht des SharePoint hindurch darauf zugreifen. Vergessen Sie direkte SQL-Abfragen à la „SELECT * FROM“, denn die werden, wie gesagt, von Microsoft nicht unterstützt. Auch das Datenschema in welchem SharePoint seine Daten verwaltet, ist Verschlusssache und kann jederzeit geändert werden. Tja, jetzt haben wir den Salat. Die Daten befinden sich zwar innerhalb des Netzwerkes, aber irgendwie hat man trotzdem keine Kontrolle darüber und jede andere Anwendung, die an die Daten möchte, muss erst einmal SharePoint sprechen.
Das ist natürlich nur die erste Dimension des Problems. Weiter könnte man fragen: Wie sollte man eigentlich mit externen Zugriffen umgehen? Soll ich meinen Partnern und Kunden Zugriff auf das Unternehmensnetzwerk und Zugriff auf SharePoint gewähren? Oder erstelle ich jetzt wieder eine Applikation, die sich um den Export aus dem SharePoint kümmert, um das Ganze dann möglicherweise in eine Dritt-Anwendung zu importieren?
Für uns hat sich folgende Antwort auf die beiden skizzierten (bewusst überzeichneten) Szenarien bewährt. Zum einem ist unser Ziel, dass die Daten in einem für alle zugänglichen Format vorliegen, das unabhängig vom Datenbank-Schema des SharePoint ist. Um dieses Ziel zu erreichen, nutzen wir die SQL Remote BLOB Storage (RBS) Schnittstelle, um die binären Daten an eine für uns sinnvolle Stelle zu schreiben. Zum anderen erhalten alle BLOBs ihre zugehörigen Metadaten im XML-Format beigelegt, so dass am Ende der Informationsgehalt meiner Daten unverändert bleibt. Das Schöne an RBS ist, dass der SharePoint davon nichts mitbekommt und die Daten nun über zwei Wege erreichbar sind: SharePoint + Datenablage.
Konsequent zu Ende gedacht macht das Ganze nur dann wirklich Sinn, wenn so auch Externen die Möglichkeit gegeben wird, ohne Hürden auf die Daten zuzugreifen und ohne einen direkten Zugriff in das Unternehmensnetzwerk zu benötigen. Unsere Antwort darauf ist Azure. Vermutlich gibt es kein Unternehmen, das einem derartig permanenten Sicherheitsstresstest unterliegt, wie es bei Microsoft der Fall ist. Ständig versuchen Menschen mit schlechten Absichten, Sicherheitslücken in den Betriebssystemen und Anwendungen von Microsoft ausfindig zu machen. Und genau aus diesem Grund kann Microsoft sich keine Sekunde zurücklehnen, während es seine Produkte und Dienstleitungen sicherer macht.
Mit der Kombination aus SharePoint und Azure erreicht man zum einen die Unabhängigkeit des Datenformats und zum anderen einen kontrollierten einfachen Zugangs für externe und Partner.
Sehen Sie auch:
1) Dokumentenspeicherung in der Windows Azure Cloud
2) SharePoint Cloud Archive
3) Microsoft übernimmt Führung beim Datenschutz
Das ist natürlich nur die erste Dimension des Problems. Weiter könnte man fragen: Wie sollte man eigentlich mit externen Zugriffen umgehen? Soll ich meinen Partnern und Kunden Zugriff auf das Unternehmensnetzwerk und Zugriff auf SharePoint gewähren? Oder erstelle ich jetzt wieder eine Applikation, die sich um den Export aus dem SharePoint kümmert, um das Ganze dann möglicherweise in eine Dritt-Anwendung zu importieren?
Für uns hat sich folgende Antwort auf die beiden skizzierten (bewusst überzeichneten) Szenarien bewährt. Zum einem ist unser Ziel, dass die Daten in einem für alle zugänglichen Format vorliegen, das unabhängig vom Datenbank-Schema des SharePoint ist. Um dieses Ziel zu erreichen, nutzen wir die SQL Remote BLOB Storage (RBS) Schnittstelle, um die binären Daten an eine für uns sinnvolle Stelle zu schreiben. Zum anderen erhalten alle BLOBs ihre zugehörigen Metadaten im XML-Format beigelegt, so dass am Ende der Informationsgehalt meiner Daten unverändert bleibt. Das Schöne an RBS ist, dass der SharePoint davon nichts mitbekommt und die Daten nun über zwei Wege erreichbar sind: SharePoint + Datenablage.
Konsequent zu Ende gedacht macht das Ganze nur dann wirklich Sinn, wenn so auch Externen die Möglichkeit gegeben wird, ohne Hürden auf die Daten zuzugreifen und ohne einen direkten Zugriff in das Unternehmensnetzwerk zu benötigen. Unsere Antwort darauf ist Azure. Vermutlich gibt es kein Unternehmen, das einem derartig permanenten Sicherheitsstresstest unterliegt, wie es bei Microsoft der Fall ist. Ständig versuchen Menschen mit schlechten Absichten, Sicherheitslücken in den Betriebssystemen und Anwendungen von Microsoft ausfindig zu machen. Und genau aus diesem Grund kann Microsoft sich keine Sekunde zurücklehnen, während es seine Produkte und Dienstleitungen sicherer macht.
Mit der Kombination aus SharePoint und Azure erreicht man zum einen die Unabhängigkeit des Datenformats und zum anderen einen kontrollierten einfachen Zugangs für externe und Partner.
Sehen Sie auch:
1) Dokumentenspeicherung in der Windows Azure Cloud
2) SharePoint Cloud Archive
3) Microsoft übernimmt Führung beim Datenschutz