© Kellie L. Folkerts/Shutterstock.com
Automatisierung per SharePoint/Office 365 Developer PnP

Das PnP-Framework mit PowerShell


Seit Längerem will Microsoft in SharePoint fehleranfälligen und unsicheren serverseitigen Code durch Apps und anderen clientseitigen Code ersetzen. Hierfür stehen Webdienste bereit, wodurch der „alte“ Ansatz mit WSP-Dateien nicht länger möglich ist. Gerade aber das Provisionieren von Vorlagen für Site Collections, Sites, Listen und Webseiten wurde bisher über solche WSP-Dateien gelöst. Deshalb ist man nun insbesondere beim zusätzlichen Provisionieren von Artefakten in einer hybriden SharePoint-Umgebung einigen Herausforderungen ausgesetzt.

CSOM (Client-side Object Model) bietet einen Ansatz für diese Art der Provisionierung, die jedoch eher funktionsorientiert ist. Die Office-Developer-PnP-Community hat mit dem PNP-Framework einen aufgabenorientierten Wrapper um das CSOM erstellt. Die PnP-PowerShell bietet hierbei eine interessante Möglichkeit der Automatisierung. Dieser Artikel stellt diese Möglichkeiten exemplarisch vor.

Ein neuer Ansatz: das PnP-Provisioning-Framework

Mit der Einführung von SharePoint 2013 (und nicht zuletzt auch SharePoint Online) wurde ein neues Paradigma vorgeschlagen. Das sollte dazu führen, dass SharePoint sicherer und performanter mit eigens geschriebenen Applikationen umgehen kann. In der Vergangenheit wurde SSOM (Server-side Object Model) ausgiebig in SharePoint-Lösungen verwendet, um Anpassungen vorzunehmen. Das führte zu großen Problemen, was sich meist in der Wartbarkeit und Sicherheit einer SharePoint-Farm zeigte. Mit den neuen SharePoint-Apps gehört das der Vergangenheit an, denn damit ist kein serverseitiger Code möglich. Eines konnte (und kann) jedoch immer weiterverwendet werden: Das Verteilen von SharePoint-Artefakten, wie Listen oder Webtemplates mit XML- und Caml-Code. Das führte bei vielen Kunden jedoch zu Problemen beim Lifecycle-Management des Deployments und auf Farm- bzw. Tenant-Level. Also empfiehlt Microsoft die Verschiebung von XML-gebundener Verteilung der SharePoint-Artefakte auf codegebundene Verteilung. Was heißt das? Inhalte wie Templates, Listen, Inhaltstypen usw. sollten mithilfe von eigenem Code erstellt werden. Das ist allerdings – gelinde gesagt – ein ganz schöner Aufwand! Warum? Nun, weil CSOM (Client-side Object Model) und JSOM (JavaScript Object Model) für das Remote Provisioning verwendet werden müssen und beide sehr funktionsorientiert aufgebaut sind. Das heißt, dass man zum Anlegen einer Liste bis zur Erstellung und zum Hinzufügen eines Inhaltstyps zur Liste leicht auf 50-100 Zeilen Code kommt. Das stellt natürlich einen enormen Aufwand dar.

Ein Ansatz, der genau das erleichtern soll, ist das PnP-Provisioning-Framework. Es hat den Vorteil, dass es aufgabenorientiert arbeitet. Wenn eine Liste erstellt wird, dann ist das mit wenigen Zeilen Code schnell erledigt. Das Framework, das es für C# und JavaScript gibt, ist ein Wrapper um CSOM bzw. JSOM und konzentriert sich auf die effektive Erstellung von Inhalten mit nur wenigen Zeilen Code. Die dazugehörige PnP-Provisioning-Engine bietet sogar die Möglichkeit, bereits gebaute Umgebungen in SharePoint in Form einer XML-Notation zu exportieren. Diese Inhalte können dann leicht auf andere Seiten übertragen werden. Das sind aber nur die offensichtlichsten Vorteile.

Vorteile, die auf der Hand liegen

Die folgende Aufzählung erhebt keinen Anspruch auf Vollständigkeit und soll lediglich die Hauptvorteile von PnP darstellen.

  • Systemunabhängigkeit: Das Provisioning-Framework funktioniert für die SharePoint-Versionen 2013, 2016 und SharePoint Online. Es ist egal, wo der Deployment-Prozess durchgeführt wird: Die Provisioning Engine erlaubt ein...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang