Frage: Nutze ich Apps, SandBox-Solution oder wie sollte ich Anwendungen in SharePoint verteilen?
Warum verteilen?
Zuerst sollten Sie sich über den Begriff „Deployment“ klar werden. SharePoint läuft aus Sicht der Anwender im Produktionsbetrieb. Wenn Sie als Administrator oder Entwickler Anwendungsbausteine bereitstellen, dann sollten Sie diese separat entwickeln, testen und dann erst in die Produktion überführen.
Was man vorher wissen sollte
Das funktioniert mit den Bordmitteln von SharePoint leider nur sehr unzureichend. Als mögliche Lösung bietet Microsoft die Erstellung von Solutions (WSP) oder Add-Ins an. In der Vergangenheit gab es dazu teilweise widersprüchliche Aussagen zu der Verfügbarkeit und Nutzbarkeit von Solutions und Add-Ins in den verschiedenen Umgebungen. Um hier etwas Ordnung hineinzubringen, ist es wichtig zu erkennen, ob Aussagen eher Marketingzwecken dienen oder technisch getrieben sind.
Microsoft hat viele Milliarden Dollar in seine Cloud-Rechenzentren investiert. Eine der wichtigsten Bausteine der Cloud-Strategie ist Office 365. Dies ist praktisch eine gehostete SharePoint Enterprise Umgebung. Gehostet heißt hier auch, dass sich viele Nutzer dieselben Hardware-Ressourcen teilen. In solchen Umgebungen ist es wichtig, das einzelnen Anwendungen andere nicht stören – egal wie gut oder schlecht sie programmiert wurden.
Um das zu unterstützen, wurde das Add-In-Model entwickelt (kürzlich in Add-In umbenannt, vorher hieß das App-Model). Betrachtet man die Möglichkeiten, dann fällt auf den ersten Blick auf, dass Add-Ins stark UI-getrieben sind. Die Intention ist es, Daten aus SharePoint in einer selbst erstellten Benutzeroberfläche verfügbar zu machen. Dabei ist die Integration von SharePoint weitgehend entkoppelt. Es werden nur die Web-Dienste aus SharePoint benutzt und die Anwendung selbst läuft in ihrem eigenen Kontext. Insofern ist dies die konsequenteste Entkopplung.
Enterprise Lösungen
Im Unternehmen sieht die Situation freilich anders aus. Eine Hosting-Umgebung für Add-Ins steht möglicherweise nicht zur Verfügung und um eine solche aufzubauen, muss es gute Gründe dafür geben. Bleiben also noch die klassischen WSP-Pakete, die der Verteilung von Anwendungen dienen.
Microsoft hat hier allerdings einen Fehler gemacht. Mit der Entwicklung des Add-In-Models wurden die zuvor benutzten Sandbox-Lösungen als „deprecated“ bezeichnet. Ein Fehler deshalb, weil hier ein Kommunikationsproblem vorlag (siehe Link). Die Sandbox ist nicht veraltet, sondern die Unterstützung für verwalteten Code (sprich: C#/.NET) mit Zugriff auf das serverseitige Objektmodell. Das verteilen deklarativer Codes und die Programmierung mit HTML/JavaScript (JSOM) oder dem Client Side Object Model (CSOM) ist weiter unbeschränkt möglich. Man spricht hier von NCSS (No-Code SharePoint Solutions). CSOM kann auch in C# programmiert werden. Dabei wird allerdings nicht die native SharePoint-API benutzt, sondern eine Client-Bibliothek, die ihrerseits wieder die SharePoint-Dienste nutzt. Mithin exakt das, was auch in einem Add-In passiert.
Farm-Solutions dagegen führen ein eigenständiges Leben mit vollem API-Zugriff und ohne Beschränkungen. Die wichtigste Eigenschaft ist, dass sie nicht in Office 365 (und ähnlichen Hosting-Situationen) benutzt werden dürfen. Vermeiden Sie die Entwicklung von Farm-Solutions! Die Frage ist: „Add-In oder NCSS“?
Was nehme ich wann?
Entscheidend ist die Intention bei der Entwicklung eigener Lösungen. Hier ein paar Fragen, die es zu beantworten gilt:
- Verteile ich Datenstrukturen und Metadaten (Spalten, Inhaltstypen, Listenvorlagen, Workflows)?
- Verteile ich SharePoint-Standardkomponenten (Master-Seiten, Themes, Seitenvorlagen usw.)?
- Verteile ich eigenständige Benutzeroberflächen (Webparts, Webseiten, HTML)?
- Verteile ich Code, der etwas außerhalb von SharePoint berechnet, anzeigt, zugreift?
Ebenso wichtig ist die Umgebung:
- Plane ich den Übergang auf Office 365 in absehbarer Zeit?
- Habe ich eine Hosting-Umgebung für Add-Ins?
- Beherrsche ich den Verteilungsprozess administrativ oder machen das meine Anwender?
Add-Ins sind eine gute Antwort, wenn folgende Bedingungen Vorgaben wichtig sind:
- Die Lösung soll im Wesentlichen eine angepasste Benutzeroberfläche liefern
- Einfachster Such-, Erwerbs- und Installationsprozess für Benutzer
- Sichere SharePoint-Erweiterungen für Administratoren
- Einfaches Marketing- und Vertriebssystem auf der Basis eines Microsoft Online Add-In Stores
- Maximale Flexibilität bei der Entwicklung zukünftiger Upgrades / Hosting-Umgebungen
- Maximale Nutzung Ihrer vorhandener Programmierkenntnisse im Bereich JavaScript
- Integration cloudbasierter Ressourcen
- Festlegen von Berechtigungen für Ihre Erweiterung, die sich von den Berechtigungen des Benutzers unterscheiden, der das Add-In ausführt
- Verwendung von plattformübergreifenden Standards wie HTML, REST, OData, JavaScript und OAuth
NCSS (No-Code Sandbox-Solutions) sind eine gute Antwort, wenn es um folgende Themen geht:
- Die Lösung soll im Wesentlichen Standardfunktionen in SharePoint nutzen und erweitern
- Branding und vorlagenartige Erweiterungen
- Eine Hosting-Umgebung für Add-Ins steht nicht zur Verfügung
- Elemente sollen administrativ kontrollierbar sein (via Features)
- Sie benutzen oder entwickeln Web-Parts (webparts)
- Sie benutzen oder entwickeln Ereignis-Empfänger (event receiver)
- Sie benutzen oder entwickeln benutzerdefinierte Spaltentypen (site columns)
- Sie benutzen oder entwickeln benutzerdefinierte Anwendungsseiten (application pages)
Folgende Bausteine sind weder mit Add-In noch mit NCSS verfügbar:
- Benutzerdefinierte Websitedefinitionen: Dies ist eine Erweiterung des Modells der integrierten Site-Vorlagen (kann ersetzt werden)
- Stellvertretungs-Steuerelemente (delegate controls): Ersetzen Teile der Master-Seite, ohne die Masterseite auszutauschen
- Benutzerdefinierte Designs:
- Benutzerdefinierte Aktionsgruppen und benutzerdefiniertes Ausblenden von Aktionen (custom action / hide custom action):
- Benutzersteuerelemente (.ascx-Dateien): ASP.NET Steuerelemente für eigene Seiten
Mehr dazu finden Sie hier.
Aus funktionaler Sicht lässt sich das also ganz gut beantworten:
| Funktion | Add-In | Sandbox | Farm |
|---|---|---|---|
| Spalten | x | ||
| Inhaltstypen | x | ||
| Custom Actions | x | x | |
| Workflows | x | x | |
| Event Receiver | x | x | |
| Steuerelemente | x | ||
| Spaltentypen | x | ||
| Applikationsseiten | x | x | |
| Site Templates | x | ||
| CSOM | x | x | |
| JSOM | x | x | |
| API | x | ||
| Features | x | x | |
| UI | x | x | x |
| Webparts | x | x | |
| App-Parts | x | ||
| Hosting | x | x | |
| Office 365 | x | x | |
| Admin Tools | x |
Fazit
Wie so oft gibt es also keine klare Antwort. Auch wenn einige Beiträge bei Microsoft-Foren oder Stack Exchange dies suggerieren. Es kommt halt darauf an, was man will und welche Rahmenbedingungen existieren.
Mein Tipp:
Entwickeln Sie zukunftssicher mit HTML, CSS und JavaScript. Nutzen Sie das clientseitige Objektmodell, basierend auf JavaScript (JSOM) für die Programmierung. All Ihre Anwendungen sind so sicher in beiden Modellen, Add-In und NCSS nutzbar. Sie haben derzeit mehr Freiheitsgrade mit NCSS. Im Enterprise-Umfeld gehören dedizierte Softwareentwicklungsprozesse und Lebenszyklusüberwachung dazu. Nutzen Sie Visual Studio, SandBox-Solutions und TFS. Stellen Sie Bausteine für Self-Services, also anwendergetriebene UI-Elemente als Add-In bereit. Stellen Sie alles andere als NCSS bereit. Stark administrierte Umgebungen (wie Behörden) profitieren von NCSS. Stark benutzerbetriebene Umgebungen (wie IT-affine Startups) profitieren von Add-Ins.