Transforming your full-trust solutions to the Add-in model / SharePoint Framework
0 likes94 views
The document discusses the transformation of full-trust solutions to the SharePoint Add-in model and SharePoint Framework, focusing on the differences between traditional server-side solutions and modern client-side approaches. Key steps in the transformation process include assessing existing customizations, understanding the target platform, planning the re-imagined solution, and implementing the transformation using modern web development technologies. The document also emphasizes the importance of considering authentication and tracking progress throughout the transformation.
Transforming your full-trust solutions to the Add-in model / SharePoint Framework
- 1. May 20th, 2017 SharePoint Saturday Madrid Transform your full-trust solutions to the add-in model / SharePoint Framework Matthias Einig
- 3. BASICS
- 4. FULL TRUST CODE vs. “APP” “ADDIN” Package/Application/Code that uses • Server Side Object Model • Declarative Code • Infrastructure specific components (e.g. HTTP Handlers) • (Too?) High level of trust Package/Application/Code that uses • Client Side Object Model / REST • Runs with Office365 • Runs outside the SharePoint box • Configurable, but complex level of trust
- 5. FULL TRUST CODE vs. SHAREPOINT FRAMEWORK Package/Application/Code that uses • Server Side Object Model • Declarative Code • Infrastructure specific components (e.g. HTTP Handlers) • (Too?) High level of trust Package/Application/Code that uses • Client Side Object Model / REST • Based on JavaScript / TypeScript • Not yet available for SP 2016 • Has the same rights as the user running it
- 6. “Will you ever support farm solutions in Office 365?” Farm solutions are deployed cross SharePoint farm and they’d impact multiple customers… No. Vesa Juvonen, Microsoft
- 9. Magic
- 11. WHAT DOES TRANSFORMATION MEAN? •Look at what you have, then •Implement from scratch, while •Re-use concepts, patterns and data
- 12. WHY WOULD YOU TRANSFORM? • Moving from on-prem to Office365 or Hybrid • SharePoint version update • To be 'future proof' • Changed / New Requirements • Cannot start on a greenfield (time, money, complexity) • Maintenance problems caused by customizations
- 13. Replace / gradually update existing FTC components Re-use code / data structures / solution concepts/ integrations HOW WOULD YOU TRANSFORM YOUR CODE?
- 14. MAJOR CHANGES
- 15. MAJOR CHANGES • No SSOM, use CSOM/REST/Graph • Do not use the Feature Framework • Avoid declarative artifacts / CAML (WebTemplates, Content Types, etc.) • Do not use MasterPages • Minimize Branding • Approach SharePoint/Office365 as a service • ”Modern” web development technologies (SPFx) instead of .NET
- 16. CAML == BAD Custom Web Template onet.xml X feature activations onet.xml X feature activations onet.xml X feature activations +2 onet.xml X feature activations +4 onet.xml X feature activations onet.xml X feature activations << Copy >> Significant differences on the outcome unless web template onet.xml has been updated cross site collections with the changes which were also done for out of the box team site. Web Template onet.xml is created by copying team site onet.xml and by adding stapled features to the onet.xml Service updates for introducing new capabilities to team sites also using feature stapling Source: TEE2015 DEV-B308 http://matte.in/TTE2015Transform
- 17. REIMAGINE!
- 18. TRANSFORMATION != Copy & Paste • Is SharePoint/Office365 providing already the functionality? • Does your solution benefit from the SharePoint UI? • Are you relying on 3rd party systems? • Does it have to be SharePoint? • Are the business requirements still valid?
- 20. THE TRANSFORMATION PROCESS Learn Plan & Track TransformAssess
- 21. ASSESS
- 22. ASSESS CUSTOMIZATIONS • Understand which customizations you have • Understand what they do • Understand why you have them • Understand the impact they make on the environment • Understand the involved effort to transform
- 23. ASSESS USAGE • Analyze if and where the customizations are deployed • Analyze if the deployed customizations are still used • Analyze if the used customizations are still required
- 24. ASSESS REQUIREMENTS • Discuss existing solution with the business. • Discuss the requirements with the business. • Learn how the existing customization are used • Decide what to keep, change and remove.
- 25. LEARN
- 26. LEARN • Add-in Model techniques • App Part • Full Immersive app • UI Custom Actions • PowerShell Scripts / Console applications • Client Parts / SharePoint Framework (SPFx) • Hosting • on-prem/Office365, • Provider/SharePoint hosted • Authentication • On-prem AD or Azure AD?
- 27. "NEW" PROVISIONING APPROACHES Provider Hosted App using CSOM/REST .NET Console App using CSOM/REST PowerShell using CSOM/REST ”Mechanical Turk” PnP Provisioning Engine Stand alone site using Graph
- 28. MOVE TO REMOTE PROVISIONING • 'Roll your own' • Complex, high maintenance • Flexible and potentially build for the task • Use the PnP Provisioning Engine • Tested, pre-built • Template approach • Code approach • Extensible • Use the PnP Partner Pack • Based upon the PnP Provisioning Engine
- 29. CONSIDER AUTHENTICATION CAREFULLY If you transform your solution to SharePoint Online: • Do you have an on-prem AD? • Do you use ADFS? • Are you moving to Azure AD? • Will you use Hybrid? • Will you use explicit or implicit grant flow for auth?
- 30. DEVELOPMENT: ADD-IN MODEL • Complex security • Add-in security vs User security • Limited ability to specify what the add-in wants to do • Powerful: full access to C# / .NET ecosystem • Rich APIs • CSOM • REST • Microsoft Graph Add-in
- 31. DEVELOPMENT: SHAREPOINT FRAMEWORK • Not a replacement for Add-Ins but rather another option • Simple security • The solution users has the same rights as the user using it • Powerful: access to the full JavaScript ecosystem • Rich APIs • JSOM • REST • Microsoft Graph Fx
- 32. DEPLOYMENT FULL TRUST • WSP files • Full control over server • Flexible • With great power comes great responsibility SANDBOX • WSP files • No control over server • Less flexible • With less power comes great frustration APPS / ADD-INs • Still new to many people • Separate hosting model • Complex authentication model SPFx • GA since March 2017 • Separate hosting model • Potentially very new development model to 'traditional' SP Devs
- 33. RESOURCES Office Pattern & Practices https://dev.office.com/pnp • Community project lead by Microsoft • Core Library, PowerShell cmdlets, samples, reference implementations • Endorsed by SharePoint product group SharePoint Framework (SPFx) https://dev.office.com/sharepoint • Additional development model • Still in preview
- 34. PLAN & TRACK
- 35. PLAN & TRACK • Plan which customization artifacts to transform or to abandon • Group depending artifacts to use cases • Track the progress of the transformation
- 36. TRANSFORM
- 37. www.sptransformator.com Develop from scratch yourself or use
- 40. discovers & analyzes… ü SharePoint Add-ins ü Sandboxed Solutions ü Farm Solutions (WSP) ü Assemblies ü Executables ü JavaScript Files supports… ü Office 365 ü SharePoint Online ü SharePoint 2016 ü SharePoint 2013 ü SharePoint 2010 ü SharePoint 2007 transforms to… ü Client Side Code (CSOM) ü JavaScript (JSOM) ü REST API ü PowerShell Script (CSOM) ü SharePoint Framework (SPFx) ü Office Dev PnP CSOM ü Office Dev PnP JSOM ü Office Dev PnP PowerShell ü PnP Provisioning Engine
- 41. SUMMARY 1. ASSESS Understand the existing customizations and requirements 2. LEARN Understand the target platform and technology 3. PLAN & TRACK Re-imagine and plan the solution 4. TRANSFORM
- 42. Please, fill your SPS Madrid passport if you want to participate. You can win one of these gifts: Raffle 10 9 8 Odor Odor@winterfell.com
- 43. Gold sponsors ______________ Silver sponsors Bronze sponsors Collaborate Platinum sponsor
- 44. Thank you!