Seite 2: Tools

Inhaltsverzeichnis

Aufgerüstet

Wenn Programmierer in der Vergangenheit für SharePoint entwickeln wollten, kamen sie um Visual Studio nicht herum. In SharePoint 2013 stellt Microsoft eine Alternative bereit, das sogenannte Office 365 Development Tool, Codename Napa. Es ist eine App in SharePoint 2013 und Office 365, die ein abgespecktes Visual Studio im Browser bereitstellt und ausschließlich für die Entwicklung von Apps für die neuen Versionen von Office und SharePoint vorgesehen ist.

Dazu muss man eine SharePoint-Site vom Typ "DeveloperSite" anlegen und auf dieser die Napa-App hinzufügen. Bei ihrem Start wird der Entwickler gefragt, welche Art App er schreiben möchte. Die Unterstützung in Napa bietet sogar IntelliSense und Funktionen wie Copy & Paste sowie Syntax-Highlighting, wie Abbildung 2 zeigt. Der Vorteil von Napa ist, dass man direkt im Browser entwickeln sowie anschließend die App installieren und testen kann. Die neue App-Infrastruktur ermöglicht es auch, die Apps ohne serverseitiges Farm Solution Deployment einzuspielen. Wer lieber mit Visual Studio entwickelt, kann sein Napa-Projekt in Visual Studio 2012 exportieren. Umgekehrt ist der Import in Napa allerdings nicht möglich.

Visual Studio 2012 (außer in der Express-Version) bietet erwartungsgemäß eine breite Unterstützung für die Entwicklung von SharePoint-Erweiterungen und -Apps. Zahlreiche Projekt- und Item-Vorlagen sowie Assistenten und eine aufbereitete Struktur im Solution Explorer unterstützen den Entwickler, wie er es seit Visual Studio 2010 und SharePoint 2010 gewohnt ist. Neben den "alten" Vorlagen aus SharePoint 2010 für Farm- und Sandbox-Lösungen findet sich nun die App-Unterstützung für Office 2013 und SharePoint 2013.

Wählt der Entwickler "App für SharePoint 2013", erscheint ein Konfigurationsdialog (s. Abb. 3), über den er bestimmt, welchen Typ von Apps (SharePoint-hosted, autohosted oder Provider-hosted) er verwenden möchte.

Zu den Entwicklungs-Tools gehört der SharePoint Designer 2013, der in den meisten Fällen nicht als Programmierwerkzeug, sondern lediglich beim Anpassen und Konfigurieren von SharePoint-Sites zum Einsatz kommt. In der neuen Version beschränken sich die meisten Änderungen auf den Workflow Designer, der in Kombination mit einem installierten Visio nun ein grafisches Werkzeug bietet. Diese erweiterten Funktionen können Anwender allerdings nur im Zusammenhang mit dem neuen Workflow-Manager von SharePoint 2013 nutzen, den sie separat installieren und einrichten müssen. Haben sie lediglich SharePoint installiert, können sie nur die 2010er Workflows für SharePoint 2013 erstellen.

Nur noch Apps, oder was?

Betrachtet man die Evolution der Applikationstypen seit SharePoint 2007, haben sich die folgenden Applikationstypen etabliert:

• Farm Solutions: in SharePoint 2007 einzige Variante zur Entwicklung und Installation von SharePoint-Erweiterungen und -Applikationen. Das Deployment geschieht mit Administratorrechten direkt auf dem SharePoint-Server einer Farm.
• Sandbox Solutions: in SharePoint 2010 eingeführtes Modell einer Sandbox-Umgebung, in der Applikationen in einem separaten Sicherheitskontext laufen und einen eingeschränkten Funktionsumfang haben. "Lösungen" werden in einen Benutzer-Store und nicht direkt auf den Server installiert. Sandbox Solutions haben ein begrenztes Kontingent an Ressourcenpunkten, die sie täglich verwenden können. Zusätzlich wurde das .NET und JavaScript verwendende Client Object Model sowie eine REST-Schnittstelle zum Umgang mit Listendaten eingeführt.
• Apps: In SharePoint 2013 eingeführter Applikationstyp, der eine Entkoppelung von Applikationslogik, Daten und Hosting-Umgebung unterstützt. Apps für SharePoint werden in .NET, HTML5, JavaScript oder PHP geschrieben und kommunizieren über Schnittstellen wie REST, SOAP oder dem Client Object Model mit dem SharePoint-Server. Dabei lassen sich Apps sowohl im Server hosten als auch extern in einer Cloud oder bei einem Provider.

Das neue App-Modell soll die bisherigen Applikationstypen weitgehend ablösen, da unter anderem die Nutzung von Client-Techniken eine Umverteilung der Last auf die Clients bewirkt und die SharePoint-Server entlastet. Ein weiterer Vorteil ist das Verteilen von Apps über den Office App Store oder über SharePoint-interne App-Deployments. Erstmals lassen sich damit Anwendungen über den Office App Store weltweit verteilen. Allerdings sind die bisherigen Applikationstypen für bestimmte Anwendungsfälle unerlässlich. Die nachfolgende Tabelle zeigt, für welche Erweiterungen oder Anwendungsfälle man welchen Applikationstyp nimmt.

	Sandbox Solutions	Apps	Farm Solutions
Einsatzzweck	veraltet, nur noch in wenigen Szenarien sinnvoll	bevorzugte und empfohlene Applikationsvariante	kommen zum Einsatz bei allem, was sich nicht mit Apps abbilden lässt; etwa Timer Jobs, Site Definitions oder Serviceapplikationen
Performance	Sandbox Solutions laufen in einem eigenen Prozess und haben nur begrenzt Ressourcen, über die sie verfügen können. Performance ist immer sichergestellt, solange die definierten Ressourcenpunkte reichen.	Sie laufen in der Regel unabhängig vom SharePoint-Server und können die Performance nur durch die Möglichkeiten des Client Object Model oder REST beeinflussen. Da aber vieles clientseitig verarbeitet wird, liegt die Last eher beim Client.	Durch den direkten Zugriff auf den Server können auch ineffiziente Anwendungen geschrieben werden, die die Server-Performance direkt beeinflussen. Performanceoptimierte Anwendungen sind notwendig.
Serverseitiger Code	kann nur eingeschränkte Funktionen der Server API nutzen	Apps können nur clientseitigen Code ausführen.	sehr effizient, kann alle Funktionen der SharePoint API nutzen
Ressourcen	SandBox Solutions haben begrenzte Ressourcenpunkte, die täglich genutzt werden können.	Apps laufen in der Cloud (Office365), einem separaten Webserver oder in SharePoint. Ressourcen werden i.d.R. nicht viele beansprucht.	Kann Server-Performance direkt beeinflussen und Server-Ressourcen nutzen
Sicherheit	sehr sicher, da die Lösung in einer Sandbox mit eingeschränktem Sicherheitskontext läuft	sehr sicher, da die Apps Berechtigungen anfordern und vom Anwender bestätigt werden müssen. Technisch wird per OAuth eine Token-Authentifizierung verwendet	Farm Solutions müssen sicher implementiert werden.

Da die Apps das bisherige Server Object Model nicht verwenden können, wurden die REST-Schnittstelle und das Client Object Model erweitert, sodass nun nahezu alle Funktionen des Server Object Model über diese Schnittstellen verfügbar sind. In SharePoint 2010 konnte die REST-Schnittstelle über den listdata.svc-Dienst nur auf Listendaten zugreifen. In SharePoint 2013 wurde das CSOM erweitert, sodass es zum einen REST-fähig ist und zum anderen so gut wie alle Funktionen des Server Objekt Model abdeckt. Abbildung 4 zeigt den REST-fähigen Endpunkt im Überblick. Neben der Suche werden auch soziale Funktionen, Taxonomien, Workflows, Berechtigungen, Publishing- und E-Discovery-Funktionen sowie der Umgang mit den Business Connectivity Services unterstützt.

Den listdata.svc-Dienst gibt es aus Abwärtskompatibilitätsgründen noch, aber für die neuen Funktionen verwendet man einheitlich das Kürzel "_api", zum Beispielhttp://meinserver/_api/Web zum Anzeigen der Daten der aktuellen Website per XML. Beispiele für REST-Aufrufe sind etwa:

• alle Listen einer Website: http://meinserver/site/_api/lists
• alle List-Items einer Liste: http://meinserver/site/_api/lists/getbytitle('listname')/items
• Anwenden eines Web-Template: http://meinserver/site/_api/web/applyWebTemplate("STS#0")