Die Zukunft von SharePoint

By Henning Eiben in Cloud, Development, Infrastruktur, SharePoint 0 Comment

Letzte Woche war es also so weit – #FutureOfSharePoint. Dabei wurden viele neu Dinge bekannt gegeben, die uns demnächst in Office 365 zur Verfügung stehen werden.

SharePoint Mobile App & OneDrive App

Es wird für Windows, iOS und Android eine neue App geben, mit der man durch SharePoint navigieren kann, ohne dass man extra über den Browser auf die Site zugreifen muss. Zudem wird die OneDrive App in Zukunft nicht mehr nur auf OneDrive beschränkt sein und auch Dateien aus SharePoint und Groups synchronisieren können.

 

SharePoint Home, Modern-UI, Team-Sites und Groups

Die Sites Kachel aus dem App-Launcher wird in SharePoint umbenannt und bekommt auch ein komplett neues Aussehen. Dieser neuer Look ähnelt dem von Delve. In SharePoint Home sind alle meine häufig besuchten Websites zu finden, aber auch Vorschläge für neue Sites.

Nachdem die „mordern document library“ Funktion ja bereits für First-Release Kunden zur Verfügung steht, wird es ein solches Modern-UI auch für Listen geben. Zudem wird das UI auch weiter entwickelt, so dass man direkt Eigenschaften über die Infoleiste am rechten Rand bearbeiten kann. Außerdem werden weitere Befehle ergänzt, die vielleicht heute noch in der Modern-UI fehlen.

Auch die Team-Sites werden einen modernen Look bekommen. Dazu gehört zum einen, dass Inhalte in der Site in Zukunft nicht mehr im Stil einer Wiki Seite erstellt werden, sondern dass der „Editor“ eher aussieht und anfühlt wie man den Editor aus Sway und den neuen Blogs von Delve kennt.

Somit ist also auch für alle „Zweifler“ dieses neuen Looks klar, dass uns dieses neue UI erhalten bleiben wird und dass es kontinuierlich weiterentwickelt wird. Microsoft wird also iterativ die bisher vorhandenen Funktionen in das neue UI überführen.

Von Anfang an war die Frage im Raum: wozu würde man die Office Groups am besten verwenden? Die Verwendung als neue Teamsite, insbesondere z.B. für Projekte, war für mich naheliegend. Allerdings war der Komfort der Groups doch eher bescheiden, da so gut wie keine Anpassungen vorgenommen werden konnten. Ich freue mich, dass die Funktionen der Groups in die neuen Teamsites mit aufgehen. Somit wachen sie Fähigkeiten der Kollaboration der Groups und die Anpassbarkeit einer „normalen“ Teamsite zusammen und ergänzen sich.

Microsoft Flow

Microsoft Flow App Launcher

Diesen Punkt finde ich besonders spannend. Noch vor knapp zwei Wochen habe ich darüber gesprochen, dass ich mir vorstellen könnte, dass die Azure Logic Apps einmal der Nachfolger des Workflow Managers (aka Windows Azure Workflows aka SharePoint 2013 Workflows) werden könnte. Ich hatte in dem Zusammenhang argumentiert, dass mit der Einführung des Workflow Managers Microsoft die Workflows ja schon von der SharePoint Plattform gelöst hat, und zumindest logisch unabhängig von SharePoint gestaltet hat. Somit sollte es relativ einfach möglich sein, dass Backend für die Workflows auszutauschen, da SharePoint die Workflow-Engine ja ohnehin nicht (mehr) kennt.

Und nun haben wir gesehen, dass Microsoft Flow in SharePoint Einzug halten wird. Ob nun für die Kommunikation wirklich die bereits in SharePoint 2013 eingeführte Service-Bus Infrastruktur verwendet wird, oder die ebenfalls neu genannten Webhooks bleibt abzuwarten.

Nun ist also aus den ehemaligen Azure Logic Apps, mit kurzem Umweg über PowerFlow (eigentlich als Teil der PowerApps) Microsoft Flow geworden.

Ein wenig abzuwarten bleibt noch, in wie weit die in den Office Groups kürzlich eingeführten Connectors in dieses Bild passen. Ich würde mal sagen, dass diese Connectoren, die in den Groups ihr Debut gefeiert haben, in Zukunft auch in Microsoft Flow verwendet werden können.

Search - Microsoft Flow

Connect Twitter to Yammer - Microsoft Flow

SharePoint Framework

Die starke Konzentration auf Client-Technologien wird auch in SharePoint immer stärker sichtbar. Das Add-In Modell bot hier ja noch unterschiedliche Wege an mit den Provider-Hosted Apps eine Möglichkeit um z.B. in C# zu entwickeln und mit den SharePoint-Hosted Apps einen Weg um ausschließlich mit Client-Technologie (also JavaScript) zu arbeiten.

Nun wird die JavaScript getriebene Entwicklung noch weiter gestärkt, indem das neue SharePoint Framework auf Visual Studio Code, Typescript und Gulp setzt.

Dies ist ja auch aktuell mein bevorzugter Technologie-Stack um Anpassungen in SharePoint oder Office 365 vorzunehmen – ich freue mich schon auf eine noch bessere Unterstützung insbesondere mit Gulp (und Yeoman). Aber die neuen Client-Side WebParts sehen gut aus – bieten sie doch eine neue Möglichkeit um Anpassungen in Form von WebParts in bestehenden Seiten einzubetten.

Mehr Infos, Links und Videos über die Zukunft von SharePoint gibt es in dem entsprechenden Blog-Post aus dem Office-Team.

Mit Gulp nach SharePoint deployen

By Henning Eiben in Development 0 Comment

Nachdem man nun also seine Entwicklungsumgebung mit VSCode, Node, Bower und Gulp schon sehr gut im Griff hat, stellt sich noch die Frage: wie bekomme ich meine Dateien nun in den SharePoint?

Mit Hilfe von Gulp habe ich ja schon alles nett in einem Verzeichnis (z.B. dist) zusammen. Also muss ich das ja nur alles in den SharePoint laden. Dank Drag&Drop ist das ja recht einfach und der Browser bietet mir ja auch direkt an vorhandene Dateien zu ersetzen. Aber auf die Dauer ist es ja doch irgendwie nervig.

Eigentlich ist die Lösung recht einfach: WebDAV!

Ich kann ja jede SharePoint Bibliothek über WebDAV erreichen. Wenn ich nun auch weiß, dass ich diese WebDAV-Freigaben über eine UNC-Schreibweise ansprechen kann … so kann ich die Bibliothek http://sharepoint.acme.local/sites/henning/scripts auch über \\sharepoint.acme.local\DavWWWRoot\sites\henning\scripts ansprechen.

Entsprechend kann ich in meinem gulpfile.js einfach folgende Task mit aufnehmen

gulp.task('deploy', [], function () {
    return gulp.src(['dist/**/*'])
        .pipe(gulp.dest(\\sharepoint.acme.local\DavWWWRoot\sites\henning\scripts));
};

Wenn ich nun z.B. nach SharePoint-Online deployen will, dann geht das dort ebenfalls, nur dass ich \\henning.sharepoint.com@SSL\[…] schreiben muss, damit der Zugriff per SSL läuft (ich kann SSL natürlich auch bei On-Premise Installationen verwenden, nur bei Office365 geht halt ausschließlich SSL).

Workflow-Verwaltung in Nintex

By Henning Eiben in Development, Infrastruktur 1 Comment

Nintex Workflow für SharePoint 2010 und SharePoint 2013 hat im Januar eine sehr interessante neue Funktion erhalten: Workflow Inventory.

Diese Funktion ist für SharePoint 2013 ab der Version 3.1.7.0 und für SharePoint ab der Version 2.4.7.0 verfügbar.

image

Damit ist es nun möglich aus der Zentraladministration heraus sich einen Überblick über alle vorhandenen Workflows zu verschaffen. Die Übersicht ermöglicht es einem die Site-Collection, die Site die Liste und den Workflow direkt aus der Übersicht heraus aufzurufen.

Zudem ist erkennbar wann ein Workflow zum letzten mal bearbeitet wurde und ob es bereits eine neuer, noch nicht veröffentlichte Version des Workflows gibt. Darüber hinaus kann man auch sehen, wann der Workflow zuletzt ausgeführt wurde. Somit lassen sich z.B. alte und verwaiste Workflows recht leicht identifizieren.

image

Bei sehr vielen Workflows ist diese Ansicht womöglich nicht sehr übersichtlich – dazu kann die Liste auch als CSV-Datei exportiert werden um dann z.B. in Excel weiter ausgewertet zu werden.

Entwicklung mit Visual Studio Code

By Henning Eiben in Development 0 Comment

Ich habe in vorherigen Beiträgen ja schon gezeigt, wie einfach Frontend-Entwicklung sein kann mit den richtigen Werkzeugen. Dazu bedarf es nicht immer einer riesigen IDE wie Visual Studio. Oftmals reicht einfach nur ein guter Editor wie zum Beispiel Notepad++.

Wenn die Entwicklung aber dann doch mal über ein paar Zeilen Code hinausgeht, dann wünscht man sich doch einen Editor, der einen ein wenig mehr unterstützt.

Also doch Visual Studio? Nicht unbedingt. Wenn ich mal eben ein kleines HTML-Frontend bauen will, dann brauch ich zwar schon ein wenig HTML und JavaScript – und genau hier kommt Visual Studio Code ins spiel.

Syntaxhighlighting in Visual Studio Code

Seit letztem Jahr ist VSCode als kleiner, schlanker Editor verfügbar, mit einer Vielzahl an Erweiterungen. Was mir am besten gefällt: VSCode ist keine 100MB schwer. Den kann man mal eben installieren – selbst auf meinem Surface (mit Atom-Prozessor).

Im Gegensatz zum klassischen Visual Studio kennt VSCode keine Solution-Dateien. Das Verzeichnis ist die Solution. Alles was im Verzeichnis ist gehört zum Projekt.

Über Tastenkombinationen kann man zwischen allen Dateien des Projekts navigieren – mit [STRG]+[P] kann man direkt zu einer Datei springen. Eine der Wichtigsten Tastenkombinationen ist [STRG]+[SHIFT]+[P]. Damit kommt man in einen “Kommandomodus” wo man eigentlich alle Funktionen von Visual Studio Code erreichen kann. Ersetzt man das > im Kommandomodus durch ein ? bekommt man eine einfach Hilfe angezeigt.

Kommandomodus von Visual Studio Code

Einige meiner persönlichen Highlights sind:

  • Syntax-Highlighting & Intellisense für verschiedene Sprachen (HTML, JavaScript, PowerShell …)
  • Git Integration
  • Vielfältige Extensions

Wer mehr Erfahren möchte, kann das über

Nintex Site Workflows in Office 365 starten

By Henning Eiben in Development 0 Comment

Nintex Workflow für Office 365 ist ein wenig anders als man dass vielleicht aus den früheren (On-Premise) Versionen gewohnt ist.

So gibt es z.B. keinen Menu-Eintrag in den Site-Actions oder auch keine Einstellungen in den Site-Settings.

Um einen neune Listen-Workflow zu erstellen kann man den Workflow-Designer direkt aus dem Ribbon starten (anstatt über das Workflow-Menu des Ribbons).

image

Aber wie erstellt man einen Site-Workflow? Indem in die Übersicht des Websiteinhalts wechselt und die Nintex-App startet. Hier kann man neue Site-Workflows erstellen

image

image

Workflow-Status in Office 365

By Henning Eiben in Development 0 Comment

Die Workflow-Veteranen kenne es: wenn ich in SharePoint einen neuen Workflow veröffentliche, dann wird in der Liste eine neue Spalte erstellt, die den Status des Workflows wiederspiegelt.

In der Regel sind das: In Bearbeitung, Abgeschlossen, Fehler und Abgebrochen.

image

Über entsprechende Actions im Workflow, kann man hier auch einen anderen Status rein schreiben, z.B. ob ein Inhalt genehmigt wurde oder in welchem Bearbeitungsschritt sich ein Workflow befindet.

Mit SharePoint 2013 hat Microsoft neben der traditionellen Workflow-Engine aus dem .Net Framework auch die Windows Azure Workflows (WAW) mit eingebunden. Diese sind zunächst einmal komplett unabhängig von SharePoint.

Wenn über die WAW ein Workflow veröffentlicht wird, dann wird für diesen Workflow ebenfalls eine neue Spalte angelegt um den Status anzuzeigen, aber der Workflow schreibt im Gegensatz zu den klassischen Workflows wird beim Starten einer neuer Workflow Instanz keinen initialen Status. Das bedeutet, dass die Spalte zunächst leer bleibt.

image

image

image

Das ist deshalb interessant, weil die Spalte eine Link auf die laufende Workflow-Instanz beinhaltet. Mit einem Klick auf den Link bekommt also direkt alle Aufgaben des Workflows sowie den Workflow-Verlauf angezeigt. Ist die Spalte leer, gibt es als Konsequenz auch keinen Link und somit kommt man nur über das Workflow-Menu des jeweiligen Elements an den Workflowverlauf.

Als Lösung sollte man also als ersten Schritt in einem Workflow immer einen Status setzen – damit sichergestellt ist, dass es den Link in der Spalte auch gibt. Wenn man mit dem SharePoint-Designer einen Workflow erstellt, dann wird automatisch als Status der Name der jeweiligen Workflow-Stufe eingefügt, bei Nintex muss man das manuell mit einer entsprechenden Action machen.

image

image

Zu beachten ist außerdem, dass am Ende des Workflows der Status ggf. noch auf “Abgeschlossen” oder so gesetzt werden sollte. Das gilt sowohl für Nintex als auch für Designer Workflows, sonst bleibt in der Spalte der zuletzt gesetzte Status stehen, der ggf. nicht den tatsächlichen Status des Workflows wiederspiegelt.

image

Recap: European SharePoint Conference 2015 in Stockholm

By Henning Eiben in Events, SharePoint 0 Comment

Letzte Woche war es nun endlich so weit – die European SharePoint Conference 2015 (ESPC) fand in Stockholm statt.

Das Line-Up war schon recht beeindruckend: mehr als 1.500 Teilnehmer aus über 50 Ländern konnten sich in über 100 Sessions in acht parallelen Tracks drei Tage lang um alle möglichen Aspekte rund um SharePoint und Office365 austauschen.

Generell waren sehr viele Entwickler-Orientierte Vorträge vorhanden, insbesondere im Zusammenhang mit Office 365 (Unified API) und Azure Active Directory. Ich denke, dass sind die Building-Blocks der Zukunft um Lösungen auf/um/für Office 365 zu entwerfen.

Ein Highlight war am zweiten Tag die Gala auf der unter anderem die Top 25 European Office 365 Influencer geehrt wurden. Diese Gala fand in der City Hall von Stockholm statt, in der sonst auch der Nobel-Preis verliehen wird – ein durchaus beeindruckendes Ambiente für eine solche Veranstaltung!

Keynote

Die ESPC wurde durch eine Keynote von Jeff Teper, Seth Patton und Bill Baer eröffnet. Dabei wurden die Herausforderungen an moderne IT Systeme klar herausgestellt:

  • weiter voranschreitende Digitalisierung unseres Arbeitsalltags
  • stärker Vernetzung
  • immer größere Mengen an Daten
  • sinnvoll und übersichtlich Aufbereitung von Daten

Dazu wurden die aktuellen Entwicklungen in Office 365, OneDrive (for Business) und SharePoint (2016) vorgestellt.

In einer weiteren Keynote zeigte Geoff Evelyn, dass Fortschritt nur dann erreicht werden kann, wenn man sich die Zeit nimmt um auch einen Blick in die Vergangenheit zu werden, das erreichte zu reflektieren und daraus neue Ausrichtungen für die Zukunft zu treffen.

SharePoint 2016

In diesem Zusammenhang wurde die SharePoint 2016 Beta 2 angekündigt, dessen Nachricht auch vom Office Team auf dem Blog veröffentlicht wurde. Diese Beta soll bereits 99% der finalen Funktionen enthalten. Was sich alles in der Beta 2 getan hat kann im Blog nachgelesen werden.

Außer der Ankündigung der Beta 2 von SharePoint 2016 waren keine großen Ankündigungen zu vernehmen. Stattdessen werden wir insbesondere in Office 365 weiterhin immer wieder kleine Veränderungen sehen. Features werden nicht mehr über Monate gesammelt und dann in einem “Big Bang” veröffentlicht, sondern Features werden veröffentlicht wenn sie “bereit” sind.

Yammer

Was in den drei Tagen ESPC aufgefallen ist: während Yammer auf der ESPC 2014 in Barcelona in nahezu jedem Vortrag eine Rolle spielte, wurde Yammer dieses Jahr bis auf wenige Ausnahmen (oder Ausrutscher?) nicht genannt. Hier hätte ich erwartet öfter Office Groups zu hören – aber auch das ist eher im Hintergrund geblieben. Dennoch denke ich, dass wir uns von dem Brand Yammer irgendwann verabschieden müssen. Die Funktionen werden dann in anderen Produkten aufgehen – vielleicht in den Groups.

Workflow Special

Mein persönliches Highlight war natürlich das Workflow Tool Special – wo ich für Nintex angetreten bin um zusammen mit anderen Kollegen exemplarisch zu zeigen wie man einen typischen Geschäftsprozess mit SharePoint Brodmitteln, K2, Nintex und WebCon umsetzen kann. Wer nicht dabei sein konnte: am 3.12. gibt es noch einmal die Gelegenheit das Workflow Special auf den SharePoint Days in München zu besuchen.

Zum Thema European SharePoint Conference gab es unter dem Hashtag #ESPC15 viele interessante Tweets. Ein paar Top Tweets haben wir gesammelt.

Gulp: Wie Coffeescript zu JavaScript wird

By Henning Eiben in Development 0 Comment

Nachdem ja nun einfache Dinge mit gulp automatisiert werden können, kann man sich ja so langsam mal an weitere Aufgaben begeben.

Coffeescript kann bei der Arbeit mit JavaScript ja schon mal ganz hilfreich sein, nimmt es einem doch manch lästige Zeremonie von JavaScript ab und fügt gleich noch Best-Practices hinzu. Wenn man nicht immer diese .coffee-Datei nach JavaScript übersetzen (compilieren) müsste.

Mit gulp kann man das sehr gut automatisieren.

npm install gulp-coffee --save-dev

sorgt dafür, dass ich das notwendige gulp-coffee Package habe. Nun also noch eine entsprechen Task im gulpfile.js einfügen.

gulp.task('coffee', function () {
    return gulp.src('app/*.coffee')
        .pipe(coffee())
        .pipe(gulp.dest('app'));
})

In diesem Fall werden also alle von Coffee-Script erzeugten Dateien ebenfalls in dem Verzeichnis app gespeichert.

Insgesamt sieht das Build Script nun so aus:

var gulp = require('gulp'),
    coffee = require('gulp-coffee'),
    uglify = require('gulp-uglify');

gulp.task('html', function () {
    return gulp.src('app/*.html')
        .pipe(gulp.dest('dist'));
})

gulp.task('js', ['coffee'], function () {
    return gulp.src('app/*.js')
        .pipe(uglify())
        .pipe(gulp.dest('dist'));
})

gulp.task('coffee', function () {
    return gulp.src('app/*.coffee')
        .pipe(coffee())
        .pipe(gulp.dest('app'));
})

gulp.task('default', ['html', 'js'], function () {
})

Die Task „js“ ist dabei Abhängig von der Coffee-Task. In der Konsole sieht die Ausführung dann so aus:

D:\projects\html_app>gulp
[14:43:24] Using gulpfile D:\projects\html_app\gulpfile.js
[14:43:24] Starting 'html'...
[14:43:24] Starting 'coffee'...
[14:43:24] Finished 'coffee' after 34 ms
[14:43:24] Starting 'js'...
[14:43:24] Finished 'html' after 47 ms
[14:43:24] Finished 'js' after 43 ms
[14:43:24] Starting 'default'...
[14:43:24] Finished 'default' after 13 μs

Gerade beim Umgang mit Coffeescript ist das Debugging des JavaScript Codes z.B. in der Konsole der Browsers etwas umständlich, denn hier wird ja nicht der eigentliche Coffeescript Code debuged, sondern der von Coffeescript erzeugte JavaScript Code. Moderne Browser können aber mit Hilfe von sogenannte SourceMaps auch den ursprünglichen Quellcode anzeigen und debuggen – hier also Coffeescript. Und auch dabei kann gulp helfen.

Dazu erweitern wir die Task coffee entsprechend.

gulp.task('coffee', function () {
    return gulp.src('app/*.coffee')
        .pipe(sourceMaps.init())
        .pipe(coffee())
        .pipe(sourceMaps.write('../dist'))
        .pipe(gulp.dest('app'));
})

Nun wird für jede Coffeescript-Datei eine entsprechende SourceMap-Datei in dem Verzeichnis dist erstellt.