This document discusses modern techniques for developing for SharePoint in a cloud-friendly way by moving code off SharePoint servers. It covers remote event receivers, PowerShell with CSOM, and Microsoft's App Model Samples. Remote event receivers allow executing code in response to events. PowerShell and CSOM is a powerful combination. The App Model Samples provide helper libraries and examples for common tasks like uploading files, provisioning sites and managing terms. While Microsoft's optimal approach is debated, these techniques allow customizations to be deployed to Office 365.
Chris O'Brien - Modern SharePoint development: techniques for moving code off SharePoint servers
1. Modern SharePoint Development
- techniques for moving code off
SharePoint servers
Chris O’Brien – MVP
www.sharepointnutsandbolts.com
2. About me
Independent Consultant
Head of Development, Content and Code
Blog: www.sharepointnutsandbolts.com
Twitter: @ChrisO_Brien
LinkedIn: http://uk.linkedin.com/in/
chrisobrienmvp
3. Agenda
Background – remote code for the win
Core techniques/references:
Remote Event Receivers (e.g. in Azure)
PowerShell and CSOM – a winning combo
AMS samples
The “optimum position” debate
Summary
4. SharePoint as a dev platform
8 years of farm solutions
– we were hooked!
The horror:
Objects not disposed
Dodgy web parts
API bad practices
Timer job proliferation
..and more
5. SharePoint – the bad parts
Too easy for custom
code to bring
SharePoint down
Result – SharePoint
got a bad rep
No good for Office
365!
6. What is cloud-friendly dev?
No - farm solutions/files deployed to _LAYOUTS
• No feature receivers
• No timer jobs
• No event receivers
Yes - sandbox solutions, but no code in sandbox solutions
Yes - apps (aka remote code)
* Deployable in Office 365 *
• No custom field controls
• No site definitions
• No custom web parts (due to use of code)
7. Benefits even to on-premises projects?
• One app can no longer bring SharePoint down
Better isolation
• Fewer SharePoint artifacts to audit/upgrade
Simpler upgrade (e.g. to “SharePoint 2015”)
• Less rework to transition
Keeps door open to Office 365
8. Code implementation mapping
Farm solution Remote code/apps
Timer job Scheduled process in Azure (CSOM to
read/write to SP)
Event receiver Remote event receiver
Custom field control JSLink
Site definition WebTemplate in NCSS *
Run With Elevated Privileges App-only authentication
Custom web parts/user control App part, or JavaScript + DOM
Feature receiver, DelegateControl,
application page
None – but other approaches possible
* NCSS = no-code sandbox solution
9. Problem areas (examples)
• Custom authentication
• Custom claims provider (needed for People
Picker in SAML claims)
• Admin UI customisations
Not possible
• Branding of OneDrive sites (personal sites)
• Remote provisioning (of site collections)
Possible, but
involved:
NOTE! The AMS samples cover these scenarios
11. Remote code – what you need to know
Various flavours:
“Off-box” server-side code (CSOM)
Powershell/CSOM scripts (CSOM)
JavaScript code (JSOM/REST)
An app is needed for server code (trust)
Required to use app authentication (OAuth or S2S)
Alternative – user authentication with password and
SharePointOnlineCredential (e.g. PS/CSOM script)
12. Examples of remote server-side code
(CSOM)
Pages in an app (e.g. ASP.NET – in Azure or IIS)
User goes OUT of SharePoint and into remote app
App pages in an app part (IFrame) in SharePoint page
User stays in SharePoint, IFrame brings remote page in
Tip! This is a key “hook” to execute remote code
Services
Remote Event Receivers
App events | List/list item events | WebProvisioned event | etc.
13. Remote provisioning code – considerations
JavaScript-based approaches can be interesting:
Custom control added to site home page
When first user (or admin) hits site, shows a “Getting your site
ready” message
JSOM code runs to provision fields/content types/pages etc.
Sets flag(s) on web property bag when done – next run checks
From the server-side (CSOM) approaches:
The WebProvisioned event (RER) can be a useful hook!
14. Remote code (CSOM) – where?
Options include:
Azure Websites (VM role not needed)
Some IIS servers (usually inside your network)
Pros/cons
Pros – Azure Websites Cons - Azure Websites
+ Easy. Even a dev can do it! - Typically need to implement authentication
(since accessible on internet)
+ Microsoft take care of SSL,
external access, load-balancing,
high availability etc.
- Need to implement Azure if not done
already (e.g. who pays the bill?)
15. Remote Event Receivers
Key pillar of “remote code” model
Effectively a WCF service somewhere callable
List/list item receivers
WebProvisioned receiver
App events:
AppInstalled, AppUpgraded, AppUninstalled (also –ing)
*No* equivalent for Feature Receivers
16. Remote Event Receivers – key steps
1. Create provider-hosted app (and add RER code)
2. Create Azure Website (if doesn’t exist)
3. Publish remote code to Azure
4. Register app with AppRegNew.aspx (or Seller Dashboard)
5. Publish app package, put in app catalog
6. Add to site
7. Associate RERs with lists (e.g. with PowerShell/CSOM)
8. Test!
17. DEMO:
Remote code in Azure
(Remote Event Receivers)
Click “next slide” to see this demo
on YouTube, or use link:
https://www.youtube.com/watch?v=G
4T1eLg0_to
20. PowerShell + CSOM – don’t confuse with:
The MSOL/Azure AD cmdlets
Generic Office 365 PowerShell – add
users, groups etc.
The SPO cmdlets
SharePoint Online PowerShell –
create site collections etc.
Instead, use STANDARD PowerShell
command prompt for PS + CSOM
21. PowerShell + CSOM – how it works
Using PS ability to call any .NET object
Need to have CSOM DLLs available
Run script from a SharePoint environment
OR
Install “client redistributable” (or manually copy DLLs)
22. PowerShell + CSOM – what it looks like
Add-Type -Path "c:LibMicrosoft.SharePoint.Client.dll"
Add-Type -Path "c:LibMicrosoft.SharePoint.Client.Runtime.dll"
Add-Type -Path "c:LibMicrosoft.SharePoint.Client.Taxonomy.dll"
# connect/authenticate to SharePoint Online and get ClientContext object..
$clientContext = New-Object Microsoft.SharePoint.Client.ClientContext($url)
$credentials = New-Object
Microsoft.SharePoint.Client.SharePointOnlineCredentials($username, $securePassword)
$clientContext.Credentials = $credentials
# do something..
$rootWeb = $clientContext.Web
$clientContext.Load($rootWeb)
$clientContext.ExecuteQuery()
$rootWeb.Title = "Updated from PS/CSOM script"
$clientContext.ExecuteQuery()
23. DEMO:
PowerShell + CSOM scripts
Click “next slide” to see this demo
on YouTube, or use link:
http://youtu.be/yuD21t-C9kQ
27. AMS – why you should care
“Office App Model Samples” –
http://officeamscodeplex.com
Version 2 released May 2014
Core CSOM helper libraries,
small/large samples etc.
Because it’s AWESOME – it’s the “helper library” you
dreamed about, plus samples you’d use!
28. AMS – what’s in there (AKA the “eye test”
slide )
Branding
• DeployThemeToWeb
• SetThemeToWeb
• SetSiteLogo
Features
• ActivateFeature
• DeactivateFeature
Fields and content types
• AddContentTypeToList
• AddFieldToContentType
• CreateContentType
• CreateField
• CreateTaxonomyField
(including wire-up)
Files and folders
• UploadDocumentToLibrary
• UploadDocumentToFolder
• CreateFolder
Pages
• AddWebPartToWebPartPag
e
• AddWebPartToWikiPage
• DeleteWebPart
• AddHtmlToWikiPage
Sites
• AddSite
• AddSiteCollectionTenant
• MySiteSearch (CSOM
search)
• ProcessQuery (CSOM
search)
• SetPropertyBagValue
Security
• AddAdministrators
• GetAdministrators
• GetSharingCapabilitiesTena
nt
Navigation
• AddCustomAction
• AddNavigationNode
• DeleteAllQuickLaunchNodes
List
• AddList
• AddDocumentLibrary
• GetList
• UpdateListVersioning
See – I *told* you it was AWESOME!
29. AMS – what’s (really) in there
Branding
Create fields
and content
types
Create
lists/libraries
Create
sites/site
collections
Upload files
Configure
navigation
App code (CSOM) to support lots of “collab” scenarios:
30. AMS – COB’s 5 favourite scenarios
1. Modifying OneDrive sites (e.g. branding)
2. Remote “timer job”
3. Custom site collection creation (“templating”)
4. Adding Remote Event Receivers to host web
5. Cross site collection navigation (term set-driven)
6. Bulk update user profiles
34. The optimum position (for Microsoft?)
You use all the techniques we’ve discussed, so that..
..all your customizations could be deployed to Office 365
But also:
MSFT optimum Reason But consider!
NO custom master
page
MSFT want to push updates
to master pages
Your customisations could
break (e.g. DOM change)
NO XML for
provisioning, remote
code used instead
Fields/ctypes in XML causes
them upgrade problems
Unclear if any benefit to
implementor
35. Summary
Many clients (not just Office 365 orgs) will want “modern”
cloud-friendly development
Some key
elements:
The “optimum position” debate is worth following
Apps
No-Code
Sandbox
Solutions
PS/CSOM
scripts
Remote
Event
Receivers
Azure
AMS
samples
36. Thank you for attending!
www.sharepointnutsandbolts.com
@ChrisO_Brien