Alles automatisch

Automatisierung in Office 365 und SharePoint Online mit Azure
Kommentare

Microsoft hat in den letzten Monaten stark in Office 365 und SharePoint Online investiert. Dennoch gilt SharePoint Online im deutschsprachigen Raum immer noch als „SharePoint Light“ mit stark eingeschränkten Funktionen in Bezug auf Anpassungen. Wir zeigen am Beispiel einer kompletten Brandinglösung für SharePoint Online auf, dass automatische Anpassungen sehr wohl möglich sind, wie neue Websites bei der Erstellung automatisch an die Kundenwünsche angepasst werden, welche Rolle Microsoft Azure dabei spielt und welche Muster dazu verwendet werden können.

Wer SharePoint täglich nutzt, weiß, dass die Plattform erst durch einen gewissen Grad an Automatisierung effizient nutzbar wird und ihr volles Potenzial entfalten kann. Wenn der Benutzer häufig dieselben Dinge zusammenklicken muss, wird dies irgendwann lästig und die Plattform wird unter Umständen wenig oder gar nicht mehr verwendet. SharePoint bietet für Anpassungen mehrere Schnittstellen an. Die umfangreichsten Möglichkeiten bieten dabei die sog. Farmlösungen (engl. Farm Solutions). Fast jedes SharePoint-Artefakt lässt sich nach Belieben durch die Programmierschnittstelle anpassen und erweitern. Die technische Entwicklung zeigt jedoch immer mehr in Richtung Cloud-Lösungen. Insbesondere Microsoft hat in den letzten ein bis zwei Jahren den Fokus auf Office 365 und weitere Cloud-Dienste gelegt. Ein wichtiger Baustein innerhalb von Office 365 ist dabei SharePoint Online. Und gerade dort können Farmlösungen nicht mehr verwendet werden. Dies macht ergibt Sinn, wenn man bedenkt, was geschehen würde, wenn Hunderte von Kunden beliebigen Code in der Office-365-Cloud ausführen könnten. Daher wurde mit der SharePoint-Version 2013 ein neues Modell der Programmierung hinzugefügt: das Cloud Application Model. Dieses erlaubt zwar nur einen eingeschränkten Zugriff auf das bisherige API, kann aber in der Cloud wie auch auf lokalen Serverinstallationen ausgeführt werden.

Das Cloud Application Model ist jedoch in vielerlei Hinsicht ungewohnt und bisherige Lösungsansätze, die mit Farmlösungen wunderbar funktioniert haben, müssen nun überdacht werden. Viele eingefleischte SharePoint-Programmierer bekunden Mühe mit dem neuen Modell. Sieht man sich doch nun trotz jahrelanger Erfahrung wieder zu den Anfängen zurückversetzt und es scheint, als müsse man einiges über Bord werfen und neu erlernen. Dazu sei gesagt: Es ist sehr vieles möglich in SharePoint Online. Diese Aussage zu untermauern, ist eines der Ziele dieses Artikels. Wir werden anhand einer beispielhaften Brandinglösung zeigen, dass es in SharePoint Online sehr wohl möglich ist, Arbeitsschritte zu automatisieren und somit auch in der Cloud das Potenzial von SharePoint voll zu entfalten. Dies bedingt, sich von den bisherigen Ansätzen loszulösen und die funktionalen Anforderungen mithilfe der neuen Mittel und Werkzeuge umsetzen zu lernen.

Vorbemerkungen

Dieser Artikel geht davon aus, dass Sie bereits Erfahrung mit SharePoint-Programmierung haben und die grundlegenden Konzepte verstehen. Aus Platzgründen ist es nicht möglich, allzu detailliert auf den Code einzugehen. Stattdessen werden einzelne bedeutsame Zeilen aufgeführt und erklärt.

Definition Branding

Wir möchten anhand eines Brandingbeispiels belegen, dass SharePoint Online automatisiert werden kann und Ihnen die dazu benötigten Muster näherbringen. Doch zuerst muss geklärt werden, was man überhaupt unter Branding versteht. Branding oder auch Websitebranding beschreibt in diesem Kontext das Anpassen einer Website an das Corporate Design einer Firma oder Organisation. Dies kann von der Einbindung des Firmenlogos über die Schriftarten und Farben bis zur Schriftgröße und sogar vorgegebenen Zeilenabständen alles beinhalten. Neben dem gewünschten Wiedererkennungswert wird dadurch häufig eine ästhetische Verbesserung gegenüber dem Standardbranding einer Teamwebsite erzielt und somit auch die Benutzerakzeptanz erhöht. Grundsätzlich bieten SharePoint Server wie auch SharePoint Online dieselben Möglichkeiten, das Aussehen einer Site zu beeinflussen. Die Masterpage definiert die grundsätzliche Struktur einer auf dem Bildschirm dargestellten Seite – unabhängig vom Inhalt. In SharePoint beinhaltet die Masterpage diverse Platzhalter, die während des Ladevorgangs der Seite von SharePoint befüllt werden. Beispiele für solche Platzhalter sind das Websitelogo und die Suchbox. „Durchkomponierte Looks“ (engl. Composed Looks) abstrahieren einige der Designelemente, indem sie aus Farbschemadatei, Masterpage, Schriftendatei und ggf. einem Hintergrundbild bestehen (Abb. 1). Dies soll es den Benutzern vereinfachen, neue Designs schneller zusammenzustellen.

Abb. 1: Durchkomponierte Looks in SharePoint Online

Abb. 1: Durchkomponierte Looks in SharePoint Online

 

Erstellen von Farbschemadateien für die Designvorlagen Die Erstellung der Farbschemadatei (.spcolor) für einen durchkomponierten Look kann sehr aufwändig werden. Immerhin besteht eine solche Datei aus 89 verschiedenen Farbangaben, die die verschiedenen Farbabstufungen repräsentieren. Glücklicherweise existiert ein einfach zu bedienendes und zudem freies Tool, das einem diese Arbeit weitestgehend abnimmt: das „SharePoint 2013: Color Palette Tool“.

Zurzeit gibt es verschiedene Ansichten, welches der beste Ansatz für das Branding einer SharePoint-Online-Website ist und ob die sog. Masterpage überhaupt angepasst werden sollte. Problematisch ist vor allem, dass eigene Masterpages etwaige Verbesserungen oder Änderungen bei Updates nicht mitbekommen und händisch anzupassen sind. Wir überlassen es dem Leser, sich selbst ein Bild zu machen und beschränken uns in den folgenden Beispielen auf das Anwenden von Gestaltungsvorlagen, d. h. wir verwenden eine Standard-Masterpage. Das Hochladen einer eigenen Masterpage kann mit ein bis zwei Zeilen mehr ebenfalls realisiert werden. Folgende Schritte müssen somit vorgenommen werden:

  • Erstellen eines Themes
  • Anwenden eines Themes

Um ein Theme zu erstellen und anzuwenden, verwenden wir das CSOM-API von Office 365 und führen diesen Code im Kontext einer Provider-hosted App aus. Mithilfe der „O365 Dev Patterns & Practices“ (ehemals „Office Application Model Samples“) kann der Code sogar auf zwei Zeilen reduziert werden. Die „O365 Dev Patterns & Practices“ sind eine Sammlung von Beispielen und Hilfsklassen, die häufige Operationen vereinfachen. Die Sammlung wird regelmäßig von Microsoft-Mitarbeitern aktualisiert sowie verbessert und kann von GitHub heruntergeladen werden.

Für unsere Zwecke empfiehlt es sich, gleich das gesamte Projekt mit Hilfsklassen im Stil von OfficeDevPnP.Core in die eigene Visual-Studio-Solution einzupflegen. Die BrandingExtension enthält dabei wertvolle Erweiterungen für das Webobjekt. Wenn wir davon ausgehen, dass wir die Dateien (eine Farbschemadatei, eine Schriftartendatei und ein Hintergrundbild) für die Designvorlage bereits in unser Visual-Studio-Projekt eingebunden haben (Abb. 2), können wir die Erstellung und Anwendung des Themes schnell hinter uns bringen.

Abb. 2: Eingebundene Gestaltungsvorlage in Visual Studio

Abb. 1: Durchkomponierte Looks in SharePoint Online

 

Mithilfe der BrandingExtension können wir das Theme in zwei Aufrufen hochladen und anwenden (Listing 1).

// Theme hochladen
rootWeb.DeployThemeToWeb("1stQuad",
HostingEnvironment.MapPath(string.Format("~/{0}", "Resources/Themes/1stQuad/1stQuad.spcolor")),string.Empty,HostingEnvironment.MapPath(string.Format("~/{0}", "Resources/Themes/1stQuad/1stQuadbg.jpg")),string.Empty);
// Theme setzen
rootWeb.SetThemeToWeb("1stQuad");
// Setzen des Markers
web.SetPropertyBagValue(BrandingHelper.BrandingMarkerID, 1);

Damit wir nicht bereits angepasste Sites nochmals anpassen, hinterlegen wir einen Marker mit einer Versionsnummer. Somit bleibt die Anpassung effizient und ermöglicht uns trotzdem, das gesamte Branding auf einen Schlag anzupassen. Mit der folgenden Zeile lässt sich der Marker abfragen:

web.GetPropertyBagValueInt(BrandingHelper.BrandingMarkerID, 0)

Somit wissen wir nun, wie wir ein Branding auf eine Site anwenden und auch wie wir prüfen können, ob das Branding schon appliziert wurde. Unser Ziel ist aber, dass einerseits bestehende Websites und Seiten, aber auch neu erstellte Websites unser Websitebranding – sprich: die Gestaltungsvorlage – übernehmen und somit ein einheitliches Erscheinungsbild gewährleistet wird. Bereits existierende Websites und Seiten anzupassen, ist ein einmaliger Vorgang, der theoretisch auch durch ein einfaches Konsolenprogramm erledigt werden könnte. Etwas kniffliger wird es, wenn wir sicherstellen wollen, dass auch sämtliche zukünftig erstellten Websites unser Branding übernehmen. Dafür muss unser Programm sich in SharePoint einklinken und zwar ganz nach Anwendungsfall auf unterschiedliche Weise.

Muster (Patterns)

Wie bereits angedeutet, ist das Anpassen von bestehenden Websites das kleinere Übel. Das dazu notwendige API ist im Client-Side Object Model von SharePoint vorhanden, und es könnte auch ein einfaches Konsolenprogramm geschrieben werden, das die bestehenden Websites anpasst. Etwas eleganter als ein Konsolenprogramm ist das App-installed Event, das sich in Visual Studio relativ bequem über die App-Properties aktivieren lässt (Abb. 3).

Abb. 3: App-Events in Visual Studio

Abb. 3: App-Events in Visual Studio

 

Mit anderen Worten: Wir passen die bestehenden Websites und Websitesammlungen schon bei der Installation der App an. Wir beabsichtigen, gleich alle Websitesammlungen im Mandanten (Tenant) anzupassen. Listing 2 zeigt, wie wir im App-Event durch alle Websitesammlungen iterieren können.

SPOSitePropertiesEnumerable spp = tenant.GetSiteProperties(0, true);
adminContext.Load(spp);
adminContext.ExecuteQuery();
// Iteriere durch alle Site Collections des Mandanten
foreach (SiteProperties sp in spp)

var currentSiteUrl = sp.Url;
// Wir lassen die Admin Site Collection aus ...
if(currentSiteUrl.ToLower() != adminUrl.ToLower())
{
var site = tenant.GetSiteByUrl(string.Format(System.Globalization.CultureInfo.CurrentCulture, sp.Url));
// Gehe durch alle Sites der Site Collection und wende das Branding an ...
...

Für jede Websitesammlung wird dann wiederum über alle Sites iteriert und wie bereits aufgezeigt das Branding appliziert. Nun haben wir also die Bausteine zusammen, um alle bestehenden Websites mit unserem Websitebranding zu versehen. Etwas komplexer wird es, wenn wir neu erstellte Websites anpassen wollen und zwar so, dass der Benutzer ausschließlich das angepasste Resultat sehen kann. Dabei gibt es folgende drei Anwendungsfälle: 1. Benutzer erstellt eine neue Unterwebsite (über Websiteinhalte) 2. Benutzer erstellt eine neue Website (Websitesammlung) über EINE NEUE WEBSITE STARTEN 3. Benutzer erstellt eine neue OneDrive-Site Alle drei Fälle müssen berücksichtigt werden, damit wir ein durchgängiges Branding gewährleisten können. Wir werden nun jeden Fall einzeln behandeln und eine entsprechende Lösung skizzieren. Dabei stützen wir uns wiederum auf die bereits geleistete Vorarbeit der „O365 Dev Patterns & Practices“.

Erstellen von Unterwebsites

Könnten wir weiterhin Farmlösungen verwenden, wäre der Fall klar: Wir würden einen Event Handler schreiben, der beim Provisionieren einer neuen Website aufgerufen wird, und schon hätten wir Handhabe genug, unser Branding anzuwenden, noch bevor der Benutzer die neu erstellte Website das erste Mal zu Gesicht bekommt. Im Cloud Application Model haben wir diese Möglichkeit nicht. Stattdessen können wir einen anderen Ansatz verwenden: Wir überschreiben den Hyperlink „Neue Website“ (Abb. 4) oder – genauer gesagt – kapern ihn, indem wir den Link auf unsere eigene „Provider-hosted App“ führen.

Abb. 4: Link zum Erstellen einer neuen Unterwebsite

Abb. 4: Link zum Erstellen einer neuen Unterwebsite

 

Verwendet der Benutzer den Link „Neue Website“, wird er direkt auf unsere App weitergeleitet. Dort wird dem Nutzer scheinbar das übliche Formular angezeigt. Tatsächlich handelt es sich aber um eine Seite unserer App. Sobald die notwendigen Daten wie Titel, URL etc. eingegeben wurden und die Erstellung durch Klick auf die Schaltfläche „Erstellen“ bestätigt wird, kann unsere App eigenen Code ausführen. Einerseits muss hierbei natürlich die Unterwebsite erstellt werden, andererseits sind wir nun frei, beliebige Anpassungen zu machen. Genauso gut ließen sich auch weitere Parameter im Formular abfragen, die für die Erstellung der Unterwebsite verwendet werden könnten.

Um die Schaltfläche „Neue Website“ zu kapern, verwenden wir eine Custom Action zum Einschleusen von JavaScript. Innerhalb dieses Skripts prüfen wir, ob sich der Nutzer gerade auf der „Websiteinhalte“-Ansicht befindet (viewlsts.aspx) und falls dem so ist, überschreiben wir den Link des HTML-Elements mit der ID createnewsite.

An dieser Stelle mag der erfahrene SharePoint-Berater ein ungutes Gefühl in der Magengegend verspüren: Was passiert, wenn Microsoft beschließt, mit einem künftigen Update die ID des Linkelements abzuändern oder zu entfernen? Die Frage ist berechtigt, und es gibt keine Garantie, dass dies nicht passiert. Allerdings schätzen wir die Wahrscheinlichkeit als sehr gering ein, nicht zuletzt, da man sich die Mühe gemacht hat, dem Element eine eigene ID zuzuweisen. Wir empfehlen, stets einen Testmandanten zu betreiben, damit solche Änderungen frühstmöglich bemerkt und die entsprechenden Anpassungen eingeleitet werden können.

Somit haben wir alle Bausteine zusammen, um das Erstellen von neuen Unterwebsites abzufangen: • Eine Custom Action, die JavaScript einspeist und die Schaltfläche „Neue Website“ überschreibt • Eine Provider-hosted App, die ein Formular anzeigt sowie Unterwebsites erstellt und anpasst (bzw. das Branding appliziert)

Provider-hosted App – Was ist das? Eine Provider-hosted App ist vereinfacht gesagt eine Website, die meist nicht innerhalb der SharePoint-Umgebung läuft und gewisse Aufgaben für uns ausführt. Die Website kann dabei lokal auf einem Entwicklungscomputer, in Microsoft Azure oder auf einem beliebigen anderen Server betrieben werden. Man kann sich den Aufruf einer Provider-hosted App als delegierte Funktionalität vorstellen: SharePoint übergibt der App Informationen und die App führt außerhalb von SharePoint Operationen aus. In unserem Fall wird diese Website Code des Client Object Models ausführen und damit das Branding anwenden. Somit läuft der entsprechende Code nicht in der Cloud, und ein Programmierfehler würde sich auch nicht auf die Office-365-Cloud auswirken. Das Gegenstück zur Website der Provider-hosted App ist die App selbst, die im App-Catalog des SharePoint-Mandanten registriert wird. Sie definiert, welche Berechtigungen die App-Website hat bzw. welche Operationen ausgeführt werden dürfen. Hierbei gibt es ähnliche Abstufungen wie bei den Benutzerrechten in SharePoint. Bei der Installation einer App muss der Benutzer den erforderlichen Rechten zustimmen, ansonsten wird die Installation abgebrochen. Zudem ist in der App auch vermerkt, wo die (Provider-hosted) Website zu finden ist. Besonders spannend ist, dass unsere Provider-hosted Website nicht zu wissen braucht, wie und ob SharePoint den Benutzer authentifiziert. Über das OAuth-Protokoll wird sichergestellt, dass keine Aktionen ausgeführt werden, die den Rahmen der Berechtigungen der App oder des Users überschreiten.

Erstellen von Websitesammlungen

Benutzer haben in SharePoint Online die Möglichkeit, neben Unterwebsites von bestehenden Websitesammlungen auch neue Websitesammlungen anzulegen. Dies muss vom Administrator konfiguriert werden und ist einiges einfacher zu realisieren als das Erstellen von Unterwebsites.

Der Administrator kann im SharePoint-Admin-Bereich unter EINSTELLUNGEN das Verhalten von EINE NEUE WEBSITE STARTEN konfigurieren. Hierbei gibt er an, unter welchem Pfad die neuen Websitesammlungen liegen sollen. Zusätzlich kann er auch definieren, welches Formular dazu verwendet werden soll. Wir geben einfach den Link zu einer Seite der bereits installierten Web-App an. Wir lassen also den Benutzer das Formular innerhalb einer Provider-hosted App aufrufen und können so die Erstellung der Site analog der Unterwebsite kontrollieren (mit dem Unterschied, dass wir kein JavaScript einschleusen müssen). Im Gegensatz zum direkten Aufruf der App müssen wir bei der Konfiguration des Verhaltens von EINE NEUE WEBSITE STARTEN den SPHostUrl-Parameter bereits festlegen. Wir geben daher den URL des OneDrive-Hosts an (z. B. https://demokob-my.sharepoint.com), da dieser für alle Benutzer zugänglich ist. Somit sieht der eingetragene URL (in der Entwicklungsumgebung) aus wie in Abbildung 5.

Abb. 5: Link zum Aufruf von „Start a Site“

Abb. 5: Link zum Aufruf von „Start a Site“

 

Da wir den OneDrive-Host angeben, wird auch dessen Branding im angezeigten Dialog übernommen. Daher ist es wichtig, dass das Branding in unserem App-Installed-Ereignis auch auf den OneDrive-Host angewendet wird.

Erstellen von OneDrive-Sites/MySites

Dieser Anwendungsfall unterscheidet sich wesentlich von den bisherigen, denn OneDrive-Sites gehören ausschließlich dem zugewiesenen Mitarbeiter. Das heißt, dass nur er die entsprechenden Anpassungen vornehmen darf. Zusätzlich werden OneDrive-Sites generell asynchron erstellt. Klickt ein Benutzer das erste Mal auf den entsprechenden Link, wird er darauf hingewiesen, dass es einige Zeit dauern kann, bis die OneDrive-Site bereit ist, und er kann bereits andere Aktionen ausführen – muss also nicht warten. Wir erinnern uns, dass wir bei der Erstellung von Websitesammlungen warten mussten, bis die Websitesammlung komplett erstellt war und wir weiternavigieren konnten.

Da die eigentliche Erstellung asynchron verläuft und die Anpassung des Brandings durch den Benutzer selbst erfolgen muss, wenden wir einen anderen Ansatz als bisher an: In so gut wie allen Portalen – unabhängig davon, ob es als Extranet, Intranet oder als Kollaborationsplattform genutzt wird – existiert eine Startseite. Hier platzieren wir ein verstecktes App-Part, das für den Nutzer die Anpassungen der OneDrive-Site vornimmt, sofern notwendig. Sobald der Nutzer auf die Startseite navigiert, wird der Code im App-Part ausgeführt. In unserer Visual-Studio-Solution erstellen wir dazu eine neue Page (z. B. OneDriveTuner.aspx), die wir dann im App-Part anzeigen. Im Code der Page können wir schließlich die OneDrive-Site ermitteln und das Branding anwenden (Listing 3).

// Ermittle OneDrive-Site
ProfileLoader loader = Microsoft.SharePoint.Client.UserProfiles.ProfileLoader.GetProfileLoader(clientContext);
UserProfile profile = loader.GetUserProfile();
Microsoft.SharePoint.Client.Site personalSite = profile.PersonalSite;
clientContext.Load(personalSite);
clientContext.ExecuteQuery();
...

Folgende Schritte werden ausgeführt:

• Prüfung, ob Anpassung bereits vorgenommen • Anpassen der OneDrive-Site unter dem Konto des Benutzers

Was genau ist ein App-Part? Vereinfacht gesagt ist ein App-Part ein iframe, das innerhalb einer SharePoint-Seite dargestellt wird. App-Parts sind grundlegend anders als Web Parts: Sie führen keinen serverseitigen Code auf SharePoint aus, sondern sind in unserem Fall nur ein Fenster zu einer Provider-hosted App. Ein App-Part ist auch nur dann verfügbar, wenn die zugehörige App auf der entsprechenden Website installiert wurde.

Fazit

Wir haben aufgezeigt, dass es mit etwas Aufwand möglich ist, eine SharePoint-Online-Umgebung zu automatisieren und somit trotz eingeschränkter Freiheiten für Entwickler das gleiche Resultat wie in einer lokalen Farm zu erreichen. Die Ansätze sind anders, als man es gewohnt ist, und erscheinen auf den ersten Blick unkonventionell, ermöglichen aber eine Vielzahl von Anwendungen. Zum Schluss sei angemerkt, dass die Entwicklung von SharePoint Online schnell voranschreitet und beinahe wöchentlich neue Updates erscheinen. Leider bedeutet dies auch, dass nicht gewährleistet werden kann, dass die aufgeführten Ansätze in einigen Monaten noch gültig sind. Halten Sie sich auf dem Laufenden, indem sie das Office-Developer-PnP-Projekt verfolgen und die Office Blogs regelmäßig konsultieren. In den Referenzen finden Sie weitere Blogs mit hilfreichen Informationen.

Aufmacherbild: Automate word on a red computer keyboard button or key to improve a process and make work more efficient and productive von Shutterstock / Urheberrecht: iQoncept

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -