| Basel Building real Business Apps with Office365/Azure Gilbert Nicolet – BPA Solutions SA

Agenda BPA Solutions Initial situation Technical considerations Choosen architecture Result Points of interest

| Basel BPA Solutions Chapter 1/6

Building real Business Apps with Office365/Azure Founded in 2001, 20+ SharePoint Experts Business Solutions for SharePoint  BPA CRM  BPA Quality  BPA Risk  BPA Recruiting Offices in CH (HQ) and US 800+ Customers WW 50+ Partners WW 10+ Languages

| Basel Initial situation Chapter 2/6

Building real Business Apps with Office365/Azure Situation end 2011 We had an existing large applications set  Running fine onPremise  Using only SSOM inside c# code (Server Side Object Model) (SPList, SPLIstItem…)  Working with dynamic lists, fields, screens !  BPA Applications are NOT on 365  They can NOT run on 365 AS IS (c#/SSOM) We are not large enough to develop/maintain two different solutions onPremise/onLine

On Premise Screens Dynamic screens with a lot of information quickly available

On Premise Screens Links between webparts and a lot of functions

On Premise Screens Dynamic Popups with Tabs

On Premise Screens Complex functions (incl. e.g. Send )

On premise Screens And a deep query engine

Building real Business Apps with Office365/Azure Goal end 2011 Define/choose the technologies/architecture to provide an application  With (quite) the same features onLine and onPremise  Using the most efficient technologies (speed, capabilities)  Running in the Microsoft 365 Cloud and onPremise with as less differences as possible in the coding  At a competitive price Profits  We were part of the PAB and Office 15 SDR programs, so, we included the future SP15 possibilities in our analysis  We achieved this development with an great help from Microsoft Redmond (Two trips and weekly calls)

| Basel Technical considerations Chapter 3/6

Building real Business Apps with Office365/Azure Summary of a Microsoft SP 15 ‘apps’ solution : To run onLine, we decided to create Apps An App contains  A) html, js, css, site templates, list templates, masterpages, aspx and client webparts without c# run on/from SP servers and on users’ devices  B) aspx with c# run on Azure servers  C) configurations files An App can be deployed «automatically» to  Office365 (A elements)  Azure (B elements) with automatic cross authentication (SP Token) “Client Webparts” must run without c# (only js allowed) but the javascripts can call Azure applications from the client (or use CSOM to get SP data directly) Dynamic ribbon from miscallenaous webparts not possible

Building real Business Apps with Office365/Azure Azure programs are able to Call current SP site with «current SP user» authentication and privileges (CSOM) Call external servers, e.g. SMTP servers Access server’s local data, like Files Run «batch» jobs (batches or repetitive processes) Colocation is available SP webparts and Azure c# part running in the same location

Building real Business Apps with Office365/Azure The way to onLine To port our applications to SP 365, we could pass to  SP+JS (Client webparts with JS)  SP+Azure(C#) Elements to take decision  Response time  CSOM has constraints to obtain good response time.  CSOM Call between servers consumes a bit of time  Executing CSOM requests from laptops won’t help !  All application’s JS on laptop would deliver our sources to clients and competitors  We want to offer quite all our products onPremise AND onLine with one documentation, one training, one development, one maintenance  No dynamic ribbon from multiple webparts

Building real Business Apps with Office365/Azure We imagined some solutions what we discarded. The two last discarded were Most of the code in JS - Security/privacy problems - Speed (many data transfer laptop-server) - JS portability / browser compatibility Port our C# code to Azure and transfer our data to SqlServer + Would be faster than SP at running time - Large parts of the application to redevelop - We would loose all OOB SP feature that our clients love

| Basel Chosen architecture Chapter 4/6

Building real Business Apps with Office365/Azure We kept two architectures Online  C# code on Azure  Data inside SP  Data handling with CSOM  Buttons inside the pages instead of ribbon OnPremise  C# code inside webparts  Data inside SP  Data handling with SSOM  Ribbon Both #if used Problem : CSOM/SSOM

Building real Business Apps with Office365/Azure Webpart onLine global rendering 1- Page+webpart IFrames 2- Light IFrame content 3- WP Request 4- gets data(c#/csom) 5- data back 6- builds html/js part 7- html/js back 8- html/js displayed/used Sharepoint 365 site Azure application Webpart in browser IFrame

| Basel Result Chapter 5/6

Online Screens

| Basel Points of interest Chapter 6/6

Building real Business Apps with Office365/Azure Some technical solutions could be interesting Data accesses Webpart/pages personalization Ribbon Single solution onLine/onPermise

Building real Business Apps with Office365/Azure Data accesses Remember : we use dynamic lists, fields, screens The screens, lists and fields are not “known” by our components. We must read the SP structure. So: We developed a “Data kernel” which :  Handles SP data via CSOM or SSOM  Caches some structure information (lists, fields, views…) in memory and/or serialized filed  Caching system is not 100% the same onLine and onPremise We changed some algorithms to avoid CSOM speed problems  Reduce the number of clientcontext.executequery  Fetch only the necessary data (e.g. only the necessary fields) Remaining problems  Speed  Cache

Building real Business Apps with Office365/Azure Webparts properties Users must be able to add pages and customize them with our application Our webparts have complex properties So:  We store our webparts properties in list  We developed a webpart properties editor  The effective webpart property is just a set of IDs

Building real Business Apps with Office365/Azure Ribbon  On premise, we generate in one single ribbon tab all commands to all webparts displayed on the page  FluentRibbon used in SP2010 onPremise and SP2013 onPremise  We did not find a solution for dynamic ribbon onLine So: We generate ribbon buttons onPremise and normal buttons onLine

Building real Business Apps with Office365/Azure Single solution onLine/onPremise OnPremise webparts are c# with SSOM accesses OnLine webparts are Javascript calling Azure using c# with CSOM accesses So: Our webparts are  Close to empty  Not the same onPremise and onLine  But they at 98% call the same c# code  On the SP Server for onPremise  On Azure server for onLine Functionalities are close to the same Thanks to DataKernel !

Summary  Single solution possible at 90%  SSOM/CSOM or only CSOM  Dynamic Ribbon versus buttons  Performances -> Algorithm  Pages customization by end user For more information