Neben Office-Apps können mit dem vereinheitlichten Office-API auf ziemlich ähnlichen Prinzipien basierend auch Apps für SharePoint entwickelt werden. Wie genau das geht und wo mögliche Fallstricke lauern, erfahren Sie im Folgenden.

Nachdem wir uns im letzten Teil dieser Serie mit der Entwicklung von Office-Apps beschäftigt haben, werden wir uns dieses Mal Apps für SharePoint ansehen. Diese sind gerade besonders interessant im Rahmen der Office-Entwicklung, da Microsoft in seiner Onlineversion den SharePoint-Server sowie Office 365 vereinheitlicht und unter einer gemeinsamen Oberfläche zusammenfasst. Dies bedeutet auch, dass die SharePoint-Apps mit einem sehr ähnlichen API entwickelt werden, wie die Office-Apps.

SharePoint als App-Plattform

Aber vorher sollte man klären, warum SharePoint eine interessante Plattform für Applikationen aller Art ist: Microsoft selbst beschreibt SharePoint als „secure place to store, organize, share, and access information from almost any device“. Grob zusammengefasst handelt es sich um eine Kollaborationssoftware auf Basis von Websites. Dabei umfasst Kollaboration sowohl eine Dokumenten- sowie eine grundsätzliche Contentablage, projektbezogene Websites, persönliches und öffentliches Blogging, Social-Media-Funktionalitäten, umfangreiche Workflows und einige weitere Bereiche. All das kann durch Apps an eigene Bedürfnisse angepasst, genutzt und komplett umgestaltet werden.

In der „echten“ Welt wird SharePoint zumeist als umfassende Intranetlösung für die Verwaltung der Zusammenarbeit im Team genutzt. Dabei kann der Einsatzbereich von „einfacher“ Dokumentenablage, über Projektwebsites, die ihren Status aus Microsoft Project beziehen, bis hin zu kompletten Lösungen für kaufmännische oder Human-Resources-Anwendungsfälle reichen.

Wer schon etwas länger als SharePoint-Entwickler tätig ist, wird sich noch an die so genannten SharePoint Core Solutions erinnern, die das ursprüngliche Entwicklungsmodell der SharePoint-App-Entwicklung darstellen. Die meisten Anwendungsfälle, für die Solutions genutzt wurden, sind mittlerweile auch durch SharePoint-Apps abbildbar. Insbesondere mit den im nächsten Abschnitt beschriebenen Provider-hosted Apps bieten sich viele Möglichkeiten. Das ist vor allem interessant, weil SharePoint Online keine Infrastruktur bietet, um Core Solutions auszuführen. Hierzu noch eine Information am Rande: Die hier beschriebenen Apps werden erstmals in der SharePoint-Version 2013 unterstützt.

SharePoint in drei Varianten

Von SharePoint existieren im Moment drei verschiedene Varianten:

• SharePoint Online, mit dem wir uns hier hauptsächlich beschäftigen werden

• SharePoint Foundation, der nur grundlegende SharePoint-Funktionalitäten bereitstellt

• SharePoint On-Premise Server, der ganz klassisch auf einem Server installiert wird

Auch die Apps, die in SharePoint ausgeführt werden können, lassen sich in drei Arten unterteilen: SharePoint-hosted Apps, Provider-hosted Apps und Auto-hosted Apps.

Grundsätzlich besteht der Unterschied dieser drei verschiedenen Typen von Apps – wie der Name schon sagt – in der Art des Hostings. Die SharePoint-hosted App wird innerhalb von SharePoint gehostet und ausgeführt, während Provider- und Auto-hosted Apps einen speziellen Webspace benötigen. Ein weiterer Unterschied besteht in der Art des Codes, der von den einzelnen Apps ausgeführt werden kann.

SharePoint-hosted Apps können nur clientseitigen Code ausführen, z. B. HTML/CSS sowie JavaScript. Provider- und Auto-hosted Apps sind flexibler und können neben dem clientseitigen auch serverseitigen Code ausführen, etwa C# oder VB.NET.

Dadurch sind auch andere Anwendungsfälle verbunden. Während mit clientseitigem Code keine allzu komplexen Probleme gelöst werden können – wobei sich auch dieser Umstand in letzter Zeit durch umfangreiche clientseitige REST-APIs relativiert – können mit Provider- und Auto-hosted Apps so ziemlich alle Probleme gelöst werden, die auch von einer „normalen“ Webanwendung abgedeckt werden können.

Wenn Sie jetzt nach Auto-hosted Apps googlen, weil Sie sich nicht wirklich viel unter der Bezeichnung vorstellen können: Sie werden nicht viel finden, denn dieses App-Modell wird seit Mitte 2014 nicht mehr von Microsoft unterstützt. Der Vollständigkeit halber sollen sie jedoch nicht unerwähnt bleiben. Auto-hosted Apps sind im Endeffekt eine spezielle Art von Provider-hosted Apps, die in Windows Azure gehostet werden.

Voraussetzung für die Entwicklung der Apps ist die Verfügbarkeit eines SharePoint-Servers. Dabei kann es sich entweder um die Onlineversion oder eine On-Premise-Umgebung handeln. Zusätzlich muss, damit das Debugging funktioniert, die jeweilige SharePoint-Seite, auf der Sie entwickeln wollen, als Entwicklerseite eingerichtet sein. Das geht ganz einfach über die SharePoint-Administration. Eine Anleitung dazu finden Sie unter [1].

Zum Testen, und um ein wenig in die Office-365-Entwicklung hineinzuschnuppern, gibt es übrigens eine 30-Tage-Testversion, die Sie hier aktivieren können [2]. Eine kleine Information am Rande: Sollten Sie MSDN-Abonnent sein und bereits ein Visual Studio Ultimate oder Premium über MSDN beziehen, bekommen Sie von Microsoft ein einjähriges Abonnement von Office 365 „geschenkt“. Sie finden das Abo unter [3].

Provider- oder SharePoint-hosted App?

Aber was sollen Sie jetzt als App-Typen nutzen? SharePoint-hosted oder Provider-hosted Apps? Wie Sie im nächsten Absatz sehen werden, machen schon einige einfache Kriterien die Entscheidung leichter.

Wie schon zuvor beschrieben, kann bei SharePoint-hosted Apps kein serverseitiger Code verwendet werden. Aus diesem Grund sind auch Anfragen an Drittanwendungen, die kein REST-API bereitstellen, nicht möglich – sofern Sie keinen Zugriff auf den Server haben und kein eigenes REST-API schreiben wollen. Deshalb kann auch nicht ohne Umwege, wie über einen Web Service, auf Datenbanken zugegriffen werden.

Aber was ist dann mit der Speicherung von Daten auf dem SharePoint-Server? Irgendetwas wird Ihre Anwendung doch speichern wollen. Das geht natürlich auch in SharePoint...