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
Slide 3
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
Slide 4
SharePoint Development then and now Potted history of
SharePoint Development Options for development today
Slide 5
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?
Slide 6
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)
Slide 7
Slide 8
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
Slide 9
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.
Slide 10
Slide 11
Slide 12
Majority of solutions are free why? Policing for quality and
misrepresenting adequate? Pros Cons
Slide 13
Slide 14
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
Slide 15
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!
Slide 16
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)
Slide 17
Slide 18
Slide 19
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?
Slide 20
O365 Europe Azure North Central US User Adelaide (via
Perth)
Slide 21
Slide 22
Slide 23
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)
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
Slide 39
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!
Slide 40
Slide 41
41
Slide 42
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
Slide 43
43
Slide 44
44
Slide 45
Slide 46
Slide 47
(3) (1) (2) (1) (2)
Slide 48
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
Slide 49
Slide 50
(1) (2) (1) (3) (2) (4) (3)
Slide 51
Kaboodle Site Map Demo
Slide 52
App Part Elements.xml file and custom properties
WebSiteMap.aspx and html mark-up WebSiteMap.aspx.cs code behind
Kaboodle Site Map Code Walk
Slide 53
The Property Element
Slide 54
Elements.xml
Slide 55
WebSiteMap.aspx: Mark-Up
Slide 56
WebSiteMap.aspx.cs: Code behind 1
Slide 57
WebSiteMap.aspx.cs: Code behind 2
Slide 58
WebSiteMap.aspx.cs: Code behind 3
Slide 59
WebSiteMap.aspx.cs: Code behind 4
Slide 60
WebSiteMap.aspx.cs: Code behind 5
Slide 61
Slide 62
Slide 63
Slide 64
Slide 65
Slide 66
Right click > Open With and select XML (Text) Editor