© Kellie L. Folkerts/Shutterstock.com
SharePoint-Apps mit ShareCoffee entwickeln

Speed up your App Dev Skills


Apps sind überall. Der Siegeszug von „Apps“ ist sicherlich einem Unternehmen aus Cupertino zuzuschreiben, dennoch haben auch gestandene Businesslösungen wie SharePoint mittlerweile aufgeschlossen und bieten Nutzern die Möglichkeit, neue Funktionen mittels Apps zu konsumieren und somit die Plattform individuell zu erweitern. Auch in SharePoint 2013 und Office 365 steht nun für Entwickler ein robustes API zum Erstellen individueller Apps zur Verfügung.

Bei genauerer Betrachtung des SharePoint-App-Modells finden sich jedoch einige Tücken und Hürden, die jeder App Developer innerhalb eines Projekts zu meistern hat. Das kostet in jedem Projekt Zeit, Geld und nicht zu vergessen Nerven bei den Projektbeteiligten.

Wiederkehrende Probleme bei der App-Entwicklung mit SharePoint

SharePoint 2013 bietet unterschiedliche Arten von Apps an. So kann der Entwickler bei der Erstellung einer neuen App zwischen den folgenden App-Typen wählen:

  • SharePoint-hosted Apps
  • Auto-hosted Apps
  • Provider-hosted Apps

Die beiden letzten App-Typen können auch unter dem Begriff Cloud-hosted Apps gruppiert werden. (Stand Mai 2014 gelten die Auto-hosted Apps jedoch als depricated, weil diese vom Markt nicht entsprechend der Erwartungen angenommen wurden, und sie sind hier lediglich der Vollständigkeit wegen aufgeführt).

Betrachtet man die vorhandenen App-Typen und die damit verbundenen Datenzugriffstechniken für eine JavaScript-basierte Kommunikation, stellt man fest, dass es vier unterschiedliche Wege gibt, die je nach App-Typ vom Entwickler gewählt werden müssen (Tabelle 1).

SharePoint-App-Typ

Ziel des Datenzugriffs

Zu verwendende Technologie

SharePoint-hosted App

App-Web

Plain AJAX request

SharePoint-hosted App

Host-Web

AJAX request mit SP.AppSiteContext

Cloud-hosted App

App-Web

SP.RequestExecutor

Cloud-hosted App

Host-Web

SP.RequestExecutor mit SP.AppSiteContext

Tabelle 1: Unterschiedliche App-Typen

Aus Tabelle 1 wird ersichtlich, dass es zwei unterschiedliche Ziele für jede App gibt. Zunächst verfügt jede App aus Isolationsgründen über ein App-Web, das für den Entwickler als „Arbeitsbereich“ dient. Das Host-Web ist die SharePoint-Seite, auf der der Nutzer die App installiert hat. Falls man als App-Entwickler hier zugreifen möchte, muss man zunächst explizit die Berechtigung beim Benutzer abfragen, darüber hinaus müssen alle REST-Abfragen mithilfe der SP.AppSiteContext-Funktionalität ausgestattet werden, da die Kommunikation über die Grenze des App-Webs hinaus geht.

Nüchtern betrachtet lässt sich also bereits an dieser Stelle festhalten, dass ein SharPoint-App-Entwickler vier unterschiedliche Programmiertechniken für den Zugriff auf Daten in SharePoint-Apps beherrschen muss, um für eventuelle App-Szenarien gerüstet zu sein.

Des Weiteren müssen Apps, die über den SharePoint Store vertrieben werden sollen, gewisse visuelle Aspekte von SharePoint beinhalten, damit der Benutzer bei der Verwendung der App das Gefühl hat, immer noch mit SharePoint zu arbeiten. Hierzu stellt Microsoft sowohl das so genannte App Chrome als auch SharePoint-CSS-Klassen bereit, die man in Cloud-hosted Apps integrieren sollte. Microsoft stellt hierzu eine Referenzimplementierung auf der MSDN bereit [1]. Diese Implementierung bringt allerdings einige Nachteile mit sich:

  • Es besteht eine Abhängigkeit zu jQuery.
  • Die Codefragmente sind circa fünfzig Zeilen groß.
  • Diese Codefragmente müssen in jede App erneut integriert werden.

SharePoint-Apps leben von Ihrem Kontext. Abhängig von der aktuellen Umgebung und der gewählten App-Art müssen kontextuelle Informationen auf unterschiedliche Art und Weise vom Entwickler abgefragt werden. Wichtig bei der Entwicklung von SharePoint-Apps sind natürlich die URLs für das App- und das Host-Web. Die AppWebUrl wird entweder über einen Parameter im QueryString oder über eine Property des Objekts _spPageContextInfo bereitgestellt, und es obliegt dem Entwickler zu entscheiden, wo nach dem Wert gesucht wird bzw. wo dieser Wert geladen wird.

All diese kleinen Stolpersteine führten dazu, dass mit der steigenden Anzahl an getätigten App-Projekten der Bedarf nach einer Abstraktions-Library geweckt wurde. Eine Bibliothek musste her, die diese Aufgaben vereinfacht und damit dem App-Entwickler auch das tägliche Arbeiten vereinfacht. Somit war der Startschuss für ShareCoffee gefallen. Neben den bereits aufgezeigten Szenarien war es der Anspruch des Autors, die folgenden Anforderungen konsequent zu erfüllen:

  • Keine Abhängigkeiten zu anderen JavaScript-Frameworks wie jQuery oder gar Microsoft Ajax
  • Integration für populäre Frameworks wie AngularJS, jQuery oder Reqwest (ebenfalls ohne Referenz vorauszusetzen)
  • Komplett testgetriebene Entwicklung
  • Leicht zu erlernendes (Fluent) API

Auf die Plätze, fertig, ShareCoffee

ShareCoffee – zunächst gibt eine kurze Erläuterung zum Namen der Bibliothek. Der Name setzt sich aus den beiden Hauptbestandteilen zusammen, zunächst „Share“, welches ganz klar suggerieren soll, dass es sich hierbei um eine Library für SharePoint handelt. Der Term „Coffee“ ist eine Anspielung auf die Sprache CoffeeScript [2], in der die Library geschrieben wurde.

Aktuell ist das Framework in der Version 0.0.12 verfügbar. Jedoch ist diese Version bereits in einer Vielzahl von Apps im produktiven Einsatz und kann daher bedenkenlos in bestehende oder neue App-Projekte eingebunden werden.

ShareCoffee in einer SharePoint-App referenzieren

ShareCoffee ist eine Open-Source-Komponente, die auf GitHub gehosted wird [3]. Somit kann es also auch komplett mit allen Sourcen, Unit Tests und Dependencies heruntergeladen und integriert werden durch die Verwendung von git clone:

git clone git@github.com:ThorstenHans/ShareCoffee.git

ShareCoffee steht allerdings auch als NuGet- u...

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