Gold Silver Bronze. In this presentation: Smorgasbord Compulsory Sharepoint Solution Development...

Gold Silver Bronze

In this presentation: Smorgasbord Compulsory Sharepoint Solution Development then and now The Cloud App Model overview Options Whats Up demo Lessons learned Questions Options The App Store and whats on it and is it working? The App Store and whats on it and is it working? Registering with the Microsoft Seller Dashboard Setting up a development environment for the App Store Setting up a development environment for the App Store Building a Provider Host (in Azure) App Security and the Azure Access Control Service (ACS), Client Ids and Secrets App Security and the Azure Access Control Service (ACS), Client Ids and Secrets Credential Caching Application Data Caching Creating a simple provider hosted app The AppManifest.xml file Publishing to Azure Globalization Pricing and Licensing Submitting to the App Store

Quick potted history of SharePoint Development Your options for SharePoint development today Quick comparison of SharePoint Hosted Apps vs Provider Hosted Apps The Kaboodle Software App Store Strategy A look at the SharePoint App Store and whats on it Getting started Registering on the Seller Dashboard Preparing your development environment Build something Using Azure as provider hosted app web site Security essentials Caching Access Tokens Application Data Using an Azure SQL Server Database as a cache Kaboodle Case Study: Whats Up What Tiler overview Licensing options Licensing framework

SharePoint Development then and now Potted history of SharePoint Development Options for development today

SP 2001-2003: Application development was certainly possible but very difficult, server object model some web services SP 2007: Farm only solutions, security via Access Control Policy which no one ever used so everything was full trust, development made much easier with WSP Builder and later VSeWSS 1.3 but still Server OM, enhanced web service API SP 2010: Proper VS integration, new client APIs (CSOM/JSOM, Silverlight & REST) in addition to Server OM, Sandboxed solutions limited support for O365/SPO SP2013: Silverlight and Sandboxed solutions supported but deprecated, O365/SPO seen as future primary delivery channels, client APIs significantly enhanced, new Cloud App Model promoted as they future but with full trust Server OM still supported SP2016: Ignite?

6 Full Trust Farm Solutions: Still supported but not in O365 or the App Store Sandbox Solutions: Still supported and can still be used on O365 (for now but deprecated) no App Store support this is a dead end Cloud App Model : The future (so we are told), supported both in O365 and On Premise and the only option for the App Store. Used to be 3 options (now only 2): SharePoint Hosted Provider Hosted Auto Hosted (was only ever a trial concept and one which was dropped in June 2014)

8 SharePoint Hosted Run in context of your SharePoint farm so no extra server required SharePoint provisions a special App Web just to run your code! Authentication is simpler as the context can be established from the App Web Your App does not necessarily have access to the host web site As its running on the Sharepoint farm and client browser only then performance should be better You can only run REST/JSOM API Thats right its a JavaScript only development experience! No data is stored outside your SharePoint deployment so better security - discuss? (not convinced) Provider Hosted Run on a separate server which you must provide and pay for You can however use an Azure VM or better still an Azure Web Site and these start out free With 3 locations to deal with (SharePoint, Client and App Provider Server) performance might be sluggish However, if you use Azure you can scale and geo- replicate as needed If you app accesses SP data you seriously need to build a caching strategy Data is potentially stored outside SharePoint deployment so you have to maintain it and think about data security You can develop in any technology you like but if you are using an Azure web site then ASP.net and C#/VB.Net are the obvious choice You can use any client API but most likely to be using CSOM There is no technology I can use in a SharePoint Hosted app that I cant use in a Provider Hosted App but (and heres the killer) the same is not true the other way round

Focus on Provider Hosted Apps, that way: I leave as many development options open as possible (i.e. I am not limited to JavaScript) I avoid having to deal with ugly App Webs Use Azure Web Site as the Provider Hosted App, that way: I can start out at zero cost I get Microsoft to maintain the web site I can scale up (with no down time) according to demand as customer base grows and even have the potential to scale on demand I can geo-replicate to different data centres to minimise latency (at a cost of course) Cache wherever possible using an Azure SQL Server database attached to the App web site, that way: I can start out free (again) I can scale as needed (again) and only pay as my customer base and revenue grows I can deliver Apps that perform well I can make the cache self cleaning I can potentially deliver apps that can be accessed by anonymous users Dont rely on the storage of primary customer data (just cached data), that way: I dont have to maintain it I can make data caching an option for customers who are security paranoid i.e. they can switch it on or off Retail through the Microsoft App Store, that way: I can access the world as a customer base I can promote other (non Cloud App Model) products and get my brand better known I can get Microsoft to collect my license fees (though I have to pay them a cut) I can leverage the App Store licensing framework to enable free trials etc.

Majority of solutions are free why? Policing for quality and misrepresenting adequate? Pros Cons

Guidance from https://msdn.microsoft.com/EN-US/library/dn383068.aspx Check you are in a support country https://msdn.microsoft.com/library/office/jj822316.aspxhttps://msdn.microsoft.com/library/office/jj822316.aspx (Australia is supported) Choose you account type (Company or Individual) and collect your account information: Microsoft Account Company Name/Display Name for Company and Individual registration respectively Logo must be 96 x 96px and less than 256 Kb Company/individual description Residential and contact information Legal profile Company reference (someone in your company other than yourself) Prepare the marketing blub

Head to https://sellerdashboard.microsoft.com https://sellerdashboard.microsoft.com Sign in to the Seller Dashboard with your Microsoft Account at (you may well get asked for security confirmation where they send you a verification code) Follow the wizard and fill in the required details Information required depends on whether you are registering as an individual or a company If you register as a company you need to provide contact details for one employee (I used my wife) 2 Phone calls and 10 days later I was registered!

You want to get paid, right? Follow the wizard Youll need bank account (or PayPal) details US Tax Details by completing an on-line Form W-8BEN-E (speak to your accountant if of a nervous disposition)

In a provider hosted app we have 3 touch points O365 tenancy Azure Web App User Cant do much about the user but we can control the other 2 touch points so where do we put them?

O365 Europe Azure North Central US User Adelaide (via Perth)

23 So I strongly recommend you consider using an Azure Web Site as your Hosted Provider platform for the following reasons: You can start out for free (I mean really for free not even using MSDN credits ideal for development and testing) You can scale up as your customer base grows If you stratospheric then you can auto-scale, geo replicate and beef up resources without any down time cool! Its all Microsoft so it should (in theory at least) all just work at least there is a better chance No patching or server maintenance You can leverage other Azure resources as need be such as a SQL Server DB (also starting from zero cost) Its all SSL enabled as standard (if you dont need your own domain name)

https://portal.azure.com https://manage.windowsazure.com

kaboodlesoftware.azurewebsites.net

1.User launches app as before 2.Sharepoint gets a Context Token from ACS as before 3.ACS Signs the token as before 4.The Context Token is sent back to the browser as before 5.The browser request the target page as before 6.The App checks the Cache Database to see if it contains a valid Access Token for the user in the context of the SharePoint host web site 7.If a valid Access Token is found it is returned to the Provider Hosted App 8.The Access Token is used to establish a Client Context as before 9.SharePoint validates the Access Token as before 10.Finally, the requested resources are returned to the browser as before 11.Only if there is no Access Token in the cache or the Access Token is no longer valid (it has expired) does Provider Hosted App request a new Access Token returned as part of the validated Context Token returned from ACS 12.The new context token is validated by the ACS as before 13.The Access Token is extracted from the Context Token along with a Cache Key and saved in the Database for subsequent reuse until it is no longer valid 1 2 3 4 56 7 8 9 10 11 12 13

Very simple flat table with just 3 fields: CacheKey: Uniquely identifies the user and the SharePoint host web site context AccessTokenString: Used to create a client context to access SharePoint resources (the string can be de- serialized into an Access Token) AccessTokenExpires: Access Tokens come with an expiry date and time which can be used to check if we need to get a new Access Token (valid for 12 hours) Establishing user authentication and authorization is a multi- step process that can take several seconds so you wont want to do it very often!

FieldTypePurposeNotes IDINTUnique identifier for table rowsPrimary Key Identity ViewIdNVARCHAR(50)Unique identifier for the relevant List ViewStores the View GUID ViewNameNVARCHAR(255)The name of the relevant List ViewOnly required for aesthetic reasons PageSizeINTThe size of the page for which the row stores cached data The page size is determined by the Max Columns and Max Rows settings in the App Part PositionNVARCHAR(255)The position string which identifies the page to load The Position string is used to access the page start position in the SPQuery TileDataNVARCHAR(MAX)Stores the tile dataThe tile data is an XML fragment used to serialize a Tile Data object for each item IsLastPageBITUsed to indicate whether the page is the last page in the view We need to know when the last page has been loaded so that the UI of the pager control can be configured appropriately

(3) (1) (2) (1) (2)

Note that HelloWebWeb is an App Web and is useful for debug and testing only. In due course we will publish this to an Azure web site

(1) (2) (1) (3) (2) (4) (3)

Kaboodle Site Map Demo

App Part Elements.xml file and custom properties WebSiteMap.aspx and html mark-up WebSiteMap.aspx.cs code behind Kaboodle Site Map Code Walk

The Property Element

Elements.xml

WebSiteMap.aspx: Mark-Up

WebSiteMap.aspx.cs: Code behind 1

Right click > Open With and select XML (Text) Editor

80 Description="$Resources:wss,exporttranslations_button_label"

87 public const string LICENSE_VERIFICATION_REST_BASE_URL = "https://verificationservice.officeapps.live.com/ova/verificationagent.svc/rest/verify?token=";

Whats Up Demo demonstration

Question and Answer

https://msdn.microsoft.com/en-us/library/office/jj220033.aspx https://msdn.microsoft.com/en-us/library/office/jj220037.aspx

Gold Silver Bronze

Gold Silver Bronze. In this presentation: Smorgasbord Compulsory Sharepoint Solution Development...

Documents

Transcript of Gold Silver Bronze. In this presentation: Smorgasbord Compulsory Sharepoint Solution Development...