SharePoint 2013 - Gegenüberstellung Farmlösungen (Farm Solutions) und Apps

In diesem Post möchte ich auf die Möglichkeiten der Bereitstellung von benutzerdefinierten Lösungen in SharePoint 2013 eingehen. Im Gegensatz zu SharePoint 2010 ergeben sich in diesem Bereich einige Änderungen, die ich im Folgenden darstellen möchte.

In SharePoint 2010 gab es die Farmlösungen (Farm Solutions) und die Sandkastenlösungen (Sandbox Solutions). In SharePoint 2013 sind die Sandkastenlösungen veraltet, Ihr Lebenszyklus war nicht von langer Dauer, was einige Entwickler mit Sicherheit freuen wird. Die bekannten Farmlösungen wird es auch weiterhin geben, zur Freude der Administratoren :-)

Ein großes Thema im täglichen Leben sind heutzutage die Apps, jeder kennt Sie und jeder nutzt Sie. In SharePoint 2013 dürfen die Apps somit nicht fehlen. Wer sich das Thema Apps und SharePoint 2013 einmal genauer anschauen möchte findet auf Microsoft Technet die benötigten Informationen.

Soweit so gut, aber für welche Szenarien setze ich welche Lösungen ein. Im Grunde genommen kann man die Lösungen in 2 Kategorien einteilen.

Kategorie Farmlösung

Lösungen dieser Kategorie erweitern die Funktionalität einer SharePoint-Farm, einer Webseitensammlung oder auch einer einfachen Seite. Die Bereitstellung und Veröffentlichung der Farmlösungen erfolgt durch die Farm-Administratoren. Diese werden wie gewohnt über die Farmlösungen innerhalb der Zentraladministration bereitgestellt.

Beispiel Farmlösung

Wir möchten unseren SharePoint Server um eine Workflow-Engine erweitern, da wir mit den Standardmitteln des SharePoint Workflow Designers nicht zufrieden sind und die Funktionalitäten erweitern möchten. Wir entscheiden uns in diesem Fall für Nintex Workflow. Diese Lösung wird auf der Farm zur Verfügung gestellt und bietet den Anwendern/Administratoren eine Reihe an Funktionalitäten.

Kategorie Apps

Lösungen der Kategorie 2 kann man gut als Einzelgänger beschreiben. Eine App stellt die Lösung zu einem bestimmten Problem dar. Apps sind in der Regel einfach zu handhaben, da keine komplexe Funktionalität zur Verfügung gestellt wird.

Beispiel Apps

Im Intranet soll auf der Startseite die Twitter-Timeline des Unternehmens eingebunden werden. Es muss in diesem Fall keine komplexe Funktionalität bereitgestellt werden. Es wird lediglich ein Web Part als App zur Verfügung gestellt, welches sich mit dem Twitter-Account verbinden und die entsprechende Timeline anzeigen kann.

Wir wissen nun, dass wir 2 Möglichkeiten der Entwicklung von Lösungen für unsere SharePoint 2013 Farm  haben. Aber welche Unterschiede sind nun in den Lösungen vorhanden. Die folgenden Punkte liefern Euch hoffentlich einen guten Überblick.

Authentifizierung

Farmlösungen laufen gewöhnlich als Vertrauenswürdig (Full trust). Handelt es sich um ein Farm-Feature wird die Lösung in den Global Assembly Cache (GAC) geladen. Sofern es sich um ein Webanwendungsfeature handelt wird die bin-Assembly in das bin-Verzeichnis des virtuellen Servers kopiert.

Apps hingegen haben unterschiedliche Zugriffsmechanismen. Damit man die SharePoint API aus einer App heraus aufrufen kann müssen wir uns zuvor am SharePoint authentifizieren. Nutzen wir lediglich HTML, JavaScript (z.B. innerhalb von Web Parts zur visuellen Darstellung) übernimmt SharePoint die Authentifizierung. Greifen wir jedoch auf Daten zu, die außerhalb vom SharePoint liegen (z.B. Cloud-Zugriffe) wird über OAuth oder auch REST API's zugegriffen.

Unterstütze Features

Farmlösungen unterstützen eigentlich jede Funktionalität, die SharePoint abbilden kann. Wie in SharePoint 2010 bei den Sandkastenlösungen gibt es auch in SharePoint 2013 Abgrenzungen bei der App-Entwicklung. 

Die folgenden Features kann man als App bereitstellen:

• Benutzerdefinierte Webparts (Custom Web Parts)
• Benutzerdefinierte Seitendefinitionen (Custom site definitions)
• Benutzerdefinierte Themes (Custom themes)
• Benutzer-Steuerelemente (User controls)
• Benutzerdefinierte Aktionen (Custom action groups)
• Stellvertretungs-Steuerelement (Delegate controls)
• Benutzerdefinierte Webservices (Custom web services)
• diese müssen auf dem SharePoint Service Application Framework aufbauen
• Ereignisempfänger (Event Receivers)

Diese Funktionalitäten lassen sich mit Apps nicht abbilden:

• Zugriff auf Elemente, die nicht in derselben SharePoint-Seite liegen
• Eine Verbindung von Apps untereinander ist nicht möglich
• Mit Hilfe von Apps lässt sich kein SharePoint Server Seiten Code aufrufen (Server side code)
• Anwendungsseiten (Application Pages) lassen sich nicht als App bereitstellen

Resource Allocation

Farmlösungen beinhalten keine Restriktionen bezüglich der Resource Allocation. Apps bieten den Webseitensammlungsadministratoren die Möglichkeit der Überwachung  und können die zugewiesenen Ressourcen ändern.

Ich wünsche allen ein frohes Fest und besinnliche Weihnachtstage im Kreise der Familie und Freunde.

Bis dahin,
Patrick