Migrieren von benutzerdefinierten Benutzeraktionen und ECB-Menüelementen zu SharePoint-Framework-Erweiterungen
Die SharePoint-Framework (SPFx) ist das empfohlene Entwicklungsmodell zum Erweitern und Erstellen von SharePoint-Anpassungen. Wenn Sie SharePoint mit benutzerdefinierten Benutzeraktionen und benutzerdefinierten ECB-Menüelementen (Edit Control Block) mithilfe des SharePoint-Featureframeworks angepasst haben, fragen Sie sich vielleicht, was der Vorteil ist, sie zu SPFx zu migrieren?
Zunächst stellen wir die verfügbaren Optionen beim Entwickeln von SharePoint-Framework (SPFx)-Erweiterungen vor:
- Application Customizer: Erweitert die native „moderne“ Benutzeroberfläche von SharePoint, indem benutzerdefinierte HTML-Elemente und clientseitiger Code den vordefinierten Platzhaltern der „modernen“ Seiten hinzugefügt werden. Weitere Informationen zu Anwendungsanpassungen finden Sie unter Erstellen Ihrer ersten SharePoint-Framework-Erweiterung (Hello World, Teil 1).
- Befehlssatz: Fügen Sie der Befehlsleiste einer Listenansicht für eine Liste oder Bibliothek benutzerdefinierte ECB-Menüelemente oder benutzerdefinierte Schaltflächen hinzu. Sie können diesen Befehlen eine beliebige clientseitige Aktion zuordnen. Weitere Informationen zu Befehlssätzen finden Sie unter Erstellen Ihrer ersten Erweiterung des Typs „ListView Command Set“.
- Field Customizer: Passt das Rendering eines Felds in einer Listenansicht mit benutzerdefinierten HTML-Elementen und clientseitigem Code an. Weitere Informationen zu Feldanpassungen finden Sie unter Erstellen Ihrer ersten Field Customizer-Erweiterung.
Je nach Ziel der Anpassung können Sie eine der oben genannten Konfigurationen nutzen. Application Customizer sind zum Beispiel ein hervorragender Ersatz für benutzerdefinierte Benutzeraktionen. Befehlssätze sind ein geeigneter Ersatz für die ECB-Menüelemente. Schließlich sollen Field Customizer JSLink/Client-Side-Rendering-Anpassungen (CSR) ersetzen.
Vorteile einer Migration vorhandener SharePoint-Featureframework-Anpassungen zu SharePoint-Framework
SharePoint-Framework wurde für die neue „moderne“ SharePoint-Oberfläche konzipiert, welche auf modernen Teamwebsites und modernen Kommunikationswebsites für alle Geräte und Plattformen verfügbar sind.
Nur unterstützte Möglichkeit zum Anpassen von "modernen" Websites ohne Skripts
Einer der Hauptvorteile der Migration von älteren SharePoint Feature Framework-Anpassungen zum SharePoint-Framework ist, dass dies die einzige unterstützte Technik ist, die Sie auf modernen Websites zum Anpassen der Benutzeroberfläche haben.
Tatsächlich ist auf den "modernen" Websites das No-Script-Flag aktiviert, wodurch die Ausführung von in die Seite eingebetteten Skripts sowie benutzerdefinierte Benutzeraktionen, die sich auf externes JavaScript oder eingebettetes JavaScript bezieht, vermieden wird.
Die benutzerdefinierten Legacyaktionen für Benutzer funktionieren in der "modernen" Benutzeroberfläche einfach nicht. Die mit dem FeatureFramework erstellten ECB-Anpassungen sind begrenzt. Sie können nur ECB-Elemente definieren, die nicht auf externe JavaScript-Dateien verweisen oder keine eingebetteten JavaScript-Aufrufe verwenden. Wenn Sie die "moderne" Benutzeroberfläche wirklich erweitern möchten, müssen Sie ein Upgrade auf die SharePoint-Framework durchführen.
Einfacherer Zugriff auf Informationen in SharePoint und Microsoft 365
Ein weiterer grundlegender Punkt ist, dass es im Legacymodell von benutzerdefinierten Benutzeraktionen und ECB-Anpassungen nicht einfach war, SharePoint-Inhalte und -Daten zu nutzen. Die einzige Möglichkeit bestand in der Verwendung von JSOM (clientseitiges JavaScript-Objektmodell von SharePoint) oder Low-Level-REST-APIs. Darüber hinaus war es fast unmöglich, den vollständigen Satz von Diensten von Microsoft 365 zu nutzen, es sei denn, Sie haben ADAL.JS (Azure Active Directory Authentication Library for JavaScript) und benutzerdefinierten JavaScript-Code autonom genutzt.
Mit dem SharePoint-Framework und den SharePoint-Framework-Erweiterungen ist es jetzt einfach und einfach, sowohl die SharePoint-REST-API als auch Microsoft Graph zu nutzen. Sie können jetzt leistungsfähigere Lösungen erstellen, die das gesamte Ökosystem der von Microsoft 365 bereitgestellten Dienste nutzen und damit interagieren können.
Ähnlichkeiten zwischen SharePoint-Framework-Lösungen und SharePoint-Featureframework-Anpassungen
Sowohl die benutzerdefinierten Aktionen des SharePoint-Featureframeworks als auch die ECB-Elemente und die SharePoint-Featureframework-Anpassungen weisen einige Ähnlichkeiten auf.
Bereitstellungsmodell
Sowohl SharePoint-Framework Erweiterungen als auch benutzerdefinierte Benutzeraktionen oder ECB-Menüelementlösungen nutzen eine XML-Manifestdatei, die mit der SharePoint Feature Framework-Syntax geschrieben wird. Die Bereitstellung basiert auf den gleichen Techniken.
Ausführung als Teil der Seite
Ähnlich wie benutzerdefinierte Aktionen und ECB von SharePoint-Featureframework sind SharePoint-Erweiterungen Teil der Seite. Damit haben diese Lösungen Zugriff auf das DOM der Seite und können mit anderen Komponenten auf der Seite kommunizieren. Zusätzlich macht diese Tatsache es Entwicklern leichter, ihre Lösungen dynamisch zu gestalten, sodass sie sich an die verschiedenen Formfaktoren anpassen können, in denen eine SharePoint-Seite angezeigt werden kann. Unter anderem wird auch die mobile SharePoint-App unterstützt.
Da SharePoint-Framework-Erweiterungen als Teil der Seite ausgeführt werden, können unabhängig davon, auf welche Ressourcen die jeweilige Anpassung Zugriff hat, auch andere Elemente auf der Seite auf diese zugreifen. Das ist ein wichtiger Aspekt bei der Erstellung von Lösungen, die den impliziten OAuth-Fluss mit Bearerzugriffstoken nutzen oder vertrauliche Informationen in Cookies oder im Browserspeicher speichern. Da SharePoint-Framework-Erweiterungen als Teil der Seite ausgeführt werden, können andere Elemente auf der Seite ebenfalls auf alle diese Ressourcen zugreifen.
Bibliotheksunabhängige Erweiterungserstellung
Beim Erstellen von Seitenanpassungen mithilfe benutzerdefinierter Aktionen haben Sie möglicherweise Bibliotheken wie jQuery oder Knockout verwendet, um dynamische Anpassungen zu implementieren und besser auf Benutzerinteraktionen zu reagieren. Wenn Sie SharePoint-Framework-Erweiterungen erstellen, können Sie ganz wie bisher auch jede beliebige clientseitige Bibliothek verwenden, um den Funktionsumfang Ihrer Lösung zu erweitern.
Ein zusätzlicher Vorteil, den die SharePoint-Framework bietet, ist die Isolation Ihres Skripts. Obwohl das Webpart als Teil der Seite ausgeführt wird, ist das Skript als Modul gepackt, sodass verschiedene Erweiterungen auf derselben Seite eine andere Version von jQuery verwenden können, ohne miteinander zu kollidieren. Das ist ein leistungsfähiges Feature, das es Ihnen ermöglicht, sich auf die Schaffung von konkretem geschäftlichem Mehrwert zu konzentrieren; technische Migrationen und Funktionskompromisse sind nicht mehr nötig.
Ausführung als aktueller Benutzer
Bei Anpassungen mithilfe von benutzerdefinierten Benutzeraktionen und ECB-Menüelementen war zur Kommunikation mit SharePoint lediglich ein Aufruf der entsprechenden API notwendig. Die clientseitige Lösung wurde im Browser im Kontext des aktuellen Benutzers ausgeführt; da der Authentifizierungscookie automatisch zusammen mit der Anforderung gesendet wurde, konnte die Lösung eine direkte Verbindung zu SharePoint aufbauen. Zur Kommunikation mit SharePoint war also anders als bei der Verwendung von SharePoint-Add-Ins keine zusätzliche Authentifizierung erforderlich.
Der gleiche Mechanismus wird auch bei SharePoint-Framework-basierten Anpassungen angewendet. Auch sie werden im Kontext des aktuell authentifizierten Benutzers ausgeführt und erfordern keine zusätzlichen Authentifizierungsschritte zur Kommunikation mit SharePoint. Der Sicherheitskontext ist der des aktuell verbundenen Benutzers, was bedeutet, dass Sie aus Sicherheitsgründen vorsichtig sein müssen, wenn Sie eine SharePoint-Framework-Erweiterung in einer Zielwebsitesammlung installieren.
Beschränkung auf clientseitigen Code
Sowohl SharePoint-Framework-Erweiterungen als auch Lösungen für benutzerdefinierte Benutzeraktionen oder ECB-Menüelemente werden im Browser ausgeführt und dürfen ausschließlich clientseitigen JavaScript-Code enthalten. Dabei gelten für clientseitige Lösungen mehrere Einschränkungen: Sie unterstützen beispielsweise keine Rechteerweiterungen in SharePoint und können auch keine Verbindung zu externen APIs aufbauen, die CORS (Cross-Origin Resource Sharing) oder die Authentifizierung per implizitem OAuth-Fluss nicht unterstützen. In solchen Fällen kann die clientseitige Lösung eine serverseitige Remote-API nutzen, um den erforderlichen Vorgang auszuführen und die Ergebnisse an den Client zurückzugeben.
Hostingmodell selbstkonsistent und basierend auf Microsoft 365
Sowohl SharePoint-Framework-Erweiterungen als auch benutzerspezifische Aktionen oder ECB-Menüelementlösungen können in SharePoint Online und schließlich im Microsoft 365 CDN-Dienst gehostet werden, um externe Dienste oder Hostingumgebungen zu vermeiden.
Das Hosten SharePoint-Framework Lösungen auf einem CDN bietet zwar viele Vorteile, ist jedoch nicht erforderlich, und Sie können den Code in einer SharePoint-Dokumentbibliothek hosten. SharePoint-Framework Pakete (*.sppkg-Dateien), die im App-Katalog bereitgestellt werden, geben die URL an, unter der SharePoint-Framework den Code der Lösung finden können. Wenn der Benutzer der Seite mit der Erweiterung das Skript von dem angegebenen Speicherort herunterladen kann, gibt es keine Einschränkungen hinsichtlich des Ziels dieser URL.
Microsoft 365 bietet die öffentliche CDN-Funktion, mit der Sie Dateien aus einer bestimmten SharePoint-Dokumentbibliothek in einem CDN veröffentlichen können. Das öffentliche Microsoft 365 CDN bietet eine gute Balance zwischen den Vorteilen der Verwendung eines CDNs und der Einfachheit des Hostens von Codedateien in einer SharePoint-Dokumentbibliothek. Wenn Ihre Organisation keine Bedenken hat, dass ihre Codedateien öffentlich verfügbar sind, ist die Verwendung des öffentlichen Microsoft 365 CDN eine Option, die in Betracht gezogen werden sollte.
Unterschiede zwischen SharePoint-Framework-Lösungen und SharePoint-Featureframework-Anpassungen
Zwischen den beiden Entwicklungsmodellen gibt es jedoch auch einige wesentliche Unterschiede, die Sie beim Entwerfen der Architektur Ihrer Lösungen berücksichtigen sollten.
Ausführung auf No-Script-Websites
Da SharePoint-Framework Lösungen, einschließlich Erweiterungen, mit vorheriger Genehmigung über den App-Katalog bereitgestellt werden, unterliegen sie nicht den Einschränkungen ohne Skripts und funktionieren auf allen "modernen" Websites.
Vordefinierter Satz von Erweiterungspunkten
Während eine benutzerbenutzerdefinierte Aktion JavaScript-Code einbetten kann, der das DOM eines beliebigen Teils der Seite aktualisieren oder ändern kann, kann eine SharePoint-Framework-Erweiterung nur unterstützte Bereiche "moderner" Seiten anpassen.
Theoretisch könnten Sie einen Application Customizer erstellen,der mithilfe von DOM die Struktur einer Seite vollständig ändern kann, wie dies bei benutzerdefinierten Benutzeraktionen der Fall war. Das SharePoint-Framework fördert eine strukturierte und zuverlässige Vorgehensweise bei der Anpassung von SharePoint. Statt der Verwendung bestimmter DOM-Elemente bietet SharePoint-Framework Entwicklern bestimmte Hooks und Platzhalter für Anpassungen. Nur diese sollten verwendet werden.
Verwendung von TypeScript für stabilere und einfacher zu pflegende Lösungen
Beim Erstellen von Anpassungen mithilfe der benutzerdefinierten Aktionen des Benutzers oder der ECB-Menüelemente haben Entwickler häufig JavaScript verwendet. Solche Lösungen enthielten häufig keinerlei automatisierte Tests, und die Codeumgestaltung war fehleranfällig.
Mit dem SharePoint-Framework können Entwickler bei der Lösungserstellung das TypeScript-Typensystem verwenden. Dank des Typsystems werden viele Fehler während der Entwicklung anstelle der Laufzeit abgefangen. Auch die Codeumgestaltung ist einfacher, weil Änderungen am Code durch TypeScript gesichert werden. Da jeder JavaScript-Code gültiger TypeScript-Code ist, ist die Einstiegshürde niedrig, und Sie können Ihren reinen JavaScript-Code schrittweise zu TypeScript migrieren. Das macht die Lösungspflege einfacher.
Kein standardmäßiger Zugriff auf das SharePoint JavaScript-Objektmodell
Bei der Erstellung clientseitiger Anpassungen für die klassische SharePoint-Benutzeroberfläche verwendeten viele Entwickler das JavaScript-Objektmodell (JSOM) zur Kommunikation mit SharePoint. JSOM bot IntelliSense und einfachen Zugriff auf die SharePoint-API, ähnlich wie das clientseitige Objektmodell (CSOM). Auf klassischen SharePoint-Seiten war die Kernkomponente von JSOM standardmäßig implementiert, und Entwickler konnten zusätzliche Komponenten laden, beispielsweise zur Kommunikation mit der SharePoint-Suche.
In der modernen SharePoint-Benutzeroberfläche ist SharePoint JSOM nicht standardmäßig implementiert. Obwohl Entwickler es selbst laden können, wird empfohlen, stattdessen die REST-API oder SharePoint Patterns and Practices JavaScript Core Library (PnP JS Library) zu verwenden, die die SharePoint-REST-API intern verwendet. REST ist universeller und lässt sich mit unterschiedlichen clientseitigen Bibliotheken wie jQuery, Angular und React verwenden.
Microsoft investiert nicht mehr aktiv in JSOM. Wenn Sie lieber mit einer API arbeiten möchten, können Sie stattdessen die PnP JS-Bibliothek verwenden, die Ihnen eine Fluent-API und TypeScript-Typisierungen bietet.
Migrieren vorhandener Anpassungen zu SharePoint-Framework-Erweiterungen
Eine Migration vorhandener Anpassungen zu SharePoint-Framework-Erweiterungen hat sowohl für Endbenutzer als auch für Entwickler viele Vorteile. Wenn Sie die Migration vorhandener Anpassungen zum SharePoint-Framework in Betracht ziehen, können Sie entweder so viele der vorhandenen JavaScript-Skripts wie möglich wiederverwenden oder die Anpassung mithilfe von TypeScript vollständig neu schreiben.
Wiederverwenden vorhandener Skripts
Wenn Sie vorhandene Anpassungen zu SharePoint-Framework-Erweiterungen migrieren, können Sie Ihre bereits vorhandenen Skripts wiederverwenden. Obwohl das SharePoint-Framework gezielt auf die Verwendung von TypeScript ausgelegt ist, können Sie auch reines JavaScript verwenden und Ihren Code schrittweise auf TypeScript umstellen. Falls Sie eine Lösung nur während eines bestimmten Zeitraums unterstützen müssen oder Ihr Budget begrenzt ist, ist diese Strategie vielleicht ausreichend.
Es ist nicht immer möglich, bereits vorhandene Skripts in einer SharePoint-Framework-Lösung wiederzuverwenden. Angesichts der Vielzahl von JavaScript-Bibliotheken gibt es beispielsweise keine einfache Möglichkeit, festzustellen, ob Ihre vorhandenen Skripts in einer SharePoint-Framework-Lösung wiederverwendet werden können oder ob Sie sie neu schreiben müssen. Sie haben nur die Möglichkeit, die einzelnen Komponenten in eine SharePoint-Framework-Lösung zu überführen und zu testen, ob sie wie erwartet funktionieren.
Neuschreiben der Anpassung
Wenn Sie Ihre Lösung für einen längeren Zeitraum unterstützen müssen oder die SharePoint-Framework besser nutzen möchten oder wenn sich herausstellt, dass Ihre vorhandenen Skripts nicht mit dem SharePoint-Framework wiederverwendet werden können, müssen Sie Ihre Anpassung möglicherweise vollständig neu schreiben. Es ist zwar kostengünstiger als die Wiederverwendung vorhandener Skripts, bietet Ihnen aber über einen längeren Zeitraum bessere Ergebnisse: eine Lösung, die besser funktioniert und einfacher zu verwalten ist.
Wenn Sie eine vorhandene Anpassung in eine SharePoint-Framework Lösung umschreiben, sollten Sie mit der gewünschten Funktionalität beginnen. Ziehen Sie zur Implementierung der Benutzeroberfläche Office UI Fabric in Betracht, damit Ihre Lösung wie ein integraler Bestandteil von SharePoint aussieht.