Wednesday, October 12, 2016

First look at SharePoint Framework

Background

In the history of development for SharePoint many different development platforms have been introduced over the years. Among these were full trust solutions, bin-folder deployments, sandboxed solutions, Client-side object model, the different models for building Add-ins and JavaScript in a script editor webpart. And shortly we will have yet another way to customize SharePoint On-premises and Online, the SharePoint Framework (SPFx)!
This new development model does not really bring new capabilities with it but is instead (finally) a real delivery platform for building JavaScript solutions in a structured way. JavaScript has always been present in Web development and has, in recent years, matured and even taken over server-side development through NodeJS. Frameworks such as AngularJS, KnockOutJS and React are standard tools for front-end development since the introduction of highly user friendly Single Page Applications. The SharePoint framework is aimed to bring SharePoint development into the realm of the ‘common’ web developer in order to greatly increase the number of developers that can customize the platform.
This document describes my first experiences and thoughts on the new development model and the repercussions of it for SharePoint developers.

Introduction

SPFx will be available on SharePoint Online in Q4 of 2016 and later be deployable to SP2016 through a Feature Pack. The introduction in SharePoint Online will go together with several other changes among which is the new responsive page model. The new page model changes the way a user can edit the content of pages, greatly improving the user experience because no page reloads are required. This is the way almost all big web platforms work and soon SharePoint will too!
Beside the responsiveness of the buttons and other controls to edit pages, the pages themselves will also be designed in such a way that they are mobile accessible. The pages will respond to the user’s device to show an optimized view of the page for that screen. Finally, the new page model allows for almost full-screen customization of the page, only a small portion is reserved for the ribbon and a side menu. This makes it easier for developers to make SPAs in O365 and increase the usability of SharePoint. SPFx WebParts will be available on the new page model, the older ‘classic’ type pages and a little later also on publishing pages.
The SharePoint framework webparts are built with a multitude of web development tools such as NodeJS and Yeoman, which will be discussed below. The tools can also minify and package the SPFx webpart as an .spapp package which is deployed to your farm via the App Catalog. Microsoft’s idea is that you deploy the source files of your webparts to a publicly accessible CDN location. This should make the files quickly accessible to end-users all around the world, and is a more maintainable deployment location than in Style libraries or masterpage galleries scattered throughout your entire SharePoint farm, where they might be deleted or corrupted by power users in the business.
The project templates for building a SPFx WebPart supports several JS frameworks (KnockOutJS and React) for development and more will follow. This nudges developers to start using a framework which will increase stability and maintainability of the code.
Microsoft mentions the following characteristics of SPFx:
·        It runs in the context of the current user and connection in the browser. No iFrames.
·        The controls are rendered in the normal page DOM.
·        The controls are responsive and accessible by nature.
·        There is a life cycle that the developer is involved in.
·        It’s not just render, but load, serialize _and _deserialize, configuration changes, etc.
·        It is framework agnostic – You can use any browser framework that you like – React, Handlebars, knockout, angular – take your pick.
·        The tool chain is based on common open source client development tools like npm, TypeScript, yeoman, webpack, gulp, etc.
·        Performance is key.
·        SPFx client-side solutions that are approved by the tenant administrators (or their delegates) can be used by end users on all sites – even self service created sites like teams, groups, personal, etc.
·        Can be deployed in both classic web part and publishing pages as well as the modern pages.

Tooling

The necessary tooling for building SPFx webparts is vast and for most SharePoint developers an entirely new world. However, it is the standard for common web development and will bring new people to SharePoint but also open up new opportunities for SP developers that are willing to learn something new.
First of all you will need NodeJS and its package manager NPM. Through the package manager you will need to install the project generator (Yeoman) and the task handler (Gulp). When you then install the Yeoman project template for SPFx webparts you will get the SharePoint workbench with it. The SharePoint workbench is a local development tool that you can use to locally develop and test a SPFx WebPart. In order to be able to deploy a SPFx webpart to Office365 you will most likely want to use an Azure storage account with CDN endpoint. Any CDN will do but the Yeoman project template includes the gulp tasks to deploy to an Azure storage account automatically. The dependence of SPFX Webparts on a CDN (and possibly API’s for advanced scenarios) may provide a boost to Azure usage for companies using Office365 which is a welcome side effect in my book.
When you have installed these prerequisites and scaffold a SPFx project you can start developing. Of course you can use Visual Studio for this, but actually lightweight editors such as VS Code or Sublime should be preferred. Besides the editors you better keep your command line open because that is the way to run and debug the code! Through the defined Gulp tasks in your project you build, run, package and deploy your project through command line options such as build, serve and package-solution.
SPFx development defaults to using TypeScript as the preferred JS dialect. It is probably harder to try and develop a SPFx webpart without TypeScript so this new development model is another big push of TypeScript by Microsoft. You are also encouraged to try to use the Office Fabric UI controls as much as possible. Office Fabric UI is a set of common HTML+CSS controls that you’ll often want to use on Office365. Next to this SASS (‘programmable’ CSS) is something you will want to try and conquer in order to speed up and structure the front-end development.
The included JS frameworks with the Yeoman template are React and KnockOutJS. More will follow.

Framework review

The previous section shows the great amount of new tooling that is required to be a successful SPFx developer. The reliance on open source, common web development tools and frameworks has SharePoint development enter a new chapter in its development history. The introduction of SPFx may beckon a whole new group of developers towards SharePoint, and likewise push the ‘old’ SharePoint developers into the Wild West of structured JavaScript development. It makes possible a more mature and professional way of developing client-side applications on SharePoint. It steers away from the practice of inline scripts on a page, and towards packages that can be successfully maintained and deployed.
Next to this, this new way of development should make it easier for web designers and developers to work together because of the reliance on SASS, the Office Fabric UI and editors like VS Code or Sublime. Prototyping apps is also faster and easier thanks to the SharePoint Workbench, making rapid development and design cycles possible. One possible downside to this is that this model is not very open to the power users/functional developers that are used to using the script editor web part and deployment into the style library. Because of the heavy reliance of SPFx on all the tools and frameworks it might be difficult for these types of people to step into SPFx development. The biggest threat to the success of SPFx (as with the other SP development models) will be that not all SP developers will want to adopt the model and will keep doing their JavaScript development in script editor webparts because it is the easiest path to delivery. This could mean a messy implementation and difficulty in maintaining Office365 solutions.
The user will likely also gain big from the SPFx framework and the new page model. Responsive and mobile accessible pages are a hard requirement nowadays and finally this will also be possible in SharePoint. Because also all of the new pages can be customized, designers and developers will be able to deliver completely unique experiences that are highly user friendly without going against best practices in SaaS/Office365 development. Next to this the new document library pages will also become customizable thanks to SPFx.
SPFx code should be deployed via Content Delivery Networks according to Microsoft because of the decreased loading times and because it facilitates the maintenance of the scripts. Also, the SPFx will allow easy integration with Microsoft Graph API’s and can also be used to talk against custom WebAPI’s that provide functionality that can only be achieved by server side code. For example, running in a different context than that of the current user or safe communication with on premises applications. Because of all this, SPFx may push companies to get Azure subscriptions or make more use of their existing subscriptions by building custom WebApis and integrating them with Office365.

Tips and tricks

When the SharePoint Framework and the new page model has been introduced in SharePoint Online and On-premises and you start a new project it is advised that you still build a development VM. Even though you can use a non-server OS and it uses only lightweight applications it will still be advisable to use a dev VM for each client. In this way you can be sure that it stays stable and that all developers work with the same version of Node, NPM, Gulp, Yeoman, the SPFx yeoman template, etc. It is easy to start developing on your own desktop, but when time progress and you get more projects using SPFx, you will start to be required to upgrade these tools and you may end up with old projects for other clients not working anymore. Besides creating a full fledged (probably Windows) VM, you can also use the popular Docker container software. Waldek Mastycarz has released a Docker image specifically for SPFx development. This is also an easy way to try out SPFx without installing all the prerequisites. Docker is a great way to virtualize an environment, especially when you can use a tried and tested Docker image.
In order to become proficient at using the new tools a developer has quite a steep learning curve ahead of him/her. It is advisable to get at least a working grasp of the node modules used, the gulp tasks, command line options and one or more of the supported JS frameworks like React or KnockOut. An explanation of the node modules included in the SPFx project template should be delivered soon by the MS team that is responsible for it. The Gulp tasks are also included in the project template, so get to know them and perhaps even learn how to add new, custom Gulp tasks yourself in order to speed up the development cycle. The SPFx also provides a great opportunity to get to know TypeScript and build more reliable JS solutions. Lastly, you will need to know what is in the Office Fabric UI pack in order to increase the maintainability of your designs.
In order to make full use local development cycle using the SharePoint WorkBench, it is advisable to include mock data in your SPFx webpart. In this way you can quickly show you app locally before it is on Office365 and iterate faster during development. Using mock data is done as such:
1.      Create models can serve to define the data structure of the data to show
2.      Create a MockHttpClient class
3.      Add GetMockData and GetRealData methods to webpart class
4.      Import environment type
5.      Add RenderDataAsync method that switches between getting mock and real data based on environment type and renders the data
6.      Add call to render data in the main render method (also add html container to provide location for rendering the html)
The following Gulp tasks are included in the Yeoman project template and can be found in the folder /node_modules/@microsoft/sp-build-web/lib/index.js
-        Build
-        Bundle (option –ship)
-        Deploy-azure-storage (uses /config/deploy-azure-storage.json )
-        Package-solution (option –ship uses /config/write-manifests.json )
-        serve
Use option –ship in bundle and package-solution to deploy to CDN.
SharePoint Framework webparts allows a user to fill in properties of the webpart in order to customize the appearance or function of the webpart. A SPFx webpart contains a manifest file to set the most appropriate default values for these properties. An attempt at making the operation of setting a web part property user friendly is to make the properties reactive to user input by default. MS went a little overboard with this, because this means every time you type, the code in the SPFx webpart get executed again. This is not very usable when the variables are used in web service calls, which will often be the case. Because of this you will almost always want to disable the reactive nature of the web part properties. This is done by overriding a property in your SPFx webpart’s code like so:
Set property disableReactivePropertyChanges to true (non reactive properties)
protected get disableReactivePropertyChanges(): boolean {
    return true;
  }
The yeoman project template for SharePoint Framework apps contains a great deal. Below I mention the most used files and their use.
What are the files in the yeoman template for?
·        IHelloWorldWebPartProps.ts (web part properties interface class)
·        HelloWorldWebPart.ts (the webpart itself inclusing render method, property pane code, import statements)
·        HelloWorldWebPart.manifest.json (default value of webpart properties)
·        HelloWorld.module.scss (styling for your webpart)
SharePoint Framework webparts allows the developer to make use of a handy pageContext variable that contains some useful properties shown below.
WebPart.context.pageContext variable
-        SPSite guid
-        SPWeb guid, absolute url, relative url, title, permissions
-        SPUser: email, displayname, loginname
Currently the actual properties of the (publishing) page do not seem to be included in this variable. It would be very useful for the developers when the current page’s properties could be easily read so they can be used in the code in order to make each page unique. For example, showing the date of publication, categories/tags of the page, related articles/people, etc.
Something to keep in mind when starting development is that the tools like Gulp and NPM are not very fond of a deep folder structure. So make sure you start your projects very close to the root folder.
When you want to try out SPFx right now, and this might occur after introduction as well if it is updated, make sure you’re using the most recent version of NPM, Yeoman and the Yeoman project template. Breaking changes may have been introduced in a newer version. MS promises that after SPFx goes GA they will not introduce breaking changes anymore. An example of an error you might get is the following. Instructions for updating your tooling follows.
Error:
Error loading debug manifest script. (Error: http://localhost:4321/temp/manifests.js did not call System.register or AMD define. If loading a global module configure the global name via the meta exports property for script injection support. Error loading https://localhost:4321/temp/manifest.js) Ensure loading unsafe scripts is allowed.
Update tooling:
npm update yo –g (update yeoman)
npm update -g @microsoft/generator-sharepoint (update yeoman sharepoint framework app generator)
yo @microsoft/sharepoint (new project)
gulp serve (run template project)
In chrome you’ll get security warnings. Go to advanced -> progress to site. SharePoint workbench inside Office365 will work again as well.

Conclusion


Hopefully this document has shown what a useful development paradigm the SharePoint Framework might become. Everything stands or falls with community adoption. However, SPFx might actually lead to new communities evolving around customization of Office365/SP2016. It may also provide new opportunities for old-school SharePoint developers if they adopt the platform. It will be exciting to see the range of solutions that will be developed using this new development model!

Azure Functions

Introductie

Dit document beschrijft Azure Functions’ zijn mogelijkheden en onmogelijkheden en mogelijke toepassingen. Azure Functions is geïntroduceerd op Build 2016. Het is een toevoeging op de Azure stack die voortborduurt op de mogelijkheden van Azure WebJobs, de onderliggende WebJobs SDK is ook de basis voor Azure Functions. Azure Functions maakt het mogelijk om kleine stukjes code aan te roepen of op een schema te laten draaien om een specifieke functie in je applicatie/architectuur mee te bewerkstelligen. Net als de WebJobs draait het op de App Services infrastructuur en daarmee is een Azure Function meteen zeer schaalbaar, en betaal je alleen voor de tijd dat de code daadwerkelijk draait. 

Features

Een Azure Function wordt gestart door middel van een handmatige actie, een (tijd)schema dat ingesteld kan worden of door middel van een trigger. Een trigger is een gebeurtenis waarbij een extern systeem de Function aanroept door middel van een bericht naar het http end point van de Azure Function. Zo kan er ook informatie van buitenaf de Function bereiken, en kan het een geïntegreerd mini subsyteem (microservice) worden van de applicatie. De Function kan ook output retourneren. Het http eindpunt kan door elke applicatie die http kan praten gebruikt worden maar er is ook een handige set van trigger en connectors die het mogelijk maakt met andere systemen te integreren dat voor een gedeelte is in te regelen via de grafische interface van Azure Functions. De set van triggers en connectoren zal verder uitgebreid worden maar bevat op dit moment in ieder geval de Azure storage oplossingen zoals Tables, Queues en Blob storage. Het is bijvoorbeeld mogelijk om een image file die aan de blob storage wordt toegevoegd te behandelen en bijvoorbeeld een watermerk toe te voegen door het uitvoeren van de Function. Naast de set van trigger en connectoren bestaan er in de grafische interface ook templates waarmee je de Function ontwikkeling kunt kickstarten. Zo kun je snel een Function maken die een Azure Queue uitleest bijvoorbeeld.
Zoals gezegd is er een web-interface voor het creëren van Azure Functions, of eigenlijk meerdere. Via de nieuwe Azure portal en een specifieke portal voor Azure Functions, maar ook via Visual Studio Online ‘Monaco’. In de laatst genoemde web interface is er ook al Intelli-sense voorhanden wat het ontwikkelen flink vergemakkelijkt. Natuurlijk is ontwikkeling in Visual Studio ook mogelijk, al zijn de gebruikelijke set aan tools daarin nog niet  voorhanden op dit moment mbt Azure Functions. Azure Functions ondersteunt ook Continuous integration (CI) vanuit Git of Visual Studio Online zodat deployments professioneel kunnen worden opgepakt. Wanneer CI wordt ingeschakeld is editing in de Web interface niet meer mogelijk zodat de developer altijd weet welke code er daadwerkelijk op de (productie) omgeving gedraaid wordt.
Zoals veel ontwikkelingen binnen Microsoft de laatste jaren is de SDK volledig open source. Hiernaast is de runtime portable zodat deze ook binnen andere Cloud providers of zelfs on premises jouw Azure Functions kan draaien. Door deze twee eigenschappen van Azure Functions betekent dit dat een bedrijf niet opgesloten wordt in het Azure ecosysteem van Microsoft en dat de buy-in klein is. Een bedrijf kan altijd beslissen de Azure Functions op een andere plek onder te gaan brengen.
Een andere belangrijke nieuwe ontwikkeling die Azure Functions met zich mee heeft gebracht is het dynamic hosting plan voor App services. Dit houdt in dat de Azure Function infrastructuur daadwerkelijk volledig uit wordt gezet wanneer hij niet wordt aangeroepen, en dan zijn er dus totaal geen kosten. Er wordt aangegeven dat het ‘cold start’ probleem wat dit met zich meebrengt van kleine omvang is, binnen één seconde zou het eerste request bij een Azure Function binnen moeten komen. Na ongeveer 5 minuten idle-time wordt een Azure Function uitgeschakeld. Microsoft geeft aan dat de maximale loop tijd van een Azure Function geen harde limiet zal krijgen, er zullen alleen mechanismen in werking komen om de Function te stoppen wanneer het erop lijkt dat de Function (bijvoorbeeld) in een oneindige lus is gekomen. De Azure Functions kunnen ook op de ‘classic’ hosting plans van App Services gedraaid worden. In ieder geval profiteren de Azure Functions altijd mee van de mogelijkheden van App Services zoals de mogelijkheden om makkelijk authenticatie op basis van bijv. Azure AD in te bouwen.
Azure Functions zal een groot aantal van de gangbare programmeertalen ondersteunen is de planning. Dit zullen zijn: Node.JS, C#, F#, PHP, Python, Java. Hiernaast zullen Bash, Batch en executables ondersteund gaan worden.

Toepassingen

Azure Functions kunnen binnen een meer omvangrijke architectuur als micro services gebruikt worden. Wanneer er een klein losstaand stukje code is dat niet past in een grotere Web API of website dan kan dat als Azure Function zijn plek krijgen. Om bepaalde klein-schalig integraties tussen SaaS services op te zetten kan een Azure Function ook zeer nuttig zijn. Het kan ook een custom onderdeel worden van een Logic App, waarmee een werkproces kan worden ingericht. Het is daarnaast een laagdrempelige manier om een executable in de cloud te gaan draaien, waar WebJobs ook al geschikit voor waren.
Ook Office365 integratie is een mogelijkheid, de Azure Function kan inhaken op een gebeurtenis in Office365 of kan operaties aan de hand van een schema uitvoeren op Office365.

Discussie


Azure Functions lijkt een zeer nuttige toevoeging aan de Azure stack. Vooral in combinatie met Logic Apps kan het een laag drempelige manier worden om processen te automatiseren in de cloud. De vraag kan echter gesteld worden hoe de (vele) Functions die gaan ontstaan beheersbaar blijven binnen een applicatie landschap. Voor alles behalve triviale gevallen zal er goed nagedacht moeten worden over de architectuur en of een Azure Function een toekomst vaste oplossing is voor een (sub)probleem. Met Azure Functions heeft Azure er weer een krachtig platform bij en gaat het de competitie met Amazon Web Services heads-on aan.

Microsoft Bot Framework

Introductie

Dit document beschrijft het Microsoft Bot Framework en werkt een zakelijk scenario uit waarvoor Bots gebruikt zouden kunnen worden.



Het Microsoft Bot Framework is een set ontwikkelcomponenten waarmee je gebruikers in staat stelt om informatie in te dienen bij een back end. De client applicaties waarmee de gebruiker dit kan doen zijn zeer divers en zijn meestal al in gebruik door de eindgebruikers. Voorbeelden zijn Skype, SMS, Slack, Office 365 Mail, etc. De Bot en de gebruiker hebben een conversatie en bij afronding hiervan wordt de uiteindelijke informatie ingediend bij een back-end, vergelijkbaar met het invullen van een web-formulier. Het idee is dat een conversatie met een bot via een al bekend kanaal zeer gebruikersvriendelijk is. Daarnaast wordt voornamelijk al beproefde infrastructuur van de kanaal-aanbieders gebruikt voor de communicatie, naast de Bot die op het zeer schaalbare Azure App Services platform kan worden neergezet. Hierdoor kan met minimale ontwikkel inspanning een gebruikersvriendelijk en schaalbaar systeem worden gebouwd om gegevens in te dienen bij een back-end. Dit kan betekenen dat de gebruiker een pizza kan bestellen, een support request kan indienen of welk verzoek om een dienst dan ook.
De onderdelen van het Bot framework zijn de Bot Connector, de SDKs waarmee je de Bot kunt bouwen en de Bot Directory. Met de Bot Connector kun je gebruikers via verschillende kanalen toegang geven tot je Bot. De Bot zelf bouw je met de SDKs als ASP.Net web applicatie of Node.JS applicatie. Er is ook een Bot Framework Emulator waarmee je de bot kunt testen en Visual Studio templates om snel een bot te kunnen ontwikkelen. De Bot directory wordt een online store waarop je je bots kunt publishen zodat ze door het publiek te vinden en te gebruiken zijn.

Een typische (happy flow) van de gebruiker-bot interactie gaat als volgt:

1.      Eindgebruiker vindt of verkrijgt het Bot id voor een kanaal (skype contact, telefoonnummer voor SMS, Office 365 email adres, etc)
2.      De eindgebruiker spreekt de Bot aan via het kanaal.
3.      De eindgebruiker en de bot hebben een conversatie
4.      De Bot registreert (de uitkomst van) de conversatie in de back-end
5.      Er is terugkoppeling naar de eindgebruiker over het resultaat.
6.      Dienst wordt geleverd aan eindgebruiker (e.g. pizza wordt bezorgd, service request wordt afgehandeld).

Een goede kandidaat voor een back-end systeem kan in bepaalde gevallen een Logic App zijn. Deze workflow kan dan berichten plaatsen in verschillende on-premises of cloud systemen, mensen informeren over de aanvraag en terugkoppeling geven aan de Bot. In simpele gevallen kan een enkele API het Bot bericht afhandelen.

De ontwikkelmogelijkheden binnen de Bot SDK (open source) zijn talrijk. Er is een soort code-wizard om snel een bot te bouwen met de FormFlow klassen. Aan de hand van een definitie van een klasse met publieke eigenschappen en attributen daarop bouwt de SDK zelf de dialogen op die de bot kan doen. Simpele bots kunnen hiermee in een mum van tijd worden gebouwd. Het dialogen framework binnen de SDK, daarentegen, geeft de ontwikkelaar de volledige vrijheid voor het opbouwen van conversaties die een gebruiker kan hebben met een Bot. Een krachtig type dialoog is de Language Understanding Intelligence Service (LUIS) dialog. Hiermee kun je je bot uitrusten met geavanceerde natuurlijke taal herkenning functionaliteiten, door middel van het opzetten van een (getraind) LUIS model. Zo kan je gebruiker in natuurlijke taal met de Bot praten en kan de Bot acties ondernemen op de doelstellingen van de gebruiker die hij registreert..




Scenario

Dit gedeelte beschrijft een mogelijke toepassing waarbij het Bot framework kan worden ingezet. Het scenario is het indienen van declaraties bij de werkgever.
Nadat de kanalen bekend zijn gemaakt bij de eindgebruiker, kiest deze er een en begint de conversatie met de Bot met als doel een declaratie in te dienen. Dit zou via een skype gesprek kunnen, of andere chat clients. In dit voorbeeld zijn screenshots genomen van de Bot Framework Emulator. Een andere chat client heeft natuurlijk een andere GUI maar het algemene principe van een gesprek zal hetzelfde zijn.

Bot scenario



Figuur 1: Initiatie van de conversatie

Figuur 2: Vervolg conversatie

Figuur 3: Samenvatting conversatie door Bot voor de verzending naar Back-end

Figuur 4: Terugkoppeling resultaat
Deze voorbeeldconversatie is gemaakt met een daadwerkelijke implementatie van een Microsoft Bot Framework Bot. Om het voorbeeld duidelijk en bondig te houden zijn er enkele simplificaties toegepast, zoals: Er kan maar 1 declaratie per conversatie worden ingediend, alle antwoorden zijn van type string inclusief de link naar de scan van de factuur (ipv mogelijkheid tot uploaden bestand).

Figuur 5: Standaard options van FormFlow Bot
De demo-Bot is gebouwd met de FormFlow sdk, wat een makkelijke manier is om een simpele Bot te maken voornamelijk via configuratie (in code). Dit heeft als voordeel dat de dialogen automatisch worden gemaakt en er ook een aantal standaard opdrachten aan de Bot worden toegevoegd zoals Help, Reset en Quit.




Discussie

Het Microsoft Bot Framework maakt het makkelijk om je gebruikers een alternatieve manier van interactie aan te bieden via bestaande applicaties, wat, bij een goed design, in veel gevallen een zeer gebruikersvriendelijke ervaring oplevert. Het feit dat je Bot binnen het App Services platform wordt opgeleverd maakt deze direct zeer schaalbaar, onderhoudbaar en uitbreidbaar. Overigens is een Bot een MVC WebApp of Node.JS API en kan dus overal gehost worden. De combinatie met de natuurlijke taal services in LUIS en andere machine learning services in Azure maakt dat de Bots die ontwikkeld worden met het framework zeer intuitief kunnen werken en er met groot gebruikersgemak functionaliteiten kunnen worden aangeroepen. Daarnaast zijn Logic Apps een mooie kandidaat als back-end voor de Bots, zodat deze allerlei acties, logging en terugkoppeling makkelijk configureerbaar en beheersbaar maken.
Het aantal beschikbare kanalen is al zeer groot en zal nog groter worden, WhatsApp zou op termijn een goede toevoeging zijn maar die infrastructuur is nog niet klaar voor directe koppeling met Framework Bots.
Uitdagingen die ik nog zie met het Framework hebben te maken met authenticatie en autorisatie. Hoe gaat het worden ingeregeld dat de identiteit van een gebruiker over kanalen heen kan worden vastgesteld. Dit, zodat er één profiel van een gebruiker kan worden opgebouwd bijvoorbeeld om daarna interacties met de Bot mee te versnellen. Dit zou een nog verdere verbetering van de gebruikerservaring betekenen.
Echter is authorisatie voor het gebruik van de Bot voor een gebruiker of groep gebruikers sowieso iets waarvoor richtlijnen en best practices nog moeten worden bepaald. Wanneer een kanaal is opengesteld kan in principe iedereen via dat kanaal de bot aanspreken, en daarmee de back-end services. Op dit moment is dit alleen te voorkomen door verdere authenticatie en authorisatie in te bouwen in de Bot. Dit vermindert de gebruikersvriendelijkheid van de bot en maakt de development van een Bot complexer en architectonisch minder losgekoppeld.

Dit maakt dat het Bot framework op dit moment alleen geschikt is voor publieke toepassingen, voor zakelijke toepassingen binnen een organisatie zullen er nog goede autorisatie oplossingen moeten worden bedacht.

Nintex versus Azure App Service

Introductie

Dit document beschrijft vier platforms/producten die rondom Office365 van belang zijn of gaan worden: Nintex Workflow, Nintex Forms, Azure Logic Apps en PowerApps. Het doel van dit document is een korte inleiding te geven van elk platform en daarna de Nintex oplossingen te vergelijken met de nieuwe Azure Apps vooral in relatie tot Office365/SharePoint Online ontwikkeling. De vergelijking gebeurt op basis van software kwaliteiten zoals functionaliteit, gebruikerservaring, onderhoudbaarheid, schaalbaarheid, etc. De vergelijking is opgesteld op basis van (in het geval van Logic -en PowerApps beperkte) ervaring met -en documentatie van de betrokken platformen.
Dit document begint met een introductie van elk platform, hierna volgt een vergelijking en een discussie.

Nintex Workflow

Nintex is een onafhankelijk bedrijf en belangrijk partner van Microsoft. Het bedrijf is gestart in 2006 met een workflow product voor SharePoint Server 2007. Het is nu de populairste 3rd party tool voor SharePoint (Online en On premises) volgens Forrester. Nintex Workflow is een Cloud workflow automatiserings-engine dat gericht is op het verbeteren van kantoorproductiviteit. De Cloud oplossing is geëvolueerd vanuit de workflow producten op SharePoint 2007, 2010 en 2013. Nintex Workflow is gericht op de zakelijke gebruiker, maar wordt in de praktijk toch vooral ingericht door functionele consultants of power users. Nintex gebruikt het SharePoint Add-on model, dit betekent dat de code extern aan SharePoint Online (SPO) draait maar wel geïntegreerd is in SPO. Via remote event receivers haken de werkstromen in op gebeurtenissen in SPO zoals item creatie. Een Nintex Workflow draait in de context van de huidige gebruiker of met verhoogde rechten. De designer voor Nintex Workflow heeft een gebruikersvriendelijke drag-and-drop interface. Het is tevens goed inzichtelijk te maken wat de status is van werkstromen en hoe het werkstroomproces is verlopen. Nintex heeft een store opgericht waar additionele operaties voor Nintex workflow in staan. Hiermee kunnen externe Cloud services worden aangeroepen vanuit een werkstroom. Salesforce, Twitter, Facebook, Dynamics CRM en meer zijn ondersteund. Enkele voorbeelden van processen die worden ingericht met Nintex Workflow zijn: Vakantie aanvragen, onboarding, goedkeuring van declaraties, helpdesk aanvragen en site management.

Nintex Forms

Nintex Forms is opgezet in 2010 door Nintex om creatie van formulieren m.b.t. SharePoint lijsten gebruikersvriendelijk te maken voor zakelijke gebruikers. Het product kan gebruikt worden om het aanmaken en wijzigen van lijst items te vergemakkelijken en uit te breiden qua functionaliteit. Het biedt bijvoorbeeld de mogelijkheid om regels en validatie toe te voegen aan een formulier, en een volledig aangepaste opmaak te geven. Tevens kunnen formulieren worden toegevoegd aan workflows zodat deze de, door een gebruiker aangeleverde, informatie kunnen verwerken en verspreiden naar de juiste personen (bijv. ter goedkeuring aanbieden). Nintex Forms kunnen extern toegankelijk worden gemaakt en ook worden aangeboden in een mobiele applicatie voor de drie grote mobielen platformen (iOS, Android, Windows). Forms is net als Nintex Workflow een betaalde Add-on voor SPO.

Logic Apps

Logic Apps is een in 2015 geïntroduceerde toevoeging aan Azure App Services, dat op dit moment nog in preview fase is. Een Logic App draait binnen de Azure Apps infrastructuur mee op je Azure bronnen, en kost niets meer dan het verbruik van die bronnen. Het biedt een workflow engine dat draait in Azure en dat kan integreren met allerlei Cloud services binnen Azure, in Office365 en met andere ondersteunde Cloud providers. De integratie gebeurt met de beschikbare connectoren (bijv. Salesforce, Office365, Twilio, Twitter, Facebook, etc) of simpelweg via het http protocol. Ook kan worden geïntegreerd met On premises software (hiervoor zijn ook connectoren beschikbaar) of met zelfontwikkelde web services. Een Logic App bestaat uit triggers en acties, echter is een trigger niet direct maar wordt deze door regelmatig polling van het andere systeem bewerkstelligd. Een Logic App is daarmee een scheduled workflow. Een mogelijke trigger is ook simpelweg een timer, waardoor de Logic App autonoom kan opstarten. Een belangrijke feature van Logic Apps zijn de aanroepbare eindpunten. Hiermee kan een extern systeem een Logic App starten en input meegeven. Hierdoor wordt het toch mogelijk een Logic App direct te laten uitvoeren vanuit een proces in het bronsysteem. Ook kan de ene Logic App een andere starten en invoer meegeven. De aanroepbare eindpunten kunnen ook gebruikt worden in een WebHook, dat is een actie in het midden van de workflow die wacht op een post van een ander systeem. ZO kan nog geavanceerdere interactie met andere services worden gebouwd.
Hiernaast is er een management API beschikbaar voor Logic Apps die het mogelijk maakt Logic Apps aan te maken, te starten of te verwijderen. Dit maakt de Logic Apps zeer programmeerbaar. Een Logic App verbindt met een ander systeem onder een service account. Je kunt een Logic App op verschillende manieren beveiligen, hij kan volledig publiek zijn, publiek met authenticatie (ik neem aan Azure AD) en intern.
Er is een visuele designer beschikbaar in Azure waarmee gemakkelijk de triggers en acties kunnen worden toegevoegd aan een werkstroom. Er is tevens naar een code view te schakelen, aangezien de Logic Apps worden opgesteld in JavaScript Object Notation (JSON). Dit maakt mogelijk dat de Logic Apps opgeslagen kunnen worden in een broncode systeem zoals Visual Studio Online, en ook bewerkt kunnen worden in de favoriete editor van de ontwikkelaar. Logic Apps zijn niet bedoeld om door zakelijke gebruikers te worden opgesteld maar door ontwikkelaars en integratie specialisten. Wanneer een Logic App operaties doet op bijv. SPO dan is dit ook niet direct zichtbaar, de App is niet geïntegreerd in de Office365 ervaring zoals een Nintex Workflow. Er zijn management functies voorhanden binnen Azure waarmee inzicht kan worden verkregen in het verloop en fouten binnen een workflow.

PowerApps

PowerApps is een web en desktop applicatie waarmee PowerApps gemaakt kunnen worden. Dit zijn cross-platform mobiele (en web) applicaties die Cloud services consumeren. Het wordt de zakelijke gebruiker gemakkelijk gemaakt om te verbinden met Cloud services en zo bijvoorbeeld een mobiele applicatie te maken om een declaratie in een SPO lijst te zetten. Ook is het mogelijk met On premises service te verbinden, al zal dit waarschijnlijk nog wat werk van een IT afdeling vragen. De PowerApps applicatie kan gemakkelijk verspreid worden, er is geen App store tussenkomst voor nodig. Een mobiele PowerApp draait op de telefoon binnen een native app. Het PowerApps platform richt zich op de zakelijke gebruiker / power user en wil ze in staat stellen om gemakkelijk specifieke mobiele applicaties te maken voor een proces binnen de onderneming. Ook dit platform is op dit moment in Preview fase.

Vergelijking Nintex & Azure App Services

Onderstaand een vergelijking op verschillende kwaliteiten tussen Nintex en Azure Apps. De mogelijkheden van Azure Apps die in de Preview in maart 2016 beschikbaar waren worden genoemd.




Kwaliteit
Onderwerp
Nintex
Azure Apps
Functionaliteit




Logic flow
Uitgebreide mogelijkheden: While loops, if statements, state machines
Weinig mogelijkheden: alleen if statements

Triggers
Handmatig, item creatie, item modificatie, geen scheduling van workflows
Handmatig, Timer, Aanroepbaar eindpunt, Polling van externe service, WebHooks

Operaties
Uitgebreide mogelijkheden: nieuw item aanmaken, item bijwerken, goedkeuringstaak starten, email versturen, Cloud service aanroepen, datum operaties, string operaties, mathematische operaties
Binnen SharePoint: Create item, create file, lijst items ophalen. Geen item bijwerken, geen goedkeuring flows, geen site provisioning. Wel string operaties, mathematische operaties en operaties op collecties. Verscheidenheid aan operaties op andere Cloud services voorhanden.

Management
Management in SPO, inzichtelijk wat de lopende werkstromen zijn en de status ervan, fouten etc.
Management in Azure, inzichtelijk wat de resultaten van de operaties zijn en wanneer de workflow gelopen heeft. Logic Management API maakt 3rd party management software waarschijnlijk.

Security
Draait in context van huidige gebruiker of App.
Opereert d.m.v. service accounts. De Logic App kan publiek, publiek + auth of intern worden ingesteld.

Programmeerbaarheid
Geen
Logic Management API maakt aanroep, creatie, wijziging van Logic Apps mogelijk. Broncode in JSON maakt source editing en control mogelijk.

Use cases
HR processen, Financieel administratieve processen, IT support processen voornamelijk binnen SPO
Integratie processen tussen on premises en Cloud, platform overstijgende processen.
Gebruikerservaring




Visual designer
Drag and drop, help functionaliteit, import + export workflows, workflow snippets opslaan.
Code en design view, Cloud service bouw blokken

Integratie met SPO GUI
Geïnstalleerd in SPO site. Nintex acties in de ribbon beschikbaar, geïntegreerd in lijsten.
Geen.

Mogelijkheden maatwerk (Forms/PowerApps)
Maatwerk input formulieren, workflow formulieren, offline formulieren in mobile App mogelijk
Focus op native mobile applicatie, creatie door gebruiker, gemakkelijk deelbaar binnen organisatie.

Debugging
Status zichtbaar. Het is inzichtelijk te maken waar de werkstroom is gestopt. Logging naar werkstroom geschiedenis.
Resultaten van de acties zijn zichtbaar. Niet inzichtelijk wanneer Logic App niet (goed) wordt getriggerd.

Doelgroep
Business user, power user, developer, consultants
Logic Apps: Developers, Integration specialists.
PowerApps: business users.
Onderhoudbaarheid




Management API
Nee
Ja

Source control
Nee
Ja

Governance
Alles op 1 plek. Goed in te regelen binnen SPO met rechtenstructuur. Nintex Forms Apps kunnen gepushed worden naar mobiele apparaten met MDM.
Verspreid tussen SPO en Azure. Logic Apps: Deployment door Azure beheerders. PowerApps: creatie en verspreiding door gewone gebruikers.

Ondersteuning
Ondersteunings overeenkomst mogelijk. Redelijke community beschikbaar.
Nog in preview dus geen support, veel aanleg voor sterke community
Uitbreidbaarheid




Connectoren
Beschikbaar in Store. Waarschijnlijk minder aantrekkelijk voor 3rd parties om Nintex connectoren te maken dan voor Logic Apps.
On premises en Cloud service connectoren beschikbaar in Azure. Eigen web services in Azure kunnen ook aangesloten worden.
Kosten




Prijs
Per user/per workflow
Logic Apps: per Azure bron-minuten. PowerApps: per gebruiker.
Diversen




Schaalbaarheid
Niet handmatig schaalbaar, draait in Nintex Cloud
Zeer schaalbaar, tegen een prijs.

Robuustheid / Volwassenheid
Goed, draait al jaren voor veel klanten
In preview fase
              

Discussie

Nintex is een uitstekende tool voornamelijk voor relatief simpele zakelijke processen, die vanwege zijn origine als SharePoint Add-on en hechte koppeling met de SPO interface absoluut niet snel op zijn vlak zal worden ingehaald door Logic Apps. Het is simpelweg te gemakkelijk om binnen Nintex zakelijke processen op te zetten om gegevens op te slaan en te wijzigen en om goedkeuringsprocessen mee in te regelen. Voor processen die binnen SPO beginnen zal Nintex nog een lange tijd een waardevolle tool zijn. Logic Apps zal vanwege het gebrek aan zichtbaarheid binnen SPO, en ondersteuning voor standaard operaties vanuit/in SPO hiervoor (nog) niet geschikt zijn. Mogelijk dat ze meer gaan concurreren wanneer er SPO Add-ins worden ontwikkeld die Logic Apps meer functionaliteit geven binnen SPO.
Voor SharePoint overstijgende processen, zoals werkstromen binnen Office365 tussen Exchange Online en SPO, of tussen verschillende Cloud service providers, kunnen Logic Apps een uitstekende oplossing worden. Ook met betrekking tot de ontsluiting van On premises oplossingen (of maatwerk API’s in Azure) naar Azure services toont het platform veel potentie. Het nut van Logic Apps neemt sterk toe naarmate de onderneming een aanwezigheid heeft met systemen binnen Azure of in andere Cloud services.
Het interesseert me enorm wat er mogelijk gaat blijken met de features van aanroepbare eindpunten en de management API. Al met al zal het succes van Logic Apps afhankelijk zijn van de stabiliteit en volwassenheid en de daarmee gepaard gaande populariteit van het platform. De benodigde functionaliteit en best practices zullen dan snel volgen.
Wat betreft PowerApps is het mij minder duidelijk of dit succes zal hebben. Het zal afhangen van de ervaring die gebruikers van de Apps hebben om simpele Cloud operaties mee te doen. Het moet blijken of het in handen geven van App creatie en verspreiding aan zakelijke gebruikers een goed idee is. Het is in ieder geval goed dat Microsoft een poging doet om ontsluiting van Office365/SPO cross-platform, en op mobiel, bereikbaar te maken.

Dat zowel Logic Apps als PowerApps nog een lange weg te gaan hebben is duidelijk, op beide platforms werkten de standaard operaties nog niet eens ten tijde van dit schrijven. Echter is de potentie zo groot dat beide platformen goed in de gaten moeten worden gehouden en moeten wij als Motion10 de (on)mogelijkheden scherp in de gaten blijven houden.