Einstieg und Wechsel auf Office 365 - SharePoint

Mit der Einführung der Cloud-Plattform Office 365 hat Microsoft vor einigen Jahren die strategische Ausrichtung verfestigt. Der Schwerpunkt neuer Produkte und Innovationen findet im Web statt. Auch wenn die On-Premise Office Produkte - wie SharePoint, Exchange & Co. - weiterhin angeboten und unterstützt werden, ist nicht klar wie lange ein Support noch gewährleistet ist. Viele Unternehmen schwenken daher auf die Cloud-Varianten um. Ich habe in den letzten 20 Jahren im Schwerpunkt, neben klassischen Web-Anwendungen, viele SharePoint Lösungen für den SharePoint Server umgesetzt. Der SharePoint Server stellt für die Umsetzung von Geschäftsprozess-Anwendungen eine ideale Plattform dar. In vielen Unternehmen kommt der SharePoint Server als Intranet-Plattform zum Einsatz und ist somit überall am Arbeitsplatz erreichbar. Daher eignet sich die Plattform sehr gut, um eigene Funktionalitäten über diese Infrastruktur zu verteilen. Der lokale SharePoint Server bietet für den Entwickler viele Erweiterungspunkte, wie zum Beispiel:

• WebParts
• Ereignisempfänger
• Workflows
• Menüband/Ribbon (Custom Actions)
• Zeitgeberdienste (Timer Jobs)
• Anwendungsseiten
• Inhaltstypen (Content Types)
• Spalten/Felder (Custom Fields)
• Ausgabevorlagen (Rendering Templates)
• Clientseitige Anzeigevorlagen (Display Templates)
• SharePoints Apps (App-Model)
• Layout: Seitenvorlagen und Gestaltungsvorlagen (MasterPages), Themes
• Anwendungsdienste (Suche, Taxonomie, Word etc.)
• PowerShell Scripting

Da viele der oben genannten Erweiterungen jedoch serverseitige auf den Rechnern der SharePoint-Farm ausgeführt werden, führte diese Architektur teilweise zu Problemen. Mithilfe der verfügbaren serverseitigen Schnittstellen (API) kann SharePoint sehr schnell um eigene Funktionalitäten erweitert werden. Typische Erweiterungen sind kundenspezifische WebParts, Ereignisempfänger, Seitenvorlagen usw. Bei der Verwendung der serverseitigen Schnittstelle muss allerdings der eigene Code zwingend auf einem SharePoint-Server ausgeführt werden. Somit besteht ein hohes Risiko, die Stabilität der SharePoint-Farm zu gefährden, da eigene Erweiterungen potenzielle Fehler enthalten könnten. Produziert zum Beispiel ein fremdes WebPart einen Laufzeitfehler, kann dadurch der betroffene Web-Frontend-Server im schlimmsten Fall Probleme bekommen. Dies kann dann dazu führen, dass die gesamte SharePoint Seite nicht mehr abrufbar ist.

Microsoft hat verschiedene Ansätze verfolgt, zum Beispiel mit den Sandkastenmodell (Sandbox Solutions), um solche Probleme zu vermeiden. Mit dem SharePoint-Server 2010 wurde dieses neue Prozessmodell (Sandbox Solutions) eingeführt. Das Sandkastenmodell führt einen serverseitigen Code von eigenen Erweiterungen innerhalb eines geschützten Prozessraums aus. Tritt innerhalb dieses separierten Prozessraums ein Fehler auf, so ist nur dieser Prozess betroffen. Die SharePoint-Farm bleibt somit stabil. Allerdings hat das Sandkastenmodell einige Beschränkungen und wurde nicht von allen Entwicklern stringent verwendet bzw. angenommen. Microsoft suchte daher nach weiteren Wegen, um die Ausführung eines Codes von der SharePoint-Farm auf andere – nicht zur SharePoint-Farm gehörende Server – zu verschieben. Die gefundene Lösung dazu findet sich in dem clientseitigen Objektmodell – kurz CSOM – wieder. Für den Entwickler bietet das clientseitige Objektmodell zusätzlich den wesentlichen Vorteil, dass für die Entwicklung kein SharePoint-Server auf der Entwicklermaschine betrieben werden muss. Das clientseitige Objektmodell bietet einen Zugriff auf SharePoint von jedem beliebigen Rechner aus.

Und in der Cloud?

Die meisten der in der Vergangenheit verwendeten Erweiterungsmethodiken, die bei lokal installierten SharePoint Farmen via voll-vertrauenswürdigen Farm-Lösungen (Full-trust Solutions) möglich waren, stehen bei SharePoint Online nicht mehr zur Verfügung. SharePoint Online wird von Microsoft als sog. Multi-Tenant SaaS System betrieben. Somit besteht kein direkter Zugriff mehr auf die Hardware sowie auf die Systemkonfiguration. Eigene serverseitige Lösungen (WSP-Pakete), können nicht installiert und betrieben werden.

Dennoch ermöglicht auch SharePoint Online die Einbringung eigener Funktionalitäten. Die Lösungsmodelle haben sich geändert, sind aber so flexibel, dass alle eigenen Anforderungen - die nicht mit den Standardfunktionen realisiert werden können - umgesetzt werden können.

Auf meinen neuen Blog werde ich zu diesen Möglichkeiten und zu anderen Office 365 Themen kontinuierlich berichten.