blog.atwork.at

news and know-how about microsoft, technology, cloud and more.

SharePoint Apps mit Office 365 und NAPA entwickeln

Web-Developer habens gut. Mit dem neuen App-Modell von SharePoint 2013 eröffnet sich eine völlig neue Welt der App-Entwicklung. War es bis SharePoint Online 2010 nur möglich, sandboxed solutions mit vielen Einschränkungen zu entwickeln, können Apps nun auf verschiedenste Arten entwickelt werden. Eine App kann nun als Webseite mit HTML, CSS und Javascript oder auch mit einer anderen beliebigen Sprache wie C#, VB.NET, PHP, o.ä. programmiert werden.

SharePoint und Office 2013-AddIns liegen nun als Webseite vor. Die Koppelung mit den Applikationen erfolgt über Datendienste. Für die Entwicklung werden HTML5, XML, CSS3, JavaScript und REST APIs verwendet. Microsoft setzt darauf, dass auch Webentwickler mit ihrem Know How rasch Lösungen für Office 2013 und SharePoint 2013 erstellen können. Etwa 65% der professionellen Developer verwenden HTML und Javascript. Somit erscheint es logisch, eine Plattform für diese Zielgruppe anzubieten.

Genau dieses Ziel verfolgt Microsoft mit der Browser-basierten Entwicklungsumgebung NAPA. Mit einem Office 365 Konto können Entwickler Lösungen direkt in der Cloud entwickeln, ohne irgendeine Software installieren zu müssen.

Dieser Artikel beschreibt die wichtigsten Schritte zum Erstellen und Bearbeiten einer eigenen SharePoint-App mit Office 365 und Napa. Bevor wir uns die Verwendung von NAPA ansehen, zuerst noch rasch ein paar Grundlagen über App-Development für Office 2013 und SharePoint 2013.

Anatomie einer App

Eine App besteht grundsätzlich aus zwei Teilen (wie in der Abbildung gezeigt):

  • Einem XML Manifest File (App.Manifest)
  • und einer Webseite

image

Grafik: Overview of apps for Office

Das Manifest definiert alle Einstellungen und zeigt zu der Webseite, wo die App gehostet ist:

  • Die URL der Website
  • Application Name, Beschreibung, ID, Version und Standard-Sprache
  • Wo läuft die App? (TaskPane, Inline in einem Dokument, FullScreen, etc.)
  • Die Art der App
  • Der "Permission Level" definiert die erforderliche Rechte für den Datenzugriff der App

Grundsätzlich gelten dieselben Regeln für OfficeApps und SharePointApps. Aufgrund der SharePoint 2013 Development-Plattform gibt es aber natürlich einige Besonderheiten für SharePointApps.

Hosting

Das Hosting entscheidet über die Art (und Programmierung) der App. Eine App für Office 2013 oder SharePoint 2013 kann so verfügbar gemacht (ge-hostet) werden:

  1. SharePoint Hosted oder
  2. Auto-Hosted (Cloud-Hosted in Windows Azure) oder
  3. Provider-Hosted (Cloud-Hosted)

Die Komponenten einer von SharePoint gehosteten App werden im App-Web einer SharePoint-Farm gehostet.imageimage

Grafik: Auswählen von Mustern für die Entwicklung und das Hosting Ihrer App für SharePoint

  • SharePoint-Hosted Apps werden direkt in SharePoint gespeichert und im App Web (s.o.) ausgeführt. Die Kommunikation erfolgt nur über Javascript, es wird kein serverseitiger Code unterstützt. Die Codierung erfolgt in JavaScript (mit der SharePoint 2013-JSOM-Bibliothek) + HTML.

Die beiden Cloud-Hosted Modelle erlauben jedoch auch serverseitigen Code in der App, sie laufen schließlich auf einem Applikations-Server.

  • Auto-Hosted kann Azure Webseiten und Azure Datenbanken beinhalten, die automatisch auf Windows Azure bereitgestellt werden. In Windows Azure steht die gesamte Palette von PaaS zur Verfügung, wie Load Balancing, Multitenancy sowie Reporting. Für die Codierung kann jede Sprache, die von Windows Azure-Websites unterstützt wird, verwendet werden, also .NET, PHP, Node.JS.
  • Beim Modell Provider-Hosted muss sich der Betreiber um die gesamte Infrastruktur kümmern. Für die Codierung kann jede Sprache, die von Ihrem Webserver oder Hostingdienst unterstützt wird, verwendet werden.

Im Klartext bedeutet das, zuerst muss sich der Entwickler für das gewünschte Hosting entscheiden, bevor ein Projekt angelegt wird. Natürlich kann eine SharePoint Hosted App auch später in eine AutoHosted App umgebaut werden. Umgekehrt ist dies jedoch nicht möglich, wenn Server-Side Code verwendet wird.

Erste Schritte zur Entwicklung von Apps für SharePoint informiert weiter über die Planung von Apps.

Voraussetzung: Office 365

Was benötigt man, um selbst SharePoint-Apps in Office 365 zu entwickeln?

Es wird nur ein Office 365 Konto benötigt. Wer noch keines besitzt, kann jederzeit hier ein neues 30-Tags-Testabonnement eröffnen. Alternativ kann man sich natürlich auch über einen Partnerlink anmelden, das hat den Vorteil, dass es einen weiteren Administrator gibt, der zum Beispiel das Admin-Kennwort zurücksetzen kann, wenn man es vergessen oder gesperrt hat.

Wichtig: Napa ist NUR IN OFFICE365 verfügbar.
Napa gibt es nicht on premise, sondern nur in der Cloud - mit Office 365.

Wenn man den eigenen Office 365 Account besitzt, ist dies die Vorgangsweise:

image

Hier folgen die einzelnen Schritte für die Einrichtung der eigenen Entwicklungsumgebung in Office 365.
(Siehe auch Sign up for an Office 365 Developer Site)

Napa einrichten

Mit Codenamen zeigt Microsoft Mut zu ... Getränken. Ist euch schon aufgefallen, dass die Codenamen fast immer mit Getränken zu tun hatten? So auch bei Napa, der wohl populärsten Weinregion in den USA (siehe wikipedia.org).

Napa steht für eine webbasierte IDE zur Erstellung von Office und SharePoint Apps.

Damit man Napa verwenden kann, benötigt man zuerst eine SharePoint Developer SiteCollection.
Diese wird im SharePoint Portal - wie im Screenshot - durch Hinzufügen einer neuen "Private Site Collection" erstellt.

image

Als Site-Template muss Developer Site ausgewählt werden. Tipp: Als Sprache am besten English verwenden, dann gibts auch keine Probleme mit dem Deployment aus Napa - sonst wird die Publishing Liste nicht gefunden... Ein weiterer Tipp: Wenn der Dialog "new site collection" im IE11 leer angezeigt, im Developer Modus (F12) auf IE9 umschalten...

image

Nach dem Erstellen der Developer Site gleich auf den Promoted Link "Build an app" klicken.

image

Es folgt ein Redirect zum SharePoint Store. Hier muss rechts oben die Sprache English ausgewählt werden - Napa funktioniert nur mit englischer Spracheinstellung. Nun kann die App "Napa" zur eigenen Developer Site hinzugefügt werden.

image

Natürlich erhält Napa "full control of this site collection". Damit ist Napa in unserer SPO Site verfügbar.

Ein Projekt mit Napa bearbeiten

Napa selbst ist eine AzureHosted-Website, die von Microsoft kostenfrei zur Verfügung gestellt wird - powered by Visual Studio!

Eigene Apps werden in Napa editiert und in die Dev-Website bereitgestellt.
Mit "Build an app" können bestehende Projekte geöffnet und neue Projekte erstellt werden.

image

Der Dialog fragt nach der Art der neuen App. Hier sieht man sofort, welche Apps mit Napa gebaut werden können, auch Office 2013 Apps sind möglich.

image

Und so sieht das neue SharePoint App Projekt in Napa aus. In einem Online-Editor (also im Browser!) können die einzelnen Dateien des App-Projekts bearbeitet werden. Dabei unterstützt die IDE auch die jeweilige Syntax mit Farbcodierungen und IntelliSense.

image

Im Vergleich zu den ersten Napa-Versionen ist die Menüleiste vom unteren Rand an den linken Rand gerückt und der Editor wurde verbessert. Die Neuerungen sind u.a. hier beschrieben.

Auch wenn die HTML-Webseite Default.aspx heißt, ist sie keine "echte" ASPX-Seite, es gibt hier keinen serverseitigen Code. Die Arbeit erfolgt in App.js, der vorkonfigurierten Javascript-Seite, die in Default.aspx inkludiert wird.

Der Code für das neue Beispielprojekt ist noch sehr überschaubar. Die App liest den Usernamen des angemeldeten SharePoint-Benutzers aus und zeigt diesen im Paragraph mit der ID "message" an. Das ist auch der Output dieser App.

image

Hier sieht man sehr schön die asynchronen Calls bei Success und bei Error - so müssen die Funktionsaufrufe erfolgen.

Napa Kommandos

Natürlich gelten im Browser primär die eigenen Tastenkombinationen. F5 führt so einen Reload der aktuellen Webseite aus, F12 öffnet die Developer Tools, usw. Aber auch in Napa gibt es Tastenkombinationen.

Mit STRG + E wird der "Quick Open"-Dialog geöffnet.

image

Mit "?" können die wichtigsten Befehle angezeigt werden.

image

">" zeigt eine Liste aller globalen Kommandos.

image

"$" zeigt alle Editor-Befehle. Sehr hilfreich ist beispielsweise STRG + F12 für "Definition".

image

Der Editor kann geteilt werden u.v.m.

image

Mit etwas Einarbeitung kann man so recht rasch im Editor arbeiten.

Use "Napa" Office 365 Development Tools to build apps for Office and SharePoint on the browser beschreibt die Möglichkeiten in der Napa Entwicklungsumgebung.

App-Eigenschaften

Das App-Manifest definiert alle Eigenschaften und Berechtigungen der App. Das Manifest kann in Napa in den Settings definiert werden.

image

In diesem Beispiel darf die App auf alle Elemente in der Site Collection mit Full Control zugreifen und die SharePoint Search verwenden.

image

Wollen wir in unserer App also auf beispielsweise eine SharePoint-Liste zugreifen, benötigen wir zumindest Read-Rechte auf Site Collection. Der Screenshot zeigt alle möglichen Permissions.
Für Site Collection sind dies None, Read, Write, Manage und Full Control, für Search nur None oder Query.

Relevant ist weiters, wenn die App auf externe Daten außerhalb von SharePoint zugreifen soll. In diesem Fall muss die Adresse des Endpoints (des Webservices) hier im App-Manifest hinzugefügt werden. SharePoint greift über einen eigenen Web-Proxy auf diese Adresse zu.

image

Hinweis Dezember 2013: Derzeit funktioniert das Hinzufügen von Adressen in Napa NICHT (auch nicht in anderen Browsern, ich vermute es dürfte ein Problem in Napa geben. Es hat zuvor allerdings funktioniert). Einzige Abhilfe hierfür war für mich, das Projekt als Visual Studio Projekt zu öffnen und es über VS zu deployen...

Napa und Visual Studio

Napa bietet auch die Möglichkeit, eine SharePoint-Hosted App aus Napa in Visual Studio zu bearbeiten. Bei Klick auf "Open in Visual Studio" wird ein Launcher geöffnet, der mit "Ausführen" bestätigt wird.

image

Danach wird ein neues Visual Studio Projekt mit der downgeloadeten App aus Napa geöffnet.
VS muss als Administrator ausgeführt werden und eine Verbindung zur SharePoint-Developer-Site hergestellt werden.

image

Das Projekt kann nun wie gewohnt in VS bearbeitet werden. Es ist dann jedoch keine Verbindung zwischen Napa und VS vorhanden. Das VS-Projekt ist völlig autark.

Die App starten

Gestartet wird die App über den Run-Button links.
image

Die App präsentiert sich nach dem Deployment-Prozess (Package - Deploy - Launch).

image

...in einem App Web. Napa öffnet für die App ein eigenes Browserfenster. Here we go!

SNAGHTML6611e8d

Jede Änderung im Code erfordert ein neues Deployment - wie schon in SP 2010 gewohnt.

Das Beispiel zeigt somit, dass man sich als Developer mit Napa nicht um Security und ähnliches kümmern muss - die App wird in SharePoint gehostet und läuft automatisch im Kontext des SharePoint-Webs. Über die eingebundenen Bibliotheken ist genauso der Zugriff auf SharePoint-Listen möglich.

Pro App ein eigenes App Web

Die Website, wo die App bereitgestellt wird, wird als Host Web bezeichnet.
Für jede SharePoint App erstellt SharePoint automatisch ein eigenes App Web.

Hier läuft die App in einem isolierten Bereich, also sandboxed.
Die URL des App Webs lautet dann zum Beispiel so:

https://spcadriatics-5262e885adfcae.sharepoint.com/sites/dev/MyFirstCloudApp/Pages/Default.aspx?SPHostUrl=...

Die App-ID wird an die domain spcadriatics als eigene Subdomain angehängt. Weitere Parameter übergeben verschiedene Werte in die App, zum Beispiel SPAppWebUrl, SPLanguage, SPHostUrl, etc. Diese werden zur Laufzeit durch Standard-Token von SharePoint ersetzt, die sicherstellen, dass der Kontext valide ist und eine Kommunikation zwischen App und SP möglich ist.

Der Platzhalter {StandardTokens} wird zur Laufzeit ersetzt. Die Parameter werden in  URL strings and tokens in apps for SharePoint beschrieben.

App Publishing

Napa kann natürlich auch ein App Package erstellen, direkt aus dem Browser heraus.

image

Nach dem Publish-Vorgang kann die App in der Developer-Site in der Liste "AppPackages" gefunden werden. Damit dieser Link funktioniert muss die Liste auch so heißen - daher sollte die Developer Site englisch sein.

image

Hier kann das erstellte Package downgeloadet werden.

image

Das .app-File ist eine ZIP-Datei mit App.Manifest und dem erstellten .wsp-Paket sowie einigen weiteren Files, beispielweise die Ressourcen wie Bilder etc. - einfach mal reinschauen!

Weitere Neuerungen in SP 2013

Im Unterschied zu SharePoint 2010 wird in SharePoint 2013 das client.svc Service mit REST-Funktionen erweitert. Das Service unterstützt nun direkte Aufrufe von REST Clients, es akzeptiert HTTP GET, PUT und POST Requests und wurde nach dem OData Protokoll gebaut.

Microsoft hat sich also von SOAP zugunsten von REST verabschiedet. REST bietet eine einfachere Schnittstelle, die bequem per Javascript und jQuery im JSON und ATOM-Format über jeweils eigene URLs abgerufen werden kann. Die Ergebnisse können über einen Proxy Server gecacht werden, das Handling ist einfacher u.v.m.

Das Client Side Object Model (CSOM) wurde um neue APIs für SharePoint Server Funktionen und für Windows Phone Applications erweitert (siehe u.a. How to: Complete basic operations using SharePoint 2013 client library code und What's new in SharePoint 2013 CSOM).

In SharePoint Foundation 2013 gab es keine großen Änderungen in CSOM abseits der REST Unterstützung. In SharePoint Server 2013 wurden jedoch in CSOM und den REST APIs alle SharePoint Funktionen wie Search, Sharing, Social, Publishing, Taxonomy, eDiscovery, Workflows, IRM, Analytics, BCS und noch viel mehr abgebildet.

sharepoint-app-new-api_thumb[4]

Neu ist auch der Alias _api für den client.svc Dateinamen in der URL, dieser vereinfacht die URL:
Statt der URL http://contososerver/_vti_bin/client.svc/web kann in SP 2013 diese URL http://contososerver/_api/web verwendet werden.

Objekt-Ressourcen können zum Beispiel so über REST URLs aufgerufen werden:

_api/web/lists
_api/web/lists/getByTitle('Announcements')
_api/web/getAvailableWebTemplates(lcid=1033)

SP 2013 verwendet für Authentifizierung nun (endlich!) das OAuth-Modell, siehe Authorization and authentication for apps in SharePoint 2013 und OAuth and the Rehydrated User in SharePoint 2013 - How'd They do That and What do I Need to Know sowie die Videos oAuth authentication in SharePoint 2013 und SharePoint 2013 OAuth implementation. Dies vereinfacht die Authentifizierung erheblich, vor allem gegen SP in Office 365 (wer sich - so wie ich - mit Claimed Based Authentication gegen SPO herumgeschlagen hat, weiß wovon ich spreche...).

Die Entwicklung mit dem neuen App Modell wird viele SharePoint Developer freuen. Hiermit fallen auch alle technischen Beschränkungen von sandboxed solutions und die Entwicklung von eigenen Lösungen wird wesentlich vereinfacht.

Eine App mit Zugriff auf SharePoint Listen

Nach wir uns das grundlegenden Bearbeiten von Apps mit Napa angesehen haben, wird es natürlich Zeit, eine echte SharePoint App zu erstellen. Hierfür stellt Microsoft ein kleines Beispiel bereit, welches zeigt, wie man mit Javascript in einer App SharePoint-Listen erstellt und löscht und wie man Elemente in eine SharePoint-Liste schreibt und löscht.

Hierzu einfach auf den Link TestAppforSharePoint klicken. Damit wird ein geteiltes Napa-Projekt geöffnet (Share Project). Wenn das Beispiel ausgeführt wird, sieht es - zwar nicht sehr hübsch, aber funktionell - so aus.

image

Das Beispiel demonstriert die Funktionen für Zugriff auf SharePoint-Listen per Javascript-Code.

Wer es selbst aufbauen möchte: In How to: Create a basic app for SharePoint by using "Napa" Office 365 Development Tools findet ihr eine Schritt-für-Schritt Anleitung zum Erstellen des obigen Beispiels!

Weitere SharePoint Apps

Im Apps for SharePoint sample pack im MSDN finden sich viele weitere App-Beispiele mit C# zum Download. Diese sind mit Visual Studio und Auto-Hosted zu verwenden.

Fazit

Napa bietet eine kostenfreie Entwicklungsumgebung in der Office 365-Cloud für SharePoint-Hosted Lösungen. Microsoft bezeichnet diese Web-basierende Plattform auch als "First-Class development environment". Napa ist ohne Installation über den Browser verwendbar und ermöglicht es, Apps für SharePoint Online und für Office 2013 zu programmieren.

Ist Napa für "echte" Developer geeignet? Nun, diese Frage muss individuell beantwortet werden. Grundsätzlich bietet Napa alles, was man zum Entwickeln braucht - wenn Client Side Code für die Lösung ausreicht. Daher ist mein persönliches Fazit: Ja, für kleine Javascript-Apps ist Napa sehr brauchbar. Für größere Projekte möchte ich schon Visual Studio mit seinem ganzen Ökosystem (wie beispielsweise TFS Online...) benutzen.

Es gibt natürlich noch sehr viel über SharePoint 2013 und SharePoint-Apps zu berichten. Fürs erste begnügen wir uns mit diesem kurzen Ausblick und wünschen viel Spaß beim Erforschen und Experimentieren von SharePoint Apps!

Comments (2) -

  • Peter

    11/17/2014 4:39:06 PM |

    Danke für diese wirklich gute Dokumentation, gibt es da Erfahrungen was den Mobilbereich betrifft? Ich denke da an Anwendungen wie man sie zum Beispiel bei Portalen wie lyoness-mobile.com verwirklichen könnte.

    Lg, Peter

  • Toni

    11/17/2014 4:50:07 PM |

    Hi Peter,
    nunja, wenn ich deine Frage bez. Erfahrungen etwa im Mobilbereich richtig interpretiere: Grundsätzlich können SharePoint und SharePoint Online mit Version 2013 eigene responsive Themes für Smartphones ausliefern. Die eigene App läuft aber in einem IFrame - ist also nur bedingt fähig, sich an den Browser des Clients anzupassen. Ich würde daher meinen: Grundsätzlich ja, aber es ist wohl deutlich mehr Aufwand erforderlich, eine SharePoint-App gut für mobile Devices umzusetzen. In Office Apps wird soundso immer IE in einer schmalen Task-Leiste verwendet - hier ist es wesentlich einfacher.
    Ich würde für ansprechende Apps eher eigene Websites und eine Business Logic verwenden, die auf (SharePoint) Services zugreift - damit ist die Skalierbarkeit und vor allem die Anpassungsfähigkeit deutlich besser.
    hth!
    lg, Toni

Pingbacks and trackbacks (1)+

Loading