Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Chris O'Brien - Modern SharePoint development: techniques for moving code off SharePoint servers


Published on

Covers some key techniques and references for "cloud-friendly" SharePoint development (i.e. suitable for Office 365, or perhaps on-premises SharePoint projects which want to stay cloud compatible or benefit from greater isolation from SharePoint).

Includes detailed coverage on - Remote Event Receivers in Azure, "PowerShell + CSOM" scripts, and Microsoft's AMS samples.

Published in: Technology

Chris O'Brien - Modern SharePoint development: techniques for moving code off SharePoint servers

  1. 1. Modern SharePoint Development - techniques for moving code off SharePoint servers Chris O’Brien – MVP
  2. 2. About me  Independent Consultant  Head of Development, Content and Code  Blog:  Twitter: @ChrisO_Brien  LinkedIn: chrisobrienmvp
  3. 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. 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. 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. 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. 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. 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. 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
  10. 10. The remote code model
  11. 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. 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. 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. 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. 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. 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. 17. DEMO: Remote code in Azure (Remote Event Receivers) Click “next slide” to see this demo on YouTube, or use link: 4T1eLg0_to
  18. 18. PowerShell and CSOM
  19. 19. PowerShell in Office 365 0 100 200 300 400 500 600 700 800 900 Poweshell cmdlets PS cmdlets On-premises SharePoint Online On-premises SharePoint Online 774 30
  20. 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. 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. 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. 23. DEMO: PowerShell + CSOM scripts Click “next slide” to see this demo on YouTube, or use link:
  25. 25. PowerShell + CSOM – advanced operations Importing/exporting taxonomy terms Importing/exporting search schema Recreating site collections Sandbox solution deployment – no API for this! Activating web templates Create publishing pages Uploading files
  26. 26. Microsoft's App Model Samples
  27. 27. AMS – why you should care  “Office App Model Samples” –  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. 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. 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. 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
  31. 31. AMS – COB’s 5 favourite core methods 1. CreateTaxonomyField (including wire-up) 2. CreateField/CreateContentType 3. AddList/AddDocumentLibrary 4. UploadDocumentToLibrary 5. AddCustomAction
  32. 32. Other useful AMS artifacts  Controls for use in provider-hosted apps:  “People picker”  “Taxonomy picker”
  33. 33. DEMO: AMS samples Click “next slide” to see this demo on YouTube, or use link:
  34. 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. 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. 36. Thank you for attending! @ChrisO_Brien