Plattformübergreifende App-Entwicklung am Beispiel SharePoint

Transkript

1 Plattformübergreifende App-Entwicklung am Beispiel SharePoint Seminararbeit im Rahmen des Studienganges Scientific Programming Torsten Schuster utilitas GmbH Betreuer: Prof. Dr. rer. nat. Bodo Kraft 2. Betreuer: Marcel Nitsch

2 Inhaltsverzeichnis 1 Einleitung Allgemeines Motivation und Ziele SharePoint Technologien im Überblick Standardfunktionalität ASP.NET und XML Objektmodelle App-Modell Bereitstellung von SharePoint Anwendungen Konzepte zur plattformübergreifenden Entwicklung Aufgabenstellung Lösungsansätze und Realisierung Listen als Datenspeicher Bearbeitung und Anzeige der Listen Integration und Nutzung von Webdiensten Anbindung an mobile Geräte Fazit und Ausblick 19 5 Anhang 20 6 Literaturverzeichnis 24 2

3 1 Einleitung 1.1 Allgemeines SharePoint ist eine Plattform von Microsoft, welche Funktionen aus den Bereichen der Zusammenarbeit, Dokument- und Inhaltsverwaltung, sowie Workflows und Integration von Geschäftslogiken bietet. Aus bestehenden Vorlagen für Listen, Bibliotheken, Workflows und Arbeitsbereichen lässt sich eine Umgebung erstellen, die den Bedürfnissen angepasst werden kann. Da jedoch keine vollständige Umgebung bereitgestellt wird, muss diese erst konfiguriert und Abbildung 1: SharePoint Übersicht aus den bestehenden Vorlagen aufgebaut werden. Dabei sind oft zusätzliche [dev09] Elemente nötig um gewünschte Szenarien abbilden zu können, wel- che teilweise programmiert werden müssen. Darunter fallen beispielsweise Webparts [Pia11], Bedienungselemente zur Auswertung und Bearbeitung von SharePoint-Inhalten, Workflows zur Automatisierung von Abläufen oder Ereignisempfänger, die auf bestimmte Ereignisse reagieren und Logiken ausführen können. Diese Arbeit soll dabei auf diesen technischen Aspekt der Entwicklung erweiterter Funktionen eingehen, verschiedene Ansätze erläutern und Konzepte zur Erstellung von Anwendungen aufzeigen, die plattformübergreifenden Zugriff ermöglichen. Damit ist zum einen der Zugriff von verschiedenen Betriebssystemen, zum anderen die Entwicklung für verschiedene SharePoint-Versionen gemeint. Der Begriff App wird dabei in dieser Arbeit im allgemeinen Sinn, als Synonym für Applikation genutzt. Dies vereinheitlicht die Nutzung, da der Begriff im SharePoint verstärkt auch für nicht mobile Anwendungen verwendet wird [Mic12d]. 3

4 Dafür werden zunächst die verschiedenen Technologien aus den bisherigen SharePoint-Versionen vorgestellt. Zielplattform der Lösungsansätze und Beispiele wird die zurzeit aktuelle Version 15, SharePoint 2013 sein. In SharePoint 2013 kamen einige neue Möglichkeiten der App-Entwicklung hinzu. Diese basieren zu einem großen Anteil auf standardisierten und verbreiteten Webtechnologien, wie JavaScript, HTML und Kommunikation zu Webdiensten und Authorisierungsmechanismen. Dadurch soll eine bessere plattformübergreifende Entwicklung möglich sein. 1.2 Motivation und Ziele Eine Vielzahl mobiler Geräte, wie Mobiltelefone und Tablet-Computer und die damit verbundenen Betriebssysteme haben einen großen Einfluss auf die Softwareentwicklung. Zum einen nutzen die verschiedenen Plattformen unterschiedliche Betriebssysteme und Technologien, zum anderen ist auch der Anspruch an die Bedienung anders. Besonders kleine Schaltflächen sind auf mobilen Geräten schwer zugänglich und erschweren die Bedienung einer App. Da es sich bei SharePoint um eine proprietäre Plattform handelt, ist es ebenso wichtig Erweiterungen und Anpassungen möglichst flexibel für Plattformaktualisierungen zu gestalten. Besonders im Rahmen von SharePoint Online - der Cloud Version von SharePoint - spielt dies eine besonderer Rolle, da dort ein Update automatisch eingespielt wird. Dabei bleiben zwar bisher auch alte Lösungen funktionsfähig, werden jedoch zukünftig als veraltet eingestuft [Mic12a]. Gleichzeitig wird durch Cloud-Dienste wie Office 365 der mobile Zugriff vereinfacht, da dieser ohnehin über das Internet stattfindet. Zusätzlich werden die Apps über einen neuen Internet-Marktplatz zur Verfügung gestellt, wodurch eine weitere Verbreitung erreicht werden soll. Zugleich ist dadurch auch ein besonders einfaches und sicheres Update möglich. Durch diese schnellere Verbreitung steigt ebenso der finanzielle Aspekt der Softwareentwicklung. Bei einer oft verkauften App muss eine einfache Bereitstellung, Installation und Wartung möglich sein, damit sie wirtschaftlich ist. Ideen für einen guten Aufbau von Anwendungen und Planung während der Entwicklung sind daher letzten Endes auch finanziell entscheidend. Ziel dieser Arbeit ist es einige dieser Konzepte vorzustellen. Beispielhaft wird dabei 4

5 eine App vorgestellt, welche diese nutzt. Schwerpunkt sollen hier jedoch die Lösungsansätze, weniger die Ausarbeitung sein. 2 SharePoint Technologien im Überblick In diesem Abschnitt werden die verschiedenen Technologien von SharePoint erläutert und gegenübergestellt. 2.1 Standardfunktionalität Wichtiger Aspekt zur Entwicklung von SharePoint- Lösungen, oder Lösungen im Allgemeinen ist die Kenntnis über die bereits vorhandene Standardfunktion. Nutzung dieser Funktionen kann zum einen die Programmierung erleichtern und gibt zusätzlich dem Anwender eine konsistentere Erfahrung, da er so die aus dem Standard bekannten Arbeitsabläufe nutzen kann. Ein Großteil von Anwendungen benötigt eine Art von Datenspeicher. Im SharePoint wird dies üblicherweise mit Listen und Bibliotheken abgebildet. Listen kann man sich vereinfacht als Tabellen mit mehreren Spalten vorstellen. Jede Spalte hat einen Namen, einen Datentyp und daran gebundene Eigenschaften. In Bibliotheken ist jede Zeile in der Tabelle ein Dokument. Die Spalten sind zusätzliche Metainformationen dazu. Um in einer Liste verschieden geartete Inhalte, wie Ordner und Dokumente bereitstellen zu können und Daten an mehreren Orten konsistenter zu halten, gibt es in SharePoint sogenannte Inhaltstypen. Jeder Inhaltstyp hat dabei definierbare Eigenschaften, welchen ein Name und ein Typ zugewiesen werden kann. Ein Beispiel für einen Inhaltstyp ist eine Aufgabe, welche Felder wie Titel als Zeichenfolge oder ein Start- und Fälligkeitsdatumdatum hat. Diese Eigenschaften lassen sich unter Inhaltstypen weitervererben. So kann beispielsweise ein eigener Dokumenteninhaltstyp auf Basis des SharePoint- Inhaltstyps Dokument erstellt werden. Dieser kann zusätzlich zu den erwähnten Eigenschaften noch eine Dokumentenvorlage abspeichern. 5

6 SharePoint liefert dabei eine Vielzahl vordefinierter Inhaltstypen, welche genutzt und angepasst werden können. Zu diesen im Standard enthaltenen Inhalten bietet SharePoint - je nach Version - verschiedene zusätzliche Features, welche aktiviert werden können und zusätzliche Funktionen, Seiten, Webparts und mehr bereitstellen können. Ein Großteil dieser Funktionen lässt sich direkt über den Browser konfigurieren und nutzen. Zudem hat man die Möglichkeit, zusätzliche Programme zur fortgeschrittenen Bearbeitung zu nutzen. Eines der bekannteren Werkzeuge darunter ist der SharePoint Designer, welcher Funktionen zur schnelleren Erstellung und erweiterten Bearbeitung von Inhalten zur Verfügung stellt. Zusätzliche Funktionen, die über die Weboberfläche nicht zugänglich sind, wie das Erstellen von Workflows bis hin zum Bearbeiten von ASP.NET Master Pages (siehe Abschnitt 2.2) sind ebenfalls möglich. Workflows geben im SharePoint die Möglichkeit, wiederkehrende Aufgaben automatisch abarbeiten zu lassen. Ein Workflow kann beispielsweise automatisch eine Aufgabe zuweisen und dabei auf Eigenschaften eines Listenelementes oder Benutzereingaben reagieren. Gehen die Ansprüche über diese Funktionen hinaus, müssen entweder zusätzliche Lösungen installiert oder entwickelt werden. Diese Erweiterungen werden meist mit dem Visual Studio erstellt, welches für SharePoint-Elemente Vorlagen zur Verfügung stellt. Grundlegende Inhalte und Technologien werden in den nächsten Abschnitten behandelt. 2.2 ASP.NET und XML Viele Funktionen und Inhalte im SharePoint nutzen XML oder haben eine XML ähnliche Struktur. Geschickt genutzt lassen sich so schon über den Browser oder den SharePoint Designer vielseitige Umgebungen erstellen. SharePoint erweitert das ASP.NET Framework und nutzt daher viele Komponenten aus diesem. Daher sind ASP.NET und somit auch HTML grundlegend zur Erstellung von Seiten in XML-ähnlicher Struktur für SharePoint- Umgebungen. Master Pages geben dabei die Struktur für die eigentlichen Inhaltsseiten vor und stellen Elemente, beispielsweise eine Navigation, bereit, die auf al- 6

7 len Seiten enthalten sein soll. Durch Anpassung der ASP-NET-Komponenten [Wen07], wie Master Pages und Inhaltsseiten kann das Aussehen des Share- Points angepasst werden. Oft werden damit Firmendesigns eingebracht oder das Layout und Bedienung auf die Umgebung angepasst. Schon mit ASP.NET Seiten und Webparts ist eine komplexe Visualisierung von SharePoint Daten möglich. Beispielsweise können gefilterte Datenquellen und Anzeige-Webparts über ASP.NET bereitgestellt und verbunden werden. Über XSLT, eine Programmiersprache die selbst XML Struktur hat, kann sowohl Funktion als auch Aussehen dieser angezeigten Daten angepasst werden. Einige Webparts in SharePoint haben die Möglichkeit, diese XSLT-Stylesheets zu nutzen, sodass Aussehen und Funktion verändert werden können [Hug11]. Genauso wie diese Anpassungen werden auch SharePoint Lösungen zu einem großen Teil über XML definiert. So werden beispielsweise Inhaltstypen, Listendefinitionen, Ansichten, Felder, Features, Eigenschaften von Webparts oder Upload von Dateien definiert. Ein kurzes Beispiel ist in Abbildung 6. Diese Generierung wird in großen Teilen jedoch von Visual Studio unterstützt und in der neusten Version über eine grafische Oberfläche vereinfacht. Zudem nutzt SharePoint als Webanwendung einige Standards, die selbst XML nutzen. Standards, welche in Abschnitt eine wichtige Rolle spielen werden sind z.b. REST-Services oder die Web Services Description Language, kurz WSDL [Pia11]. 2.3 Objektmodelle Um auf SharePoint Elemente zugreifen zu können, bietet SharePoint mehrere Objektmodelle, welche in verschiedenen Programmiersprachen, hauptsächlich C# und JavaScript, genutzt werden können. Zusammengefasst lassen sich diese Modelle in zwei Kategorien einteilen. Das Server- und das Client-Objektmodell [Pia11]. Der auf dem SharePoint-Server ausgeführte Code wird beispielsweise in Webparts, Ereignisempfängern und TimerJobs zur Ausführung wiederkehrender Aufgaben genutzt. Es hat den größten Funktionsumfang und kann daher für viele Anwendungsszenarien genutzt werden. 7

8 Für Client-Anwendungen stellt Microsoft für JavaScript und C# ein Client-Side- Objectmodel, kurz CSOM, bereit. So können auch aus mobilen Applikationen, Anwendungen auf einem Computer oder speziell dem Browser Funktionen des SharePoints genutzt werden. Die Anwendung läuft dabei auf dem Client und kommuniziert intern mit Webservices des SharePoints. Daher ist der Zugriff auf maximal Websitensammlungsebene beschränkt und somit beispielsweise die Nutzung von Eventreceivern oder anderen Elementen, die auf Farmebene agieren, nicht möglich [Pia11]. In SharePoint 2013 wurde dieser Umfang jedoch erhöht und ein neuer, einheitlicherer Webservice zur Verfügung gestellt. Beispielsweise kann in Listenansichten und Formularen nun durch Einbindung eigener JavaScript-Dateien das Darstellungsverhalten auf Clientseite beeinflusst werden [Eva12]. Die Auswirkungen in der neuen Version werden in Abschnitt 2.4 genauer beschrieben. Bei der Entwicklung muss des Weiteren die Netzwerklast mit in die Planung einbezogen werden. Das CSOM schont zwar Serverressourcen, erhöht jedoch die über das Netzwerk abgefragten Daten, wie Listenelementen. Dafür lassen sich auf dem Client auch komplexe Funktionen, wie Visualisierungen durchführen, mit der Möglichkeit weitere Clientfunktionen, wie andere JavaScript- Bibliotheken zu nutzen. Eine weitere Einschränkung besonders bei JavaScript ist, dass der Code direkt auf dem Client ausgeführt wird und dort auch mit wenig Aufwand angesehen und sogar bearbeitet werden kann. Es ist somit nur eingeschränkt, möglich die enthaltenen Algorithmen zu schützen. Oft werden Hybridlösungen genutzt, welche diese beiden Konzepte kombinieren. Ein klassisches Beispiel dafür ist ein eigener Webservice, welcher serverseitig ausgeführt wird und über eine Clientanwendung aufgerufen wird. Dieses Zusammenstellung kann dafür sorgen, dass von verschiedenen - auch mobilen - Anwendungen serverseitige Logik ausgeführt werden kann. Im Abschnitt wird dies daher genauer erläutert. 8

9 2.4 App-Modell In SharePoint 2013 wurde das sogenannte App-Modell eingeführt und zugleich der Begriff App verstärkt genutzt. SharePoint Inhalte, wie Listen, Kalender und Bibliotheken werden nun genau wie auch programmierte Lösungen als App bezeichnet. Ich werde diesen Begriff jedoch weiterhin zum eindeutigen Verständnis für programmierte Lösungen benutzen. Diese neuen Apps bestehen dabei immer aus einer Webanwendung und einer SharePoint-Komponente, welche diese Webanwendung im SharePoint registriert und autorisiert. Die Webanwendungen können dabei auf drei Arten gehostet werden, was Auswirkungen auf mögliche Inhalte hat. Die einfachste Version ist die SharePoint hosted App. In dieser werden alle Inhalte im SharePoint hinzugefügt. Sie eignen sich daher besonders für Listen und Anpassungen in der SharePoint-Oberfläche, können jedoch keinen serverseitigen Code beinhalten. Über das erweiterte JavaScript-Objekt-Modell in SharePoint 2013 ist der Funktionsumfang jedoch gegenüber der vorherigen Version gestiegen. Bei der Provider-Hosted App kann man den Provider selber angeben und kann dadurch, was bisher nicht möglich war, beispielsweise eine Webanwendung in einer anderen Sprache, wie PHP oder Python, in SharePoint einbinden. Über das CSOM oder REST ist dann eine Anzeige und Bearbeitung der SharePoint Daten, wie Listenelementen, Benutzereigenschaften oder Suchergebnissen möglich. Genauer wird dies in Abschnitt beschrieben. Die letzte Variante ist die Autohosted App, welche für Office 365 zur Verfügung steht. Dabei wird die Webanwendung automatisch in einer isolierten Windows Azure Umgebung bereitgestellt. Diese Webanwendungen können dann über den SharePoint aufgerufen werden oder als sogenannten App-Parts in eine SharePoint-Seite eingebunden werden. Ermöglicht wird dies durch die Einbindung von OAuth in SharePoint Zusammengefasst ermöglicht OAuth auch externen Webanwendungen, Daten im SharePoint zu bearbeiten. Die Anwendung kann durch einen Benutzer autorisiert werden, in seinem Auftrag zu handeln [How12]. 9

10 2.5 Bereitstellung von SharePoint Anwendungen Bei der Bereitstellung von Anwendungen im SharePoint gibt es mehrere Möglichkeiten. Eine der Einfachsten ist es Dateien, wie ASP.NET-Seiten, HTML- Seiten, Stylesheets oder Assemblies direkt in die SharePoint Farm zu laden. Der Speicherort kann direkt auf den Festplatten der Server in der Farm sein oder eine Bibliothek, deren Dateiinhalte in einer Datenbank abgespeichert werden. Einmalig kann man so schnell und einfach Elemente bereitstellen, verzichtet jedoch auf Möglichkeiten der besseren Aktualisierbarkeit und Wartbarkeit, die andere Alternativen bieten. Die am häufigsten genutzte Variante der Bereitstellung ist das Erstellen von SharePoint-Lösungen. Diese können mit dem Visual Studio erstellt und dann auf einer SharePoint Umgebung bereitgestellt werden. Über Features können sämtliche SharePoint Inhalte erzeugt werden. Bei Aktivierung, Deaktivierung und Upgrade können diese neben der Bereitstellung der Elemente auch Funktionen sogenannte Feature Eventreceiver ausführen. Über diese Funktionen hat man die Möglichkeit, Anwendungen nur dort bereitzustellen, wo sie benötigt werden und mehr Komfort bei der Aktualisierung einer Lösung. Über XML kann für verschiedene Feature-Versionen definiert werden, welche Elemente geändert werden müssen. Durch den Feature Eventreceiver hat man zusätzlich die Option, eigenen Code ausführen zu lassen, um komplexere Aktualisierungsprozesse auszuführen. Das neue App-Modell von SharePoint 2013 wurde bereits im vorherigen Kapitel vorgestellt. Da SharePoint 2010 jedoch weiter verbreitet ist, werden hier auch die Bereitstellungsmodelle vorgestellt. In SharePoint 2010 unterscheidet man zwischen sogenannten Farmlösungen und den in dieser Version eingeführten Sandkastenlösungen. Farmlösungen haben dabei uneingeschränkten Zugriff auf das gesamte SharePoint Objektmodell und laufen unter Full Trust. Dadurch ist beispielsweise eine Impersionisierung möglich, wodurch ein Programm als Administrator ausgeführt werden kann. In SharePoint Online können diese Lösungen nicht genutzt werden. Einige Elemente, wie z.b. TimerJobs können jedoch nur in solchen Lösungen bereitgestellt werden. 10

11 Sandkastenlösungen haben im Vergleich zu Farmlösungen eingeschränkten Zugriff und laufen immer im Kontext des ausführenden Benutzers. Zudem können Ressourcen zugeordnet werden, welche von den Lösungen genutzt werden können. Wird dieses zugewiesene Kontingent überschritten, wird die Lösung mit dem höchsten Verbrauch deaktiviert. Die Ressourcen berechnen sich durch Ausführungszeit, Anzahl von Zugriffen, Anzahl an hervorgerufener unbehandelter Ausnahmen und weiteren Parametern. Über diese gesammelten Informationen lassen sich diese Lösungen somit besser überwachen und auswerten [Stu09]. Auch eine Kombination von Farm und Sandkastenlösungen ist möglich. Wird eine Logik auf Farm-Ebene in mehreren Sandkastenlösungen benötigt, kann ein sogenannter Full-Trust Proxy geschrieben werden. Dieser wird dann als Farmlösung bereitgestellt und kann aus der Sandbox aufgerufen werden. Bei der Entwicklung einer neuen Anwendung sollte daher auch überlegt werden, in welcher Form die Lösung bereitgestellt werden soll. Soll beispielsweise ein individuelles Design im SharePoint umgesetzt werden können, benötigte Seiten und Stylesheets einfach im SharePoint abgelegt und referenziert werden. Soll die Lösung hingegen wiederverwendbar sein, so empfiehlt sich eine SharePoint-Lösung. 3 Konzepte zur plattformübergreifenden Entwicklung 3.1 Aufgabenstellung Im Rahmen des Updates von SharePoint 2010 auf 2013 werden die Sandkastenlösungen als veraltet gekennzeichnet. Da dies bisher der einzige Weg war, Lösungen auch für SharePoint Online bereitzustellen, muss ein großer Teil der bestehenden Lösungen für SharePoint Online angepasst werden. Zugleich werden viele Installationen der letzten SharePoint Version bestehen bleiben. Aufgabenstellung ist es daher, ein Konzept zu entwickeln, welches es ermöglicht, mit weniger Aufwand Lösungen für mehrere SharePoint Versionen zu 11

12 entwickeln, ohne dabei neue Funktionen einzuschränken. Konkret soll dafür eine Adressverwaltungs-App erstellt werden, welche Kontakte zentral im SharePoint zur Verfügung stellen muss. Diese Kontakte müssen Firmen zugeordnet werden können und in weiteren SharePoint Listen zur Verfügung stehen. Die Anwendungsfälle für Kontakte in Abbildung 7 sind mit denen zu Firmen größtenteils identisch. Da diese Lösung in der ersten Version einfach aufgebaut ist, soll eine einfache, schnelle Bereitstellung und eine gute Aktualisierbarkeit gewährleistet sein. Folgende Versionen sollen in kurzen Abständen folgen können, um Erfahrungen und Kundenrückmeldungen einfließen zu lassen. Sowohl Kontakte als auch Firmen müssen über die Standardlösung bestimmte Felder vordefiniert haben. Kundenspezifische Felder sollen jedoch jederzeit hinzugefügt werden können, ohne die Lösung programmatisch anpassen zu müssen. Dabei muss trotzdem gewährleistet sein, dass die Lösung weiterhin aktualisierbar bleibt. Weiterhin sollen diese Kontakte in Zukunft zusätzlich zur SharePoint Oberfläche auch auf mobilen Geräten oder anderen Anwendungen, wie Outlook, zur Verfügung stehen. Diese Punkte können zunächst so weit wie möglich im Standard umgesetzt werden. Sind Punkte in der ersten Version dadurch nicht möglich, muss die Lösung so gestaltet werden, dass sie jederzeit einfach aktualisiert werden kann. Daher muss für die Entwicklung Zeit für Recherche, Tests und Planung eingeplant werden. In dieser Phase sollen ebenso Neuerungen der neuen SharePoint Version ermittelt werden und Konzepte erstellt werden, die es ermöglichen, mit wenig Aufwand Lösungen für beide SharePoint Versionen zu erzeugen. Mit der App soll ein einheitlicher und einfach zu verwaltender Speicher für Kontakte geschaffen werden, welcher auf verschiedenen Geräten einen guten Überblick bietet. SharePoint-Standardfunktionen, wie beispielsweise eine Synchronisierung von Kontakten zu Outlook sollen dabei erhalten bleiben. 12

13 3.2 Lösungsansätze und Realisierung In Abschnitt 2.1 wurden einige Elemente und Technologien auch des SharePoint Standard vorgestellt. Diese sind enorm vielseitig und können in geschickter Kombination auch komplexe Anforderungen bedienen. Ein wichtiger Schritt in der Entwicklung ist es somit festzustellen, welche Mittel der Standard schon zur Verfügung stellt und wie diese erweitert werden können. Dadurch kann der Entwicklungsaufwand reduziert werden und man kann oft auf weitere bestehende Funktionen zurückgreifen. Nutzt man beispielsweise eine SharePoint Liste zur Datenspeicherung, braucht man keine Anwendungen zum Erstellen, Bearbeiten oder Anzeigen von Elementen erstellen, da diese schon über Standardformulare gegeben sind. Möchte man diese anpassen, könnte man dies z.b. über eigene Formulare mit eigenen Webparts gestalten oder die Bestehenden über XSLT anpassen Listen als Datenspeicher Die Datenhaltung kann im SharePoint größtenteils über Listen abgebildet werden. Dadurch lassen sich alle Standardfunktionen von SharePoint, wie Datenpflege, Suche und Berechtigungsvergabe nutzen. In der Adressverwaltung werden dafür neue Inhaltstypen und Websitespalten für Firmen und Kontakte angelegt. Der Kontakt-Inhaltstyp kann dabei direkt von dem SharePoint-Eigenen Inhaltstyp erben und erhält so Felder, welche die Synchronisierung zu Outlook ermöglichen. Zusätzlich werden weitere benutzerdefinierte Felder hinzugefügt, welche beispielsweise bestehende Firmen zuordnen können. Auf Basis dieser Inhaltstypen können nun Listendefinitionen erstellt werden. Diese dienen als Vorlage für eine Listeninstanz, welche schlussendlich die Kontakte und Firmen beinhalten können. In der Listendefinition können zudem Ansichten definiert werden, welche für die Kontakte nötig sind. Zusätzlich werden Listenansichts-Webparts auf Seiten bereitgestellt. Über Webpart-Verbindungen ist es möglich, eine Ansicht zu erstellen, welche bei Auswahl einer Firma die dazugehörigen Kontakte anzeigt. Ein Webpart stellt dabei die Daten zur Filterung in dem anderen bereit. Bis hier werden alle Schritte über XML-Elemente definiert und stehen sowohl 13

14 für SharePoint 2010, als auch in der neuen Version zur Verfügung Bearbeitung und Anzeige der Listen Zum Anlegen, Bearbeiten und Ansehen stellt SharePoint automatisch Standardformulare bereit. Diese zeigen standardmäßig alle bearbeitbaren Felder an. Möchte man diese Verhalten beeinflussen, kann die Ansichtseigenschaft für die jeweiligen Formulare über die Feldeigenschafften konfiguriert werden. Des Weitern könne die Formulare angepasst oder eigene über Lösungen bereitgestellt werden. Für die Adressverwaltung sind dafür Systemfelder über die Feldeigenschaften ausgeblendet. Somit ist die Anpassung von Formularen nicht notwendig. Dadurch kann das dynamische Standardformular (siehe Abbildung 8) weiterhin genutzt werden. Werden einem Kontakt so weitere, benutzerdefinierte Felder hinzugefügt, erscheinen diese automatisch im Formular. Ansichten können, wie in Abschnitt kurz beschrieben, über die Listendefinition bereitgestellt werden. Dafür wurden bei der Adressverwaltung weitere Ansichten hinzugefügt. Automatisch wird bei der Instanziierung der Kontakt-Liste eine Seite mit einem Listenansichts-Webpart erstellt. Ebenfalls über die Listendefinition können der Seite weitere Webparts hinzugefügt oder das bestehende angepasst werden. Darüber ist die Möglichkeit gegeben, das Aussehen der Ansichten zu beeinflussen und erweiterte Funktionen bereitzustellen. Über ein Feature wird zusätzlich eine Seite bereitgestellt auf der die Firmenund Kontaktliste angezeigt werden. Bei Auswahl einer Firma wird über eine vorkonfigurierte Webpartverbindung die Kontaktliste direkt gefiltert, wodurch die Übersicht vereinfacht wird (Beispiel in Abbildung 5) Integration und Nutzung von Webdiensten Wie in Abschnitt 2.4 erwähnt, kam in SharePoint 2013 mit dem App-Modell die Möglichkeit hinzu, auch externe Webanwendungen und Webservices zu nutzen. 14

15 Dies ermöglicht die Webservices freier zu gestalten als es bei Lösungen in SharePoint 2010 möglich war. Es kann nun auf einer eigenen Webanwendung ohne Einschränkungen einer SharePoint Umgebung ein Inhalt bereitgestellt werden, der mit dem SharePoint verbunden ist. Diese Inhalte können dann über das CSOM oder wie in Abbildung 2 dargestellt direkt über einen REST-Webservice lesende und schreibende Aktionen im SharePoint ausführen. Abbildung 2: SharePoint REST Architektur [Mic12b] Da dieser Zugriff über alle gängigen Sprachen möglich ist, sind diese Komponenten nahezu sprachunabhängig. Die Nutzung von SharePoint-Daten ist jedoch über C# einfacher, da hierfür bereits Hilfsfunktionen für die Authentifizierung vorhanden sind. In anderen Sprachen müssen diese erste implementiert werden. Ist diese Webanwendung fertiggestellt, kann sie von mehreren anderen Anwendungen aufgerufen werden. So kann beispielsweise ein mobiles Gerät ebenso wie eine Windows 8 App die Webanwendung anzeigen. Ebenso können eigene Webservices erstellt werden, die zusätzliche Funktionen bereitstellen. Vorteil dabei ist, dass die eigenen Logiken aus dem SharePoint ausgelagert werden können. Ein Webservice kann dabei so gestaltet werden, dass er einfach aus mehreren Sprachen, für mehrere Betriebssysteme genutzt werden kann. Eine Art dies zu realisieren, ist die Web Services Description Language, kurz WSDL. Über diese XML-Definition wird der Aufbau der ausgetauschten Daten festgelegt. Sowohl für den Client als auch für den Server gibt es dafür Tools, welche 15

16 zugehörige Klassen generieren können. Eine weitere, auch von SharePoint selbst genutzte Variante ist ein REST Service. Bei diesem kann beispielsweise über HTTP eine Anfrage auf eine SharePoint-Liste ausgeführt werden. Der REST-Service kann daraus die Listenelemente codiert zurückgeben [Hil12b]. Eine Webanwendung hat, im Vergleich zu einer SharePoint Lösung, zusätzlich den Vorteil, dass sie zentral verwaltet werden kann. Bei einem Update muss diese lediglich einmal aktualisiert werden. Alle anderen Anwendungen in SharePoint oder mobilen Geräten nutzen dann automatisch diese Version. Lediglich die SharePoint-Komponenten müssen aktualisiert werden, was über die Microsoft Plattform einfach vom Kunden ausgeführt werden kann. Für die Adressverwaltung sind Webservices sowohl für die Anbindung externer Geräte als auch für die SharePoint-Komponenten wichtig. Funktionen über den Standard hinaus, wie erweiterte Ansichten oder eben mobile Apps, können die gleiche Logik und Funktionalität über einen zentralen Webservice nutzen Anbindung an mobile Geräte Allgemein lässt sich der Aufbau wie in Abbildung 4 skizzieren. In SharePoint 2010 konnten mobile Applikationen und Anwendungen, wie Browser, nur Funktionen des SharePoints nutzen. Dazu zählt beispielsweise ein Seitenaufruf oder die Anfrage an einen SharePoint-Webservice. Die neueste Version hat neben einem erweiterten Webservice, kurz _api, die Möglichkeit auch externe Webservices z.b. in Azure anzusteuern. Der einfachste Weg, mobilen Geräten Zugang zu SharePoint-Daten zu verschaffen, ist der Browser. Die vorhandene Weboberfläche ist jedoch nur bedingt auf mobile Geräte ausgelegt, da einige Schaltflächen relativ klein sind. Um diese zu optimieren besteht die Möglichkeit das Aussehen der Seiten und Listen gezielt für mobile Geräte zu beeinflussen. Dazu können Listenansichten angepasst werden um diese auf Bedienung und das Display eines mobilen Gerätes zu optimieren. Eine weitere Möglichkeit ist es Seiten und Master Pages anzupassen. Dabei kann über die ASP.NET Komponenten des SharePoints eine Master Page angelegt werden, welche nur für mobile Geräte genutzt wird. Über diese kann das Aussehen einer Seite für den mobilen Zugriff optimiert werden. 16

17 Zusätzlich können Listenansichten für mobile Geräte definiert werden, welche Informationen optimiert für einen kleineren Bildschirm darstellen. Vorteil bei Anpassungen über Master Page und Listenansicht ist, dass jeder Client über den Browser eine optimierte Ansicht bekommt, ohne eine App auf dem Client installieren zu müssen. Es können jedoch keine clientspezifischen Funktionen genutzt werden. Für die Adressverwaltung bedeutet dies, dass ein Kontakt beispielsweise nicht nativ aus einem Smartphone angerufen werden kann. Um dies möglich zu machen, sollen native Apps für verschiedene mobile Plattformen erstellt werden können. An diesem Beispiel kann gezeigt werden, wie Software-Modelle den Aufbau von Applikationen verbessern können. Schon in vorherigen Kapiteln wurden einige Elemente zur Planung, Strukturierung und Umsetzung der Anforderungen genutzt. Dazu gehören beispielsweise UML Modelle, wie use case Diagramme oder Klassendiagramme [Kle11]. Einige Microsoft Frameworks zur Entwicklung mobiler Applikationen für das Windows Phone oder Windows 8 Apps vereinfachen zudem die Nutzung des Model View ViewModel -Musters, kurz MVVM (siehe Abbildung 3). Dieses unterteilt eine Anwendung in Model, View und ViewModel und soll in erster Linie dazu dienen, die Daten von der Visualisierung zu trennen. Dadurch kann die Ansicht angepasst werden, ohne dass dies Auswirkungen auf den Rest der Anwendung hat. Abbildung 3: MVVM [Mic12c] Das Model beschreibt die Daten und deren Bearbeitung. Im SharePoint und der Adressverwaltung sind dies die Listen, Inhaltstypen und Felder für Kontakte und Firmen. 17

18 Der View dient lediglich dazu die Daten anzuzeigen und zu bearbeiten. Diese Daten gelangen über eine Datenbindung des Views an das ViewModel. Das ViewModel dient als Schnittstelle zwischen Model und View. In der mobilen App für ein Windows Phone wäre eine einfache Möglichkeit den View über XAML zu gestalten. Das ViewModel sind C#-Klassen, welche über Webdienste und das CSOM die Daten aus SharePoint für den View bereitstellen. Durch diese Abwandlung des klassischen Model-View-Controller-Patterns [Kle11] sind die Daten von der Ansicht somit getrennt. Dadurch lassen sich die einzelnen Komponenten leichter bearbeiten, warten und testen. Für Microsoft Plattformen kann diese Modell oft schon über die IDE generiert werden. Aber auch alle anderen gängigen Plattformen bieten ähnliche Modelle. So kann beispielsweise sogar über HTML5 und JavaScript mit bestehenden Bibliotheken eine solche Datenbindung realisiert werden [Hil12a]. 18

19 4 Fazit und Ausblick Mit der Einführung der Apps hat SharePoint 2013 durch die Nutzung verbreiteter Technologien auch anderen Plattformen den Zugriff erleichtert. Diese Standards der Webprogrammierung bringen viele ihrer Vor- und Nachteile mit sich. Zum einen bekommen nun Web-Entwickler und weitere Tools Zugang zum SharePoint. Zum anderen waren Sandkastenlösungen oft eher serverlastig und müssen umgeändert werden. Zudem sind die neuen Apps stärker auf den Client ausgelegt. Sprachen wie JavaScript machen es jedoch fast unmöglich, den Code zu schützen. Durch die Vergrößerung des Umfangs des Client-Objektmodells und die Einbindung externer Webanwendungen können Lösungen nun auch an einer zentralen Stelle liegen und sind so wesentlich einfacher wartbar und aktualisierbar. Über den Marketplace werden die Apps nun auch einfacher zu installieren und verbreiten sein. Grundfunktionen von SharePoint, wie Listen und deren Bereitstellung, haben sich jedoch nicht oder nur sehr wenig geändert. Für die Adressverwaltung sind nun die nächsten Schritte, die geplanten Erweiterungen nach und nach umzusetzen. Dazu zählt beispielsweise die Entwicklung nativer Apps für mobile Endgeräte mit Android oder ios oder weitere Komfortfunktionen aus Kundenrückmeldung. Bei Tests wurden sowohl von Anwender- als auch von Entwicklerseite die verschiedenen Anwendungsszenarien erfolgreich getestet. Darunter fallen beispielsweise Tests der entwickelten Klassen, Kompatibilität zu verschiedenen SharePoint Umgebungen und Anwendertests. Die erste Umgebung wurde in SharePoint Online 2010 bereitgestellt und für einen Kunden angepasst. Sowohl Grundfunktionalität, als auch die kundenspezifischen Anpassungen waren einfach bereitzustellen bzw. zu integrieren. Zudem ist die App in der aktuellen Version leicht auf SharePoint 2013 portierbar, einfach zu aktualisieren und lieferte Konzepte für weitere Projekte. Insgesamt kann der Stand des Projektes daher, sowohl aus Kunden- und Entwicklersicht, als erfolgreich angesehen werden. 19

20 5 Anhang Abbildung 4: App-Modell nach [Sha12] 1 <WebPartPages:SPProxyWebPartManager runat=" server " 2 ID= " ProxyWebPartManagerForConnections " > 3 <SPWebPartConnections> 4 <WebPartPages:SPWebPartConnection 5 ConsumerConnectionPointID= "DFWP F i l t e r Consumer ID " 6 ProviderID=" ut_address_company_id_consumer " ID= " c " 7 ProviderConnectionPointID="DFWP Row Provider ID " 8 ConsumerID= " ut_address_company_id_provider " > 9 <WebPartPages:SPRowToParametersTransformer 10 ConsumerFieldNames= " Company" ProviderFieldNames= " ID " > 11 </ WebPartPages:SPRowToParametersTransformer> 12 </ WebPartPages:SPWebPartConnection> 13 </ SPWebPartConnections> 14 </ WebPartPages:SPProxyWebPartManager> Abbildung 5: Beispiel für die Bereitstellung einer Webpartverbindung in einer.aspx-seite 20

21 1 <?xml version = " 1. 0 " encoding =" u t f 8"?> 2 <Elements xmlns= " h t t p : / / schemas. m i c r o s o f t. com / sharepoint / " > 3 <! F e l d d e f i n i t i o n e n > 4 < F i e l d ID= " {45255E92 D7FB 4716 A DFB4EC4} " Required= "FALSE" 5 DisplayName= " Geschä ftsbeziehungstyp " 6 Name= " CompanyBusinessRelationship " 7 StaticName= " CompanyBusinessRelationship " 8 Group= " Adressverwaltung " Type= " Choice " > 9 <CHOICES> 10 <CHOICE>Kunde </CHOICE> 11 <!... > 12 <CHOICE>Sonstiges </CHOICE> 13 </CHOICES> 14 <Default >Kunde </ Default > 15 </ Field > 16 < F i e l d ID= " {9CEA63D0 B7A9 4D8D 904D 6EDBFFBDFF5E} " 17 Required= "FALSE" DisplayName= " Kontakt " Name= " AddressMngContact " 18 StaticName= " AddressMngContact " Group= " Adressverwaltung " 19 Type= " Lookup " L i s t = " L i s t s / Contacts " ShowField= " T i t l e " / > 20 <! Übergeordneter ContentType: Element (0 x01 ) > 21 <ContentType ID= " 0x0100cb79d700f1954bc188a3701cab0c6489 " 22 Name= " Adressverwaltung Firma " Group= " Adressverwaltung " 23 D e s c r i p t i o n = " " I n h e r i t s = "TRUE" Version= " 0 " > 24 <FieldRefs > 25 <FieldRef ID= " { fc2e188e ba91 48c9 9dd afddd50 } " Required= "FALSE" Name= " WorkAddress " DisplayName= " $Resources:core, Address ; " / > 26 <!... > 27 <FieldRef ID= " {45255E92 D7FB 4716 A DFB4EC4} " Required= "FALSE" 28 DisplayName= " Geschä ftsbeziehungstyp " 29 Name= " CompanyBusinessRelationship " / > 30 <FieldRef ID= " {9CEA63D0 B7A9 4D8D 904D 6EDBFFBDFF5E} " Required= "FALSE" 31 DisplayName= " Primä r e r Kontakt " Name= " AddressmngContact " / > 32 </ FieldRefs > 33 </ ContentType > 34 </ Elements > Abbildung 6: Beispielhafter Auszug der Adressverwaltung für Inhaltstypenund Felddefinitionen in XML 21

22 Abbildung 7: Basis-Anwendungsfälle für Kontakte der Adressverwaltung 22

23 Abbildung 8: Formular zur Erstellung eines neuen Kontaktes in der Adressverwaltung 23

24 6 Literaturverzeichnis [dev09] DEVILLA, Joey: SharePoint Diagramm. msdn.com/blogfiles/cdndevs/windowslivewriter/ TechDaysRezaAlirezaeionDevelopingandCons_D8A9/ sharepoint_diagram_f72b9e2d-02d e40-58b1e227f7a9. jpg, [Eva12] [Hil12a] [Hil12b] EVANS, Kirk: Client Side Rendering in SharePoint Server Vortrag auf der SharePoint Conference 2012 in Las Vegas, HILLIER, Scot: JavaScript best practices for developing apps. Vortrag auf der SharePoint Conference 2012 in Las Vegas, HILLIER, Scot: A Primer in HTML5 and Javascript. Vortrag auf der SharePoint Conference 2012 in Las Vegas, [How12] HOWARD, Rob: Understanding authentication for apps for SharePoint. Vortrag auf der SharePoint Conference 2012 in Las Vegas, [Hug11] HUGHES, Kathy: SharePoint Designer 2010 Unleashed. Sams Publishing, ISBN [Kle11] KLEUKER, Stephan: Grundkurs Software-Engineering mit UML. 2., korrigierte und erweiterte Auflage. Vieweg + Teubner Verlag, ISBN [Mic12a] MICROSOFT: solutions. Apps for SharePoint compared with SharePoint jj163114(v=office.15).aspx, [Mic12b] MICROSOFT: Build mobile apps for SharePoint http: //msdn.microsoft.com/en-us/library/jj aspx, [Mic12c] MICROSOFT: Implementing the MVVM Pattern. http: //msdn.microsoft.com/en-us/library/gg405484(v= pandp.40).aspx,

25 [Mic12d] MICROSOFT: What s new for developers in SharePoint jj163091(v=office.15).aspx, [Pia11] PIALORSI, Paolo: SharePoint 2010 Developer Reference. Microsoft Press, ISBN [Sha12] SHAH, Aesha: Building apps for SharePoint. Präsentation bei Jumpstart: Apps for Office and SharePoint in London presentations, [Stu09] STUBBS, Paul: Developing, Deploying, and Monitoring Sandboxed Solutions in SharePoint de-de/magazine/ee aspx, MSDN Magazin [Wen07] WENGER, Rolf: Handbuch der.net-programmierung: Das komplette Wissen, von C#2005 bis zur Client/Server-Programmierung. Microsoft Press Deutschland, ISBN

26 Eidesstattliche Erklärung Hiermit versichere ich, dass ich die Seminararbeit mit dem Thema Plattformübergreifende App-Entwicklung am Beispiel SharePoint selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe, alle Ausführungen, die anderen Schriften wörtlich oder sinngemäß entnommen wurden, kenntlich gemacht sind und die Arbeit in gleicher oder ähnlicher Fassung noch nicht Bestandteil einer Studien- oder Prüfungsleistung war. Aachen, den Torsten Schuster