SharePoint Framework Enterprise-Leitfaden

Das SharePoint-Framework (SPFx) ist ein neues Entwicklungsmodell für die Erweiterbarkeit der SharePoint-Benutzeroberfläche. Es wird von Erst- und Drittanbietern verwendet und ergänzt vorhandene Anpassungs- und Erweiterbarkeitsoptionen wie das SharePoint-Add-In-Modell. Die SharePoint-Framework ermöglicht einen strukturierten und unterstützten Ansatz zur Anreicherung und Erweiterung der Benutzeroberfläche von SharePoint mithilfe clientseitiger Frameworks. Basierend auf modernen Webstandards bietet es einen einzigartigen Satz von Features, um SharePoint-Anpassungen für Entwickler und Unternehmen allgemein verfügbar zu machen, aber gleichzeitig an früheren Modellen und Mustern in SharePoint ausgerichtet. Auf dieser Seite bieten wir Administratoren den Hintergrund, die Vorteile und das Wissen, die sie benötigen, um SharePoint-Framework-basierten Komponenten in ihren SharePoint-Umgebungen erfolgreich zu verwalten.

Hintergrund

SharePoint wird schon lange als Anwendungs- und Entwicklungsplattform verwendet und bietet viele Sätze von Entwicklungs- und Anpassungsoptionen – von voll vertrauenswürdiger Codeausführung auf den SharePoint-Servern über Sandkastenlösungen und Add-Ins bis hin zu Benutzeroberflächenanpassungen mit direkt verfügbaren Features oder per Einbettung von JavaScript/CSS.

Im mehrinstanzenfähigen SharePoint Online wurde voll vertrauenswürdiger Code nie unterstützt, und der Sandkasten-Codedienst ist veraltet. Die gängigsten Muster für Anpassungen von SharePoint Online waren Add-Ins, Remotecodeausführung (Codeausführung an anderer Stelle, z. B. in Azure) über die Standard-APIs und JavaScript-Einbettung. Obwohl die JavaScript-Einbettung eine leistungsfähige Möglichkeit zur Erweiterung von SharePoint war, erwies es sich für das Konzept als schwierig, mit der ständigen Weiterentwicklung des beliebten Modells von SharePoint Online Schritt zu halten. Das SharePoint-Framework soll diese Probleme lösen, indem es ein standardisiertes Framework für die Erstellung benutzerdefinierter Benutzeroberflächenerweiterungen und unterstützter, zukunftsfähiger Anwendungen auf SharePoint Online-Basis bereitstellt.

Das SharePoint-Framework erweitert die SharePoint-Framework-Benutzeroberfläche um Clientseitige Webparts und Erweiterungen.

Clientseitige Webparts

Die clientseitigen Webparts implementieren das bekannte Paradigma von Webparts, was über die Jahre hinweg einer der Erfolgsfaktoren von SharePoint war. Sie können Seiten hinzugefügt und von den Endbenutzern selbständig angepasst werden. Diese clientseitigen Webparts funktionieren auf den neuen modernen Seiten und auf den klassischen Seiten und sogar in der mobilen SharePoint-App.

Hinweis

Weitere Informationen finden Sie unter Übersicht über clientseitige SharePoint-Webparts.

Erweiterungen

SPFx-Erweiterungen ermöglichen es den Entwicklern bestimmte Anpassungen von Benutzeroberflächen in der „modernen“ Erfahrung zu implementieren, die in der „klassischen“ SharePoint-Erfahrung möglich waren. Entwickler können jeder Seite JavaScript hinzufügen, Kopf- und Fußzeilen hinzufügen, Menüelemente einer Liste und Bibliotheken hinzufügen, und die Ansicht eines Felds in einer Liste anpassen.

Entwicklungsmodell und -Tools

Das SharePoint-Framework wird von Grund auf mithilfe von einem modernen, webstapelbasierten TypeScript, JavaScript, HTML und CSS. Alle Bestandteile der generierten Artefakte werden im Browser des Endbenutzers ausgeführt. Das SharePoint-Framework verfügt außerdem über einen neuen Satz an Tools. Diese neuen Tools sind plattformunabhängig, funktionieren auf Windows, macOS, Linux und basieren auf Open-Source-Technologien wie Node.js, Gulp, Webpack und Yeoman. Diese Frameworks und Tools werden zur Erstellungszeit verwendet, um die Entwicklerumgebung zum Erstellen, Packen und Bereitstellen zu optimieren. Für die tatsächliche Ausführung des SharePoint-Framework-Codes sind sie nicht erforderlich.

Aktueller Status des SharePoint-Frameworks

Das SharePoint-Framework wurde für SharePoint Online im Februar 2017 veröffentlicht. Die neueste Version sowie alle vorherigen Versionen von SharePoint Framework werden in SharePoint Online gehostet und sind dort verfügbar.

Das SharePoint-Framework ist ebenfalls für SharePoint Server 2016 (mit dem Feature Pack 2) als Version v1.1 und für SharePoint Server 2019 als Version v1.4.1 verfügbar.

Die Entwicklerperspektive

Neue wie auch erfahrene SharePoint-Entwickler profitieren vom SharePoint-Framework. Es ermöglicht dem Entwickler die Benutzeroberflächenfunktionen von SharePoint auf eine sichere und strukturierte Weise mithilfe von clientseitigen Komponenten zu erweitern. Diese Komponenten werden clientseitig ausgeführt und können Daten aus SharePoint, aus Microsoft 365 über Microsoft Graph oder auch aus benutzerdefinierten Web-APIs abrufen, die standardmäßige OAuth- und REST-Methoden verwenden.

Erfahrene SharePoint-Entwickler sind mit Konzepten wie Webparts und dem SharePoint-Datenmodell bereits vertraut. Die Tools zum Erstellen, Packen und Bereitstellen clientseitiger Webparts sind jedoch neu. Entwickler müssen insbesondere Kenntnisse in TypeScript erwerben, der primären Sprache für die Entwicklung von SharePoint-Framework-Artefakten. TypeScript bietet mehrere Vorteile gegenüber JavaScript, die wichtig für die Entwicklung in Enterprise-Umgebungen sind, z. B. stark typisierte Objekte, Objektvererbung, Klassen und Schnittstellen und Konzepte. Java-, .NET- und C/C++-Entwickler sollten heute mit all diesen Konzepten vertraut sein. Bezüglich der Erstellung und Verpackung stellt Visual Studio für Entwickler nicht mehr die einzige Option zum Programmieren von SharePoint-Lösungen dar. Dank der Verwendung von Open-Source-Technologien und Projekten wie node.js, npm und Gulp kann die Entwicklung im SharePoint-Framework auf jeder beliebigen Plattform erfolgen, mit dem Code-Editor oder der IDE, die der Entwickler bevorzugt (beispielsweise Visual Studio Code, Sublime oder sogar Notepad).

Für Entwickler, die vorher noch nie SharePoint-Lösungen erstellt haben, die aber mit modernen Webtechnologien vertraut sind, gibt es keine signifikante Lernkurve. Viele Entwickler haben bereits zur clientseitigen Entwicklung oder einer Kombination davon gewechselt. Die clientseitige Entwicklung ermöglicht eine bessere, dynamischere und reaktionsfähigere Oberfläche für Benutzer und auch eine einfachere Umgebung für Entwickler. Dank der freien Wahl des Code-Editors und der Verwendung gängiger Open-Source-Frameworks und -Technologien können viele Entwickler, die möglicherweise noch gar nicht innerhalb des Microsoft-Ökosystems gearbeitet haben, leicht den Einstieg in die Erstellung von SharePoint-Erweiterungen finden.

Eines der meistverwendeten Muster bei der SharePoint Online-Erweiterung war die JavaScript-Einbettung (auch als JavaScript-Einfügung bezeichnet). Bei dieser Methode verwenden Sie z. B. das Skript-Editor-Webpart, um beliebigen JavaScript-Code auf der Seite einzufügen, und fügen dann per DOM (Document Object Model)-Manipulation im Webbrowser HTML, CSS und JavaScript ein, um eine Lösung oder Anwendung zu erstellen. Diese Methode hat viele Nachteile. Aufgrund ihrer strikten Abhängigkeit vom Aufbau der HTML- und CSS-Struktur in SharePoint führt sie sogar häufig dazu, dass Kunden die neuen Features in SharePoint Online nicht nutzen können. Das SharePoint-Framework ist eine bessere Möglichkeit, Anpassungen auf Basis von JavaScript-Einbettung zu implementieren, wenn auch noch kein vollständiger Ersatz. Das SharePoint-Framework verwendet wie bereits erwähnt TypeScript, das einen relativ einfachen Übergang von JavaScript-Einbettungen zu einer standardisierten und zukunftssicheren Lösung ermöglicht. Die OfficeDev PnP-Initiative bietet zudem Beispielprojekte und Richtlinien für diesen Übergang.

Perspektive: das SharePoint-Framework in der umfassenderen SharePoint-Plattform

Das SharePoint-Framework ist ein neues Modell, das die bereits vorhandenen Methoden ergänzt, jedoch den Fokus auf Benutzeroberflächenanpassungen mit größerem Mehrwert setzt, wie z. B. auf clientseitige Webparts. Dieses Framework ist darauf ausgelegt, in Verbindung mit vorhandenen funktionierenden Modellen eingesetzt zu werden, und erleichtert die Erstellung neuer Benutzeroberflächenanpassungen in einer besser unterstützten und nachhaltigeren Weise.

Wichtig

Die Microsoft Office SharePoint Online-Seite HTML DOM ist keine API. Sie sollten vermeiden, Abhängigkeiten der Seiten-DOM-Struktur oder der CSS-Formatvorlagen zu übernehmen, die Veränderungen unterliegen und Ihre Lösungen möglicherweise unterbrechen. SharePoint-Framework bietet eine umfangreiche API, um die SharePoint-Umgebung auf zuverlässige Weise anzupassen, und ist die einzige unterstützte Methode für die Interaktion mit dem HTML-DOM der SharePoint-Seite.

Vergleich mit Add-Ins

SharePoint-Add-Ins, die in SharePoint 2013 als SharePoint-Apps eingeführt und später umbenannt wurden, waren eine der Optionen zum unterstützten und gesteuerten Hinzufügen von Anpassungen zu SharePoint Online. SharePoint-Add-Ins erfordern jedoch wesentlich mehr Infrastruktur, als in vielen Fällen tatsächlich nötig wäre, in denen eine einfache Anpassung der Benutzeroberfläche erforderlich ist.

Es gibt zwei Arten von SharePoint-Add-Ins: SharePoint-gehostete Add-Ins und anbietergehostete Add-Ins. SharePoint-gehostete Add-Ins waren eine der Möglichkeiten zur unterstützten Ausführung von clientseitigem Code in SharePoint, erfordern jedoch wie bereits erwähnt wesentlich mehr Aufwand als nötig, um ein einfaches clientseitiges (JavaScript-)Webpart einzufügen. In vielen Fällen wurden SharePoint-gehostete Add-Ins nur erstellt, um Artefakte wie Listen und Webparts auf einer SharePoint-Website bereitzustellen. Diese Add-Ins befinden sich im sogenannten App-Web, einer speziellen Website mit begrenzten Features.

Anbietergehostete Add-Ins werden remote von SharePoint (Online) ausgeführt und können serverseitigen Code und clientseitigen Code nutzen. Dies hat einen Vorteil für unabhängige Softwarehersteller, die ihr geistiges Eigentum/ihren Code/ihre Logik schützen möchten, und für Szenarien, die nicht clientseitig mit JavaScript ausgeführt werden können. Dies gilt z. B. für rechenintensive Vorgänge mit langer Ausführungszeit oder Zugriffe auf Remotedaten, die nicht mit clientseitigen Skripts ausgeführt werden können.

Der größte Vorteil von Add-Ins ist die Isolierung: Da der eigentliche Code nicht auf der SharePoint-Website ausgeführt wird, verhindert der Schutz des Browsers vor websiteübergreifendem Scripting, dass das Add-In dieselben Zugriffsrechte wie der Benutzer erhält. Add-Ins sind auf die Berechtigungen beschränkt, die ihnen zur Installationszeit erteilt wurden. Dies macht Add-Ins zu einer sichereren Option für Szenarien, in denen ein Administrator ein Add-In eines Drittanbieters erwirbt, und es ermöglicht Microsoft die Einrichtung eines Stores, aus dem Sie Add-Ins herunterladen können.

Das SharePoint-Framework funktioniert parallel mit SharePoint-gehosteten und anbietergehosteten Add-Ins, kann aber auch als Alternative verwendet werden, wenn nur clientseitige Skripts erforderlich sind. Beispielsweise können Add-Ins App-Webparts zu der Website hinzufügen, auf der sie gehostet werden. Diese App-Webparts ähneln Webparts, werden aber statt im Kontext der Seite in ihrer eigenen Domäne (App-Web oder anbietergehostetes Web) in einem iFrame auf der Seite ausgeführt. Dies verhindert, dass das Add-In den Benutzerkontext vom Rest der Seite übernimmt.

Das SharePoint-Framework wird nicht in einem iFrame ausgeführt. Auf diese Weise kann es nahtloser im Kontext der Seite ausgeführt werden, mit dem ganzen Leistungsumfang des Benutzers, der das Webpart anzeigt. Dieser Umstand macht es möglich, dass Webparts mit einem großen Funktionsumfang ausgeführt werden können. Andererseits bedeutet er auch, dass nicht dieselben Sicherheitskontrollen zur Verfügung stehen wie bei Add-Ins. SharePoint-Framework-Lösungen werden daher auch als voll vertrauenswürdige clientseitige Lösungen bezeichnet. Bei iFrames besteht das Problem, dass sie nicht reaktionsfähig sind, sodass die gerenderte Webseite auf einem Mobiltelefon oder bei einer anderen Bildschirmgröße nicht so flüssig dargestellt wird.

Für SharePoint-Framework-Lösungen gibt es zum Zeitpunkt der Erstellung dieses Artikels aus den genannten Sicherheitsgründen keinen Store, aus dem Sie Lösungen herunterladen und installieren können. Die Verwendung des Benutzerkontexts ist häufig ein gewünschtes Szenario, in dem stattdessen das SharePoint-Framework verwendet werden kann.

Einbetten von JavaScript in HTML

Eine der gängigen Vorgehensweisen von Entwicklern bestand in einer Methode namens „Einbetten von JavaScript“ (auch als „JavaScript-Einfügung“ bezeichnet). Das bedeutet, dass beliebiger JavaScript-Code auf den Websites und Seiten eingefügt wurde, z. B. in Gestalt von benutzerdefinierten Aktionen, Gestaltungsvorlagen oder Seitenlayouts und sogar Skript-Editor-Webparts. Diese Methode hat sich als einfacher als das Erstellen von SharePoint-gehosteten Add-Ins erwiesen und ermöglicht es außerdem, den Skriptcode im vollständigen Kontext der Benutzer auszuführen. Daher wurde sie sehr populär. Der Nachteil dieses Ansatzes ist, dass viele dieser Einbettungen auf DOM-Manipulation beruhten und ihre Erstellung und Pflege vom Benutzer einiges Fachwissen erforderten.

Aufgrund der andauernden Beliebtheit von SharePoint Online konnten diese mit dem Einbetten von JavaScript erstellten Lösungen bei jedem Update von SharePoint Online unbrauchbar werden, da die Entwickler möglicherweise Abhängigkeiten (auch unbeabsichtigt) von der Struktur oder Formatierung der SharePoint-Seiten verwendeten. Wenn Updates in SharePoint ausgeführt werden, auch Nebenversionen und geringfügige Updates, kann dies große Auswirkungen auf diese Lösungen haben und dazu führen, dass das eingebettete JavaScript nicht mehr ausgeführt werden kann.

Mit dem SharePoint-Framework steht nun eine von Microsoft standardisierte und unterstützte Möglichkeit zur Verfügung, um viele dieser zuvor mit JavaScript-Einbettungen erstellten Lösungen zu realisieren.

Skript-Editor-Webparts

Am häufigsten wird zum Einfügen von beliebigen HTML-, JavaScript- oder CSS-Anpassungen in SharePoint das Skript-Editor-Webpart oder das Inhalts-Editor-Webpart verwendet. Skript-Editor-Webparts sind beliebt, weil es mit ihnen so einfach ist, benutzerdefinierte Skripts zu jeder beliebigen Seite hinzuzufügen. Jeder Bearbeiter einer Website kann ein Skript-Editor-Webpart zu einer Seite hinzufügen, JavaScript-Code kopieren und dort einfügen, und diesen JavaScript-Code die notwendigen Anpassungen ausführen lassen. Wie bei JavaScript-Einbettungen kann es eine Herausforderung für Administratoren darstellen, die Kontrolle über Skript-Editor-Webparts zu behalten.

Das SharePoint-Framework kann in vielen Fällen ein direkter Ersatz für solche Konfigurationen mit Skript-Editor-Webparts sein.

Steuerung von Skriptfunktionen in SharePoint Online

SharePoint Online ermöglicht Administratoren die Steuerung der Möglichkeit, Websites und Seiten benutzerdefinierte Skripts hinzufügen, um die Sicherheit und Integrität des Mandanten zu erhöhen. Dies geschieht mithilfe des Features „Benutzerdefiniertes Skript“ auf der SharePoint Online-Verwaltungswebsite oder einzeln pro Website mithilfe von PowerShell.

Benutzerdefinierte Skripts können auf allen Websites oder nur auf persönlichen Websites deaktiviert werden. Standardmäßig ist für neue Mandanten das Scripting auf persönlichen Websites, auf allen per Self-Service erstellten Websites und in der Stammwebsitesammlung des Mandanten deaktiviert.

Wenn benutzerdefinierte Skripts deaktiviert sind, können Bearbeiter von Websites keine Webparts wie das Skript-Editor-Webpart hinzufügen. Jedoch sind SharePoint-Framework-Lösungen zulässig, da diese als sicher gelten, sobald sie von einem Administrator im App-Katalog genehmigt wurden.

Unterschiede bei der Erstellung von SharePoint-Framework-Lösungen und ihre Bedeutung

Dem SharePoint-Framework liegt ein neues Paradigma für SharePoint-Entwickler beim Entwerfen, Erstellen und Bereitstellen von SharePoint-Anpassungen zugrunde, das einen modernen Webstapelansatz verwendet und auf clientseitige/browserbasierte Anpassungen konzentriert ist.

Dies ist eine wichtige Wende bei der Behandlung der SharePoint-Entwicklung.

Durch die Verwendung von Technologien und Frameworks wie beispielsweise TypeScript, Node.js, Yeoman und Gulp zieht das SharePoint-Framework Entwickler an, die bisher noch nicht im SharePoint-Ökosystem gearbeitet haben, vielleicht sogar nicht einmal im Microsoft-Ökosystem. Gleichzeitig soll es bestehenden SharePoint-Entwicklern das Erstellen von SharePoint-Anpassungen mit einem moderneren, standardisierten Ansatz erleichtern.

Erstellen von Lösungen

Aufgrund des Bedarfs an spezifischen und gezielten Tools, die über Visual Studio bereitgestellt werden, wurde die SharePoint-Entwicklung über Visual Studio in einer Windows-basierten Entwicklungsumgebung mit einer lokal installierten und konfigurierten Instanz von SharePoint ausgeführt. Dadurch wurden die Hardware- und Benutzereinstellungen eingeschränkt und die Entwicklungskosten erhöht. Das SharePoint-Framework verwendet dagegen verschiedene gängige Open-Source-Webtools, die für eine Reihe von Plattformen wie z. B. macOS und Linux verfügbar sind, um größere Flexibilität bei der Entwicklung zu ermöglichen.

SharePoint-Framework-Lösungen werden mit einer Kombination aus einem Tool namens Yeoman und einem spezifischen SharePoint-Framework-Generator erstellt, der auf Node.js basiert. Yeoman ist ein Tool zum Erstellen eines Projektgerüsts. Es erstellt das Projekt und generiert die erforderlichen Artefakte, installiert die benötigten Node.js-Pakete und konfiguriert das Buildsystem.

Nachdem das Projekt generiert wurde, kann es in einem beliebigen Editor unter einem beliebigen Betriebssystem bearbeitet werden: z. B. in Visual Studio, Visual Studio Code, Sublime oder Atom. Dadurch wird eine größere Vielfalt in Nutzungsverhalten und Stilen in und zwischen Teams ermöglicht. Der Yeoman-Generator kann mehrfach für dasselbe Projekt ausgeführt werden, um zusätzliche Artefakte hinzuzufügen, z. B. clientseitige Webparts.

Entwickeln und Erstellen von Lösungen

Das Buildsystem basiert auf Gulp. Gulp ist ein Tool zur Aufgabenausführung, das die SharePoint-Framework-Artefakte erstellt, verpackt und optional auch bereitstellt. Wie Yeoman basiert auch Gulp auf Node.js und ermöglicht Entwicklern das Erstellen und Bereitstellen unter jedem beliebigen Betriebssystem.

Eine Komponente des Buildtoolsets für das SharePoint-Framework ist die Workbench. Die Workbench ist ein Tool, mit dem der Entwickler seine SharePoint-Framework-Lösung hosten und testen kann. Die Workbench ist reaktionsfähig und lädt die Artefakte automatisch neu, sobald der Entwickler eine Datei speichert, sodass er seine Lösungen schnell sehen und testen kann.

Es sind zwei Versionen des Beispiel-Add-Ins verfügbar. Eine Version ist außerhalb von SharePoint vorhanden und wird lokal auf dem Entwicklungscomputer gehostet, der offline ohne SharePoint-Zugriff und SharePoint-Daten ausgeführt wird. Mit dieser Version können Team und Designer Lösungen mit simulierten Daten oder Beispieldaten erstellen und entwerfen. Das erlaubt es ihnen, sich auf die Benutzeroberfläche zu konzentrieren.

Die andere Version von Workbench wird in SharePoint gehostet. Sie wird verwendet, wenn die SharePoint-Framework-Lösung mit realen SharePoint-Daten im realen SharePoint-Kontext getestet und überprüft werden muss.

Wichtig

Die lokale Workbench erfordert einen modernen, ständig erneuerten Webbrowser. Internet Explorer 11 wird von der lokalen Workbench nicht unterstützt.

Bereitstellen von SharePoint-Framework-Lösungen

Das Bereitstellen von SharePoint-Framework-Lösungen erfolgt durch das Bereitstellen eines Lösungspakets im App-Katalog und dessen Genehmigens für die Verwendung in Ihrer Mandanten- oder Websitesammlung.

Für Lösungen, die für SharePoint Online bereitgestellt werden, können Sie das von Microsoft 365 gehostete CDN für das Speichern und Bereitstellen der Artefakte in der Lösung verwenden, die zur Implementierung der clientseitigen Komponenten verwendet wird. Weitere Informationen finden Sie im Abschnitt Microsoft 365 öffentliches CDN.

Für Lösungen, die für SharePoint Server bereitgestellt werden, müssen Sie bestimmen, wo Ihre Artefakte gespeichert werden. Dies ist ein zusätzlicher Bereitstellungsschritt, der für SharePoint Online nicht erforderlich ist. Die einzige Voraussetzung ist, dass die Artefakte für die Benutzer Ihrer Lösung zugänglich sind.

Alternativen zum SharePoint Online-CDN

Entwickler einer SharePoint-Framework-Lösung können jeden beliebigen CDN-Dienst verwenden, z. B. Azure Storage, Azure CDN oder auch SharePoint selbst, bevorzugt mithilfe der Funktionen des SharePoint-CDN (siehe weiter unten in diesem Artikel). Bei Verwendung eines öffentlichen CDN, bei dem die im CDN bereitgestellten Objekte im Internet öffentlich verfügbar sind, kann die SharePoint-Framework-Lösung von vielen Mandanten verwendet werden. Bei einer im SharePoint-CDN bereitgestellten SharePoint-Framework-Lösung sind die bereitgestellten Skripts und Ressourcen nur für den Mandanten verfügbar, in dem die Lösung bereitgestellt wird.

Standardmäßig enthalten die Buildtools eine integrierte Aufgabe, die die gepackte Lösung in Azure Blob Storage bereitstellt. Dies wird in der Regel von Systemintegratoren oder ISVs erweitert, um benutzerdefinierte CDN-Speicherorte oder Konfigurationen zu unterstützen.

Nachdem Sie den Code geändert und die Projektmappe erstellt haben, erzeugt die SharePoint-Framework Toolkette ein neues Lösungspaket (*.sppkg) und eine Reihe von Skriptdateien. Diese Skriptdateien enthalten einen eindeutigen Hash im Dateinamen, welcher angibt, dass der Inhalt dieser Dateien von den zuvor bereitgestellten Versionen abweicht. Um eine neue Version der Lösung zu verwenden, müssen Sie die neuen Skripts im CDN bereitstellen und das Lösungspaket im App-Katalog aktualisieren. Theoretisch könnten Sie den Inhalt der vorhandenen Skriptdateien ersetzen, statt das Lösungspaket zu aktualisieren; dies ist jedoch unzuverlässig und wird nicht empfohlen. Je nach Konfiguration des CDN werden möglicherweise zuvor heruntergeladene Skriptdateien für längere Zeit auf den Clientcomputern zwischengespeichert, was das Rollout der Lösung für die Endbenutzer erschwert.

Der Speicherort des CDN ist wichtig. Der Speicherort, in dem die SharePoint-Framework-Objekte gehostet werden, muss hohe Verfügbarkeit bieten. Daher werden vertrauenswürdige CDN-Anbieter wie Azure, Akamai oder ähnliche sowie SharePoint selbst empfohlen. Unter Sicherheitsgesichtspunkten ist es wichtig zu wissen, welche CDNs von den bereitgestellten SharePoint-Framework-Lösungen verwendet werden. Ein fehlerhaftes CDN kann auch die SharePoint-Framework-Lösungen beeinträchtigen. Im schlimmsten Fall kann ein kompromittiertes CDN dazu führen, dass die Daten im SharePoint (Online)-Mandanten ebenfalls kompromittiert werden.

Bei der Genehmigung von SharePoint-Framework-Lösungen von Drittanbietern besteht ein übliches Checklistenelement in der Überprüfung des Zertifizierungsstatus und der Vertrauenswürdigkeit des CDN-Speicherorts sowie aller Drittanbieter, die sie hosten können. Denn nachdem die Anwendung installiert ist und in SharePoint-Websitesammlungen verwendet wird, gilt für die betreffenden Websitesammlungen eine Abhängigkeit von dem CDN-Speicherort. Derzeit gibt es keine einfache Möglichkeit, diesen Endpunkt zu kontrollieren. Der Drittanbieter des CDN kann über Updates ohne Wissen des Benutzers erwünschte ebenso wie unerwünschte Änderungen implementieren und so Angriffspunkte schaffen, da das SharePoint-Framework im Kontext des Benutzers ausgeführt wird und alle Aktionen ausführen kann, die dem Benutzer erlaubt sind.

IT-Administratoren wird empfohlen, nachzuverfolgen, welche CDNs verwendet werden und welche CDNs von der Organisation genehmigt wurden – diese Informationen sollten auch an die Entwickler im Unternehmen kommuniziert werden.

Das öffentliche Microsoft 365 CDN

Das öffentliche Microsoft 365-CDN ist ein neues Feature in Microsoft 365 und SharePoint Online, das es Administratoren ermöglicht, statische Objekte wie JavaScript-Dateien, Bilder und CSS-Formatvorlagen automatisch in einem CDN zu hosten, um die Leistung zu steigern. Das öffentliche Microsoft 365-CDN ist ein Feature für geografisch verteiltes Caching, das statische Objekte möglichst nahe an den Endbenutzerbrowsern zwischenspeichert, von denen sie angefordert werden.

Administratoren können das öffentliche Microsoft 365-CDN in einem oder mehreren designierten Dokumentbibliotheken aktivieren, die als Ursprung für die statischen Objekte dienen. Die Verwaltung der Bibliotheken und des CDN erfolgt mit SharePoint Online PowerShell-Cmdlets. Die Objekte in der Dokumentbibliothek werden in das Microsoft 365-CDN repliziert und sind dann über auf das öffentliche Microsoft 365-CDN weisende URLs zugänglich, die generiert und der Dokumentbibliothek zugeordnet werden. Alle Aktualisierungen an den Objekten werden innerhalb von 15 Minuten auf die CDN-Endpunkte übertragen. Alle Ressourcen stehen in den Dokumentbibliotheken über den CDN-Endpunkt für anonyme Benutzer zur Verfügung.

Das SharePoint-Framework im Unternehmen

SharePoint war und ist eine der erfolgreichsten Plattformen für die Zusammenarbeit im Unternehmen. Einer der Gründe für ihren Erfolg sind Erweiterbarkeitsoptionen und die Möglichkeit SharePoint als Plattform für Anwendungen und Integrationen zu verwenden. Das SharePoint-Framework wird diesen Erfolg fortsetzen, indem es SharePoint zu einer moderneren Plattform für die unterstützte und standardisierte Erstellung clientseitiger Anpassungen macht.

Enterprise-Entwickler

Das SharePoint-Framework ermöglicht es Enterprise-Entwicklern (in der Regel Entwickler von Anwendungen für den Einsatz in einer Organisation), SharePoint oder SharePoint Online in einer strukturierten und unterstützten Weise um neue Funktionen zu erweitern. Das SharePoint-Framework bietet alles Nötige, vom Entwicklungsframework über die Buildpipeline bis hin zu Funktionen für die eigentliche Bereitstellung, und ermöglicht es Entwicklern, in kurzer Zeit alle Websitesammlungen mit neuen Lösungen und Features zu erweitern, alles gesteuert durch den App-Katalog. In einem Unternehmensszenario haben Sie zudem volle Kontrolle über die CDN-Speicherorte (externe oder interne in SharePoint) und können leicht Fixes und Updates in der gesamten Organisation bereitstellen.

Innerhalb des Unternehmens sollten Administratoren und Entwickler gemeinsam eine Blaupause für die Bereitstellung von SharePoint-Framework-Lösungen erarbeiten. Die Blaupause sollte Details zu bevorzugten clientseitigen Frameworks, CDN-Speicherorten usw. enthalten.

Weitere Informationen finden Sie im Abschnitt Erstellen eines Plans für SharePoint Framework-Anpassungen.

Einzelentwickler

Einzelentwickler, auch Citizen Developers genannt, verwenden SharePoint schon seit Langem zur Erstellung von Geschäftsanwendungen. Dabei benutzen sie seit jeher eine Vielzahl unterschiedlicher Methoden und Techniken.

Das SharePoint-Framework wird für bestimmte Szenarien, insbesondere JavaScript-Einbettungen und Lösungen mit Skript-Editor-Webparts, einen großen Fortschritt bedeuten. Es wird diese Lösungen standardisierter machen und ihre Pflege langfristig vereinfachen. Für Einzelentwickler bedeutet es möglicherweise einen Einarbeitungsaufwand, sich an die neue strukturierte Art der Erstellung von Lösungen zu gewöhnen; sie wird sich jedoch langfristig als stabiler, sicherer und besser verwaltbar erweisen.

Wenn die oben genannten Steuerungsmethoden auf Basis des Features Benutzerdefiniertes Skript aktiviert sind, dürfen Einzelentwickler keinen beliebigen JavaScript-Code und keine Skript-Editor-Webparts hinzufügen. Dies kann Ihre SharePoint-Umgebung potenziell stabiler und besser verwaltbar machen, aber gleichzeitig die Innovationskraft in Ihrem Unternehmen hemmen. Sie sollten also dafür sorgen, dass sich Einzelentwickler in Ihrem Unternehmen hinsichtlich des Einsatzes des SharePoint-Frameworks mit Ihren Enterprise-Entwicklern abstimmen.

Benutzeroberflächendesigner und Front-End-Entwickler

Für Webentwickler oder Benutzeroberflächen-Designer ist die SharePoint-Framework wertvoll. Die Workbench ermöglicht Front-End-Entwicklern die Verwendung von SharePoint-Framework-Lösungen unter jedem beliebigen Betriebssystem und die Verwendung ihrer bevorzugten Bearbeitungstools ohne SharePoint. Dabei können sie simulierte Daten verwenden und sich auf die Benutzeroberfläche konzentrieren.

Das SharePoint-Framework wird parallel mit Office UI Fabric, dem offiziellen Front-End-Entwicklungsframework für Office und Microsoft 365, veröffentlicht und ermöglicht es Benutzeroberflächendesignern, eine nahtlose Oberfläche für Office, Microsoft 365 und benutzerdefinierte Lösungen zu erstellen.

Systemintegratoren (SI)

Wenn Sie Systemintegratoren (SI) oder Beratungsfirmen mit der Erstellung von SharePoint- und Microsoft 365-Lösungen beauftragen, sollten Sie Empfehlungen oder sogar Anforderungen für die Erstellung von SharePoint-Framework-Lösungen zusammenstellen, damit sie sich an den Plan Ihres Unternehmens für das SharePoint-Framework halten können.

Systemintegratoren haben in der Regel eine bevorzugte Art, Lösungen zu erstellen, die nicht immer mit den Governance-Vorgaben Ihres Unternehmens konform ist. Eine Abstimmung mit den Systemintegratoren ist daher wichtig und macht letztendlich allen Beteiligten die Arbeit einfacher.

Ein typisches Szenario mit Systemintegratoren besteht darin, dass diese die Lösung für Ihr Unternehmen erstellen und Sie nach Abschluss des Projekts selbst die Aufgabe haben, die Lösung zu verwalten, upzugraden und zu aktualisieren. Daher ist es umso wichtiger, dass Sie sich mit den Systemintegratoren darüber abstimmen, wie die SharePoint-Framework-Lösungen erstellt und gehostet werden.

Unabhängige Softwarehersteller (ISV)

Unabhängige Softwarehersteller (ISV) sind Organisationen, die Drittanbieterlösungen für den Massenmarkt erstellen, und sie erfüllen möglicherweise nicht immer Ihren Plan für SharePoint-Framework-Lösungen. Zudem sind ISVs in der Regel Eigentümer ihres Codes und ihres geistigen Eigentums, wodurch es schwierig für Sie ist, ihre Art der Implementierung und des Hostings ihrer Lösungen zu ändern.

Bei Verwendung von SharePoint-Framework-Lösungen von Drittanbietern müssen Sie genau analysieren, wie sie Updates verwalten und wie ihre Lösungen gehostet werden. Wollen Sie beispielsweise zulassen, dass die Lösung ohne Ihr Wissen aktualisiert wird? Wollen Sie zulassen, dass die statischen Objekte ohne Ihre Kontrolle im CDN des ISV gehostet werden? Inwiefern vertrauen Sie dem ISV?

Bedenken Sie, dass clientseitiger Code im SharePoint-Framework im Kontext des aktuellen Benutzers ausgeführt wird und Sie keine Möglichkeit haben, die Ausführung einzuschränken, was mit SharePoint-Add-Ins möglich ist.

Erstellen eines Plans für SharePoint-Framework-Anpassungen

Wenn Sie SharePoint Framework als eines der Tools für die Erweiterung Ihrer SharePoint (Online)-Instanzen einführen möchten, müssen Sie dies planen. Der Plan sollte mit der Einführung des neuen Technologiestapels beginnen, der beim Erstellen von SharePoint-Framework-Lösungen verwendet wird. Entwickler benötigen möglicherweise Training hinsichtlich der Verwendung von TypeScript als primärer Sprache zum Programmieren von SharePoint-Framework-Code.

Andere Aspekte des SharePoint-Framework, die Entwickler erlernen müssen, sind die tatsächliche Toolkette für das SharePoint-Framework mit Node.js, NPM und Gulp und die Verwendung der verschiedenen Gulp-Aufgaben zum Erstellen, Packen und Bereitstellen von Lösungen. Eine gute Ausgangsressource hierfür sind die offizielle SharePoint-Framework-Dokumentation und die GitHub-Repositorys zu SharePoint.

Möglicherweise möchten sich Entwickler für die Organisation auf ein bestimmtes clientseitiges Framework oder auf verschiedene Frameworks festlegen. Clientseitige Frameworks umfassen unter anderem React, Knockout, Angular, Handlebars, jQuery usw. Die Standardisierung auf einem Framework hat Vorteile, da entwickler dadurch mehr wiederverwendbaren Code erstellen und eine bessere Konsistenz beim Erstellen und Verwalten ihrer Lösungen erzielen können.

Es bietet Vorteile, mehrere Frameworks zuzulassen, da jedes clientseitige Framework seine Vor- und Nachteile bzw. geeigneten Anwendungsfälle hat. Allerdings kann die Zulassung beliebiger clientseitiger Frameworks zu Fragmentierung in Ihren Enterprise-Lösungen führen. Zudem kann die Verwendung mehrerer unterschiedlicher Frameworks die Seitenladezeit verlängern, da bei mehr Frameworks auch mehr externe Bibliotheken geladen werden müssen.

Standardmäßig bietet der Yeoman-Generator von SharePoint Framework Vorlagen für zwei clientseitige Frameworks: React und Knockout. Mit der Zeit ist zu erwarten, dass die Community weitere Generatoren oder Sub-Generatoren hinzufügen wird, um Unterstützung für weitere clientseitige Frameworks zu implementieren. Die Wahl von React als bevorzugtes clientseitiges Framework hat einen Vorteil: Microsoft hat eine React-Version von Office UI Fabric erstellt. Somit können Sie das Aussehen und Verhalten von Office und Microsoft 365 für Ihre Anpassung implementieren, falls dies in Ihrer Organisation bevorzugt wird.

Der vierte Aspekt ist, wie und wo Sie Ihre Lösungsartefakte bereitstellen, d. h. in welchem CDN die generierten Skriptbundles und Objekte gespeichert werden. Standardmäßig werden in den Gulp-Aufgaben in der Toolkette nur Azure Blob Storage und Azure CDN unterstützt. Diese Optionen sind möglicherweise gut geeignet, wenn Sie ein Azure-Abonnement verwalten und Ihre Objekte für mehrere Mandanten freigeben können. Ein weiteres gängiges Szenario ist die Verwendung von SharePoint Online und seinem CDN-Feature als Host für die Artefakte. Ab SharePoint-Framework v1. 4 werden statische Objekte standardmäßig in das SharePoint Framework-Paket gepackt. Wenn dieses Paket im App-Katalog bereitgestellt wird, werden sie automatisch in Microsoft 365 CDN (falls aktiviert) oder in der App-Katalog-URL gehostet.

Schließlich müssen Entwickler über die Verwaltung des Anwendungslebenszyklus (ALM) nachdenken: die Art und Weise, wie Sie Quellcode und Versionsverwaltung, automatisches Erstellen, Testen und Bereitstellen usw. verwalten. Die gängigsten Quellcode-Versionsverwaltungssysteme können verwendet werden, z. B. Git, GitHub oder Visual Studio Team Systems.

Für Continuous Integration gibt es keine Standardtools. Sie können jedes beliebige Tool verwenden, das node.js unterstützt, z. B. Visual Studio Team Systems, Travis CI oder Jenkins. Mit diesen Tools können Sie den Build- und Testprozess automatisieren und, wenn ein erfolgreicher und genehmigter Build vorhanden ist, die Artefakte sogar automatisch im CDN-Speicherort bereitstellen. So können Sie alles automatisieren, vom Einchecken des Codes durch die Entwickler bis hin zur Bereitstellung in der Produktionsumgebung.

Verwaltungsfunktionen von SharePoint-Framework-Lösungen

Alle SharePoint-Framework-Lösungen, die in einem Mandanten bereitgestellt werden, müssen von einem Mandantenadministrator genehmigt werden. Dies erfolgt durch Hochladen des SharePoint-Framework Pakets, der Datei *.sppkg in die App für SharePoint-Bibliothek. Wenn eine neue Lösung zur Bibliothek hinzugefügt wird, wird der Administrator in einem Dialogfeld aufgefordert, die Lösung für die Verwendung im Mandanten zu genehmigen. Im Dialogfeld wird erläutert, dass es sich um eine Lösung mit voll vertrauenswürdigem clientseitigem Code ohne Ressourceneinschränkungen handelt, die im Kontext des Benutzers ausgeführt wird. In dem Dialogfeld ist auch angegeben, aus welcher Domäne hauptsächlich Inhalte abgerufen werden; mit anderen Worten, es ist der CDN-Speicherort der SharePoint-Framework-Skripts aufgeführt. Jede SharePoint-Framework-Anwendung kann nach dem ersten Laden aus dem CDN auch Daten von anderen Speicherorten laden. Einmal genehmigt, kann die SharePoint-Framework-Lösung in jeder Websitesammlung aktiviert werden.

Ein Administrator des App-Katalogs kann das Paket jederzeit aus dem App-Katalog entfernen, indem er das Lösungspaket aus der Apps für SharePoint-Bibliothek entfernt. Dadurch wird die Verwendung der Lösung in allen Websitesammlungen unterbunden. Die Lösung kann auch durch Ändern der Eigenschaft Enabled des hochgeladenen Pakets deaktiviert werden. Dadurch wird die Lösung sofort in allen Websitesammlungen deaktiviert. Auf vorhandenen Seiten, die clientseitige Webparts verwenden, wird das Webpart nicht gerendert, und die App ist nicht mehr in den Websitesammlungen verfügbar bzw. kann in vorhandenen Websitesammlungen nicht mehr hinzugefügt werden. Wenn Sie eine SharePoint-Framework-Lösung entfernen, werden keine Daten oder Informationen entfernt, die durch die eigentliche clientseitige Lösung in SharePoint oder in einer von der Lösung verwendeten externen Datenquelle erstellt wurden.

Der Administrator kann auch andere Eigenschaften des Pakets im App-Katalog ändern, um die Sichtbarkeit der Lösung in Websitesammlungen zu verbessern, z. B. das Symbol, die Kategorie, die Beschreibung und den Status.

Wenn das Lösungspaket aktualisiert werden muss, z. B. wenn neue SharePoint-Framework-Artefakte erstellt oder andere Änderungen auf Paketebene vorgenommen werden, muss der Administrator nur eine neue Version des Pakets in die Bibliothek hochladen.

Wie bei SharePoint-Add-Ins kann ein Mandantenadministrator auch die SharePoint-Framework-Lösungen überwachen. Im SharePoint Admin Center unter Apps kann der SharePoint-Administrator die SharePoint-Framework-Lösungen hinzufügen und dann sehen, wie viele installierte Instanzen es von einer bestimmten Lösung gibt. Das ist für SharePoint-Add-Ins ebenso möglich wie für SharePoint-Framework-Lösungen.

Um eine SharePoint-Framework-Lösung in einer Websitesammlung zu aktivieren, muss sie der Websitesammlungsadministrator zu der Websitesammlung hinzufügen. Dies funktioniert wie bei SharePoint-Add-Ins, indem Sie in der Websitesammlung auf Neue App hinzufügen klicken und dann die Lösung aus der Liste der Apps auswählen. Sobald die App hinzugefügt wurde, steht sie für die Verwendung in der Websitesammlung zur Verfügung. Als Websitesammlungsadministrator können Sie die SharePoint-Framework-Lösung auch aus der Websitesammlung entfernen. Hierzu wechseln Sie zu Websiteinhalte und wählen dann Entfernen für die App aus.

SharePoint-Framework-Bereitstellungsbereiche

Beim Erstellen von SharePoint-Framework-Lösungen können Entwickler entscheiden, ob ihre Lösung eine mandantenweite Bereitstellung unterstützt oder ob sie auf jeder Website separat bereitgestellt werden muss. Letzteres ist erforderlich, wenn die Lösung zusätzliche Ressourcen wie Listen bereitstellen muss, nachdem sie auf einer Website bereitgestellt wurde.

Während Entwickler beim Erstellen der Lösung entscheiden, ob die Lösung eine mandantenweite Bereitstellung unterstützt, treffen Administratoren die endgültige Entscheidung darüber, wie die Lösung bereitgestellt wird. Auch wenn Sie eine Lösung für alle Websites im Mandanten bereitgestellt werden könnte, können Administratoren festlegen, dass sie nur für bestimmte Websites bereitgestellt wird. Wenn die Lösung die mandantenweite Bereitstellung nicht unterstützt, können Administratoren sie nur auf bestimmten Websites bereitstellen.

Wichtig

Die mandantenweite Bereitstellung ist nur in SharePoint Online verfügbar. In lokal gehosteten SharePoint-Umgebungen können SharePoint-Framework-Lösungen nur auf bestimmten Websites bereitgestellt werden.

Die SharePoint-Framework verfügt nicht über einen Speicher, den SharePoint-Add-Ins haben. Aus diesem Grund müssen Bereitstellungen immer vom Mandantenadministrator initiiert werden, indem ein Lösungspaket zum App-Katalog hinzugefügt und genehmigt wird.

Sichern und Wiederherstellen von SharePoint-Framework-Komponenten

SharePoint-Framework-Lösungen haben keine eigenen Features für Sicherung und Wiederherstellung. Das einzige, was aus administrativer Sicht empfohlen wird, ist, dass es eine gute Idee ist, eine Kopie aller installierten Lösungspaketdateien (*.sppkg) zu haben, wenn ein Lösungspaket versehentlich aus dem App-Katalog entfernt wird. Der App-Katalog ist jedoch eine SharePoint-Bibliothek und umfasst dieselben Funktionen wie jede Dokumentbibliothek, mit aktivierter Hauptversionsverwaltung und Papierkorb.

Was Sie nicht sichern können, sind die tatsächlichen Lösungsartefakte wie z. B. Skriptbundles und Objekte, die in einem CDN gehostet werden. Wenn Sie die Kontrolle über das CDN haben oder das CDN eine SharePoint-Website ist, können Sie die Artefakte sichern. Wenn Sie SharePoint-Framework-Lösungen von einem Drittanbieter verwenden, gibt es unter Umständen keine Möglichkeit für Ihre Organisation, sie zu sichern.

SharePoint-Framework-Roadmap

Das SharePoint-Framework hat seit Februar 2017 den Status der allgemeinen Verfügbarkeit (General Availability, GA). „Allgemeine Verfügbarkeit“ (GA) bedeutet, dass die Verwendung des SharePoint-Frameworks in Produktionsumgebungen unterstützt wird. IT-Experten und Entwickler können es also produktiv einsetzen. Über die allgemeine Verfügbarkeit hinaus erwarten wir, dass die Szenarien für die Erstellung und Verwendung von SharePoint-Framework-basierten Komponenten über Webpart-Szenarien hinaus auf Bereiche wie Listen- und Websiteanpassungen erweitert werden können.

Weitere Informationen zum SharePoint-Framework finden Sie separat SharePoint-Framework-Roadmap.

Wesentliche Änderungen oder die Einführung neuer wichtiger Features werden über das Microsoft 365-Nachrichtencenter angekündigt, das Sie in Ihrer Mandantenverwaltung finden – jeder Microsoft 365-Administrator sollte im Rahmen seiner Routineaufgaben täglich nachschauen, ob es dort neue Ankündigungen gibt. Eine weitere wichtige Ressource ist der Office-Entwicklerblog. Hier finden Sie weitere Details und Updates.

Unterstützung und SLA

Microsoft bietet über die regulären SharePoint Online-Supportkanäle keine Unterstützung für benutzerdefinierte Lösungen, die für SharePoint entwickelt wurden. Alle Probleme im Zusammenhang mit SharePoint-Lösungen erstellen sollten in GitHub unter https://github.com/SharePoint/sp-dev-docs/issues protokolliert werden. Die SharePoint-Engineering-Gruppe sieht sich in diesem Repository regelmäßig Probleme an und ist bestrebt, die eingehenden Anfragen so schnell wie möglich zu beantworten.

Wenn Ihre Organisation über einen Premier-Supportvertrag verfügt, sollte dieser der Standardkanal sein, über den Sie bei allen Problemen im Zusammenhang mit dem Erstellen von SharePoint-Lösungen Unterstützung anfordern. Ihre Anfragen werden von Microsoft-Eskalationstechnikers entsprechend ihrer Dringlichkeit bearbeitet.

SharePoint Framework ist für Abwärtskompatibilität konzipiert. Microsoft garantiert, dass Lösungen, die mithilfe einer der allgemein verfügbaren Versionen von SharePoint Framework erstellt werden, so lange funktionieren, bis ein expliziter Hinweis zu veralteten Funktionen für die jeweilige Version im Voraus angegeben wurde.

Zusammenfassung

SharePoint-Framework ist eine hervorragende Ergänzung und Weiterentwicklung der Toolbox für SharePoint-Anpassungen, mit der Entwickler auf unterstützte und kontrollierbare Weise SharePoint erweitern können. Mit dem SharePoint-Framework, das auf quelloffenen und modernen Technologien basiert, können Entwickler die SharePoint-Entwicklung in Unternehmen nicht nur auf das SharePoint-Team, sondern auch auf eine heterogenere Entwicklergruppe ausdehnen. Durch Bereitstellen der richtigen Governance und Unterstützung für SharePoint-Framework in Ihrem Mandanten helfen Sie als Administrator den Entwicklern, schneller ansprechendere Lösungen zu erstellen, was zu rund um besserer Effizienz führt.

Da das SharePoint-Framework für Entwickler von Erst- und Drittanbietern erstellt wurde und von Microsoft zunehmend für zukünftige Featureerweiterungen von SharePoint verwendet wird, stellt es auch für Ihre Organisation eine gute Wahl dar. Wir erwarten in Zukunft weitere inkrementelle Updates und Erweiterungen des SharePoint-Frameworks, mit denen die Funktionslücke zwischen dem klassischen SharePoint und der modernen SharePoint-Umgebung geschlossen wird.