© best_vector/Shutterstock.com
Kolumne: SharePoint ganz praktisch

Kolumne: SharePoint ganz praktisch


Neben dem serverseitigen Objektmodell, das bereits in früheren Ausgaben dieser Kolumne behandelt wurde, bietet SharePoint auch schon seit Längerem ein JavaScript-API. Es ermöglicht den einfachen Zugriff auf SharePoint-Informationen über eine JavaScript-Schnittstelle.

Der Zugriff auf in SharePoint gespeicherte Daten via JavaScript ist schon seit frühen SharePoint-Server-Versionen möglich. Dennoch wurde zu Beginn der ersten SharePoint-Server-Versionen die serverseitige Schnittstelle und somit das serverseitige Objektmodell von Microsoft bevorzugt erweitert. Mithilfe der serverseitigen Schnittstelle kann SharePoint sehr schnell um eigene Funktionalitäten erweitert werden. Typische Erweiterungen sind kundenspezifische Web Parts, Ereignisempfänger, Seitenvorlagen usw. Bei der Verwendung der serverseitigen Schnittstelle muss allerdings der eigene Code zwingend auf 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 Web Part einen Laufzeitfehler, kann dadurch der betroffene Web-Frontend-Server im schlimmsten Fall Probleme bekommen. Dies ist oft der Fall, wenn das Dispose-Pattern für SharePoint-Objekte nicht befolgt wurde und dadurch Speicherprobleme entstehen. Da solche Fehler in fremden Erweiterungen die SharePoint-Infrastruktur gefährden, hat Microsoft Wege gesucht, diese Gefahren zu minimieren. Mit SharePoint Server 2010 wurde dazu das Sandkastenmodell (Sandbox Solutions) eingeführt. Es 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 und die SharePoint-Farm bleibt 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

Das clientseitige Objektmodell bietet Zugriff auf SharePoint von ...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang