Einsatz des SharePoint-Frameworks in Unternehmen

Home/SharePoint/Einsatz des SharePoint-Frameworks in Unternehmen

Einsatz des SharePoint-Frameworks in Unternehmen

Die erste Frage, die man sich im Rahmen der Planung von Lösungen für Unternehmen mit Bezug auf das SharePoint-Framework (SPFx) stellen sollte, lautet: Lohnt es sich bzw. macht es Sinn, das SPFx schon produktiv einzusetzen? Die Antwort darauf ist ganz klar noch nicht klar: Es kommt darauf an. Dies soll kurz erläutert werden.

Das SPFx ist für die allgemeine Verfügbarkeit und den Einsatz in produktiven Umgebungen bereits am 23. Februar diesen Jahres freigegeben worden. Es bringt sehr viele Vorteile mit sich, wie z.B.:

  • SPFx-Lösungen werden als Webparts auf Office-365-Seiten bereitgestellt und können die Funktionalität von Seiten in sehr kleinem bis größerem Umfang erweitern
  • SPFx-Webparts können auf klassischen Webpartseiten, Veröffentlichungsseiten und auf modernen Seiten in Office 365 bereitgestellt werden
  • SPFx-Webparts sind clientseitig und können mit beliebigen Browser-Frameworks entwickelt werden (z.B. Angular oder React)
  • SPFx-Lösungen müssen, ähnlich wie SharePoint-Add-Ins, nur einmal in einem Office-365-Tenant bereitgestellt und genehmigt werden, damit jeder Benutzer sie auf seiner Website einbinden kann
  • SPFx-Webparts laufen im Kontext des aktuellen Benutzers
  • Unterstützung für Custom Actions und JSLink​ wurde als Developer Preview​ released

SPFx-Webparts können die allseits beliebte JavaScript-Einbettung per Skript-Editor-Webpart auf SharePoint-Seiten ersetzen. Diese ist zwar simpel und für Entwickler schnell umsetzbar, hat aber geringeren Wiederverwendungswert, da ein auf diese Weise eingebettetes Skript auf einer anderen Seite oder einer anderen Umgebung oftmals individuell angepasst werden muss vom Entwickler. Endanwender haben dabei kaum Konfigurationsmöglichkeiten. In SharePoint Online besteht auch die Gefahr, dass das Skript nach Updates durch Microsoft nicht mehr funktioniert, wenn bestimmte Abhängigkeiten bestehen. Das Skript-Editor-Webpart ist außerdem nur verfügbar, wenn benutzerdefiniertes Skript nicht in den Administrationseinstellungen gesperrt wurde.

Das SharePoint-Add-In-Model bietet bereits eine Lösung für diese Probleme. Damit lassen sich mit einem gewissen Aufwand leicht wieder verwendbare SharePoint-Lösungen erstellen, die sowohl in On-Premise-Umgebungen als auch in Office 365 bereitgestellt werden können und bei Bedarf Konfigurationsmöglichkeiten für die Endanwender bieten. Allerdings laufen SharePoint-Add-Ins in einem iFrame und sind dadurch potenziell langsamer als Skripte in einem Skript-Editor-Webpart. Für ein optimal an die SharePoint-Website angepasstes Design ist somit auch ein gewisser Aufwand nötig.

Das SPFx bietet dagegen wiederverwendbare, leicht für Endanwender konfigurierbare, performante und leichtgewichtige Webparts, die sich mit sehr überschaubarem Aufwand an das individuelle Seitendesign anpassen lassen. Es ist als Alternative zum Add-In-Model anzusehen. Dennoch gibt es Einstiegshürden für Entwickler, wenn diese von der JavaScript-Einbettung oder SharePoint-Add-Ins auf das SPFx wechseln und bisher wenig Erfahrung haben mit typischen Open-Source-Webentwicklungstools wie den Node Package Manager, Node.js, Gulp oder Webpack. Entwickler sollten auch vertraut mit TypeScript sein bzw. sich darin einarbeiten können. Besonders am Anfang können somit Mehraufwände für die Einarbeitung entstehen.

Solche Mehraufwände lassen sich leicht rechtfertigen, wenn man langfristig mit der Entwicklung von SPFx-Webparts für Kunden einen lukrativen Weg gehen kann. Um dies zu evaluieren, müssen die aktuellen Nachteile bzw. noch fehlenden Features des SPFx betrachtet werden (Stand Mai 2017). Folgende lassen sich dabei aufzählen:

  • SharePoint On-Premise wird noch nicht unterstützt
  • Anzahl an Quellen für die Entwicklung ist noch sehr überschaubar, was insbesondere die Entwicklung komplexerer Lösungen schwierig machen kann
  • Bugs können immer wieder mal auftreten bzw. entdeckt werden, da das SPFx bislang nur in der ersten Version vorhanden ist
  • Assets der SPFx-Lösungspakete wie JavaScript- und Lokalisierungsdateien müssen für die Bereitstellung zentral (in einem öffentlichen CDN oder innerhalb des Office-365-Tenants des Kunden) hinterlegt werden (ggf. muss deshalb die SPFx-Lösung für jeden Kunden zunächst einmal paketiert werden)

Der letzte Punkt ist durch die generelle Architektur von SPFx-Webparts begründet und bringt weitere Betrachtungen mit sich, wie z.B. wo die Assets langfristig für einen Kunden gespeichert werden sollen und ob extern geladene Ressourcen (wie JavaScript-Frameworks) im Tenant des Kunden genutzt werden dürfen. Dabei sollte auch bedacht werden, dass SPFx-Lösungen als Full-Trust-Lösungen im Tenant laufen.

Wenn die Nachteile bzw. fehlenden Features des SPFx keinen Show-Stopper bei der Entwicklung einer Lösung für einen Kunden darstellen, sollte das SPFx ernsthaft in Betracht gezogen werden. Einige Punkte sprechen sehr stark für das SPFx. Insbesondere kleinere Lösungen, welche lediglich die Funktionalität bestimmter Seiten in Office 365 erweitern sollen, lassen sich mit dem SPFx sehr gut umsetzen. Für Modern Sites ist das SPFx auf jeden Fall eine sehr gute Lösung, da hier keine Skript-Editor-Webparts genutzt werden können. Auch für mobile Oberflächen sollte das SPFx in Erwägung gezogen werden.

Dennoch sollte stets ein Auge auf die aktuellen Entwicklungen in Bezug auf das SPFx geworfen werden. Es ist nicht auszuschließen, dass bestimmte Verkettungen von Updates in Office 365 und im SPFx dazu führen, dass bestimmte Features in zuvor entwickelten SPFx-Webparts nicht mehr wie gewohnt funktionieren. Da das SPFx ständig weiterentwickelt wird und von Microsoft als offizielles Framework für die clientseitige Entwicklung für SharePoint Online ausgewiesen wird, kann man davon ausgehen, dass die Kompatibilität zwischen dem SPFx und Office 365 langfristig gegeben ist. Sicherheitshalber sollte man sich darauf einstellen, dass ein einmal entwickeltes SPFx-Webpart im Laufe der Zeit evtl. nochmal angepasst werden muss, weil es bestimmte Updates gegeben hat.​

Die stetige Weiterentwicklung des SPFx und anderer entwicklungstechnischen Komponenten von SharePoint und Office 365 lässt sich gut verfolgen und auf Basis der aktuellen Roadmap des SPFx lassen sich die künftigen Verbesserungen erahnen. Von Microsoft werden außerdem ausführliche Hilfestellungen​ bereitgestellt, um den Einsatz vom SPFx in Unternehmen evaluieren zu können. Zumindest der Evaluierung des SPFx für den produktiven Einsatz sollte damit nichts mehr im Wege stehen.

By | 2017-06-14T09:28:50+00:00 May 15th, 2017|SharePoint|0 Comments

About the Author:

Technology Specialist

Leave a Reply

%d bloggers like this: