Wann sind SharePoint Apps als Lösung sinnvoll?
In Tabelle 1 sind Gründe zu finden, die für die Nutzung von SharePoint Apps sprechen und erklären, wieso diese im Gegensatz zu Standard SharePoint Solutions verwendet werden sollten. Die Tabelle stellt lediglich einen ersten Blick auf das gesamte Portfolio dar und erhebt nicht den Anspruch auf eine umfassende Darstellung aller möglichen Gründe. Es bleibt aber zu erwähnen, dass der traditionelle SharePoint-Solution-Ansatz immer noch als Enterprise-Lösung in Unternehmen zum Einsatz kommt. Dies liegt zum größten Teil an den umfangreichen Funktionalitäten. Gerade für Entwickler stehen zahlreiche Möglichkeiten zur Verfügung, um eine wahre Solution zu entwickeln und dadurch einen Mehrwert für Unternehmen zu liefern.
Tabelle 1: Wann SharePoint Apps sinnvoll sind
Gründe für den Einsatz von Apps | Beschreibung |
App-Katalog | Über den App-Katalog in SharePoint lassen sich verfügbare Apps steuern, das heißt, in diesem Katalog können erstellte Apps hochgeladen und den Anwendern in SharePoint zur Verfügung gestellt werden - Apps können ebenso aktualisiert und gelöscht werden. |
App Version | Jedes App-Paket hat zusätzlich zu einer sogenannten App ID (eindeutiger Identifier) auch eine App-Paket-Version, die über die Manifest-Datei in Visual Studio geändert werden kann. Dies erleichtert das Management der einzelnen App-Versionen auf unterschiedlichen Umgebungen. |
Lebenszyklus | Der Vorteil daran ist, dass dieser App-Katalog mit dem Windows Phone Store vergleichbar ist. Wurde eine App geändert, muss lediglich die Version geändert und wieder in den Katalog hochgeladen werden. SharePoint kümmert sich alleine um den Update-Prozess. |
Cloud-fähig | SharePoint Apps können in Office 365 verwendet werden. Full-Trust Lösungen sind aktuell noch nicht Cloud-fähig. |
Entwicklungsumgebung (Visual Studio) | Bislang konnte nur auf diesem System SharePoint Solutions entwickelt werden, auf dem auch SharePoint installiert ist. SharePoint Apps lassen sich lokal entwickeln, auch wenn lokal kein SharePoint Server läuft. Es besteht zusätzlich die Möglichkeit, remote SharePoint Apps zu nutzen. Dies stellt meiner Meinung nach einen großen Mehrwert dar. |
Wann machen SharePoint Apps als Lösung weniger Sinn?
Wie erwähnt zeigt der obige Auszug lediglich einen Teil des Portfolios und bietet keinen umfassenden Überblick. Kommen wir nun zu der Frage: Wann ergibt es weniger Sinn, SharePoint Apps zu verwenden, oder wann können SharePoint Apps nicht verwendet werden?
Lassen Sie uns mit einer gewissen Flughöhe diese Fragen beantworten. Es gibt Punkte, die gegen eine Entwicklung von Apps sprechen, weil es generell technisch in SharePoint nicht möglich ist oder weil es einfach den Entwicklungszyklus durch zu großen Aufwand oder andere Einflussfaktoren behindern würde.
Sollten Sie Timer Jobs in Apps verwenden wollen, muss ich Sie leider enttäuschen. Es ist nicht möglich, über die Apps Timer Jobs zu erstellen - Timer Jobs müssen separat erstellt und in der Zentraladministration verwaltet werden. Leider ist es auch nicht möglich, Delegate Controls in Apps zu verwenden. Sie sehen schon, dass die Apps auch Nachteile mit sich bringen, gerade wenn tiefer in die SharePoint-Architektur eingetaucht werden möchte.
Wie sieht es eigentlich mit dem Branding aus? Wie Erfahrungen zeigen, möchten Unternehmen ihre Oberflächen immer fancy haben. Es gibt Workarounds, um Branding in Apps zu nutzen, aber eigentlich sollten hierfür eher Sandbox Lösungen eingesetzt und verwendet werden. Beim Umgang mit Workflows, Deployment und Zugriffen gibt es ebenso Einschränkungen. Es können keine wiederverwendbaren Workflows verwendet, keine assets nach /_vti_bin oder /_layouts eingesetzt sowie keine App-Parts angesprochen werden.
Somit muss vor der Entscheidung, ob Apps eingeführt oder entwickelt werden sollen, gut evaluiert werden, was das Ziel ist und was damit erreicht werden möchte. So wird die Situation vermieden, hinterher festzustellen, dass es überhaupt nicht möglich ist - Thema Sackgasse!