Bob German Principal Architect Future-Proof your SharePoint Customizations: Build 2010 Solutions that become 2013 Apps

Bob German  SharePoint Principal Architect at BlueMetal Architects  Developer and architect on the SharePoint platform since Site Server 3.0  Co-author of SharePoint 2010 Development with Silverlight for Addison-Wesley BlueMetal Architects  Boston, New York and Chicago.  We strive to build solutions that exactly meet our clients’ needs  SharePoint / Information Management  Data Platforms / Analytics ● Design  Mobile Apps ● Enterprise Apps ● App

A Brief History of SharePoint Development 2007 Well documented model with “Features” and “Solutions” 2010 Added Sandbox Added Client APIs 2013 Deprecated Sandbox Added App Model, more Client APIs Key concept: Microsoft wants us to start developing outside of SharePoint Similar to Facebook and other online service “apps” Code runs in browser or an external web site; access SharePoint via Client API’s Works in Office 365 and other hosted services Helps with stability, upgradability on-premises as well 2003 First.NET version; limited API No documented deployment model ASP Classic “Digital Dashboard” CAML is born

Application code is omnipotent Applications can affect farm stability and scalability Applications can circumvent security Doesn’t play well in shared / multi-tenant environments SharePoint development today is like MS- DOS development was in 1981.

No IsolationProcess IsolationApp Isolation Examples MS DOS, Windows 3.1, Windows 95, Mac OS 9 Windows NT, Windows 7, Mac OS X Windows Phone 8, Android, iOS Validated API protects OS Yes Process memory protection Yes App storage isolation Yes Permission SchemeNoneUser-basedApp-based SharePoint farm Solution SharePoint App

It’s time to rethink how we develop for SharePoint 1.Microsoft wants us to start developing outside of SharePoint 2.Instead of trying to protect SharePoint from code running within it, the Client APIs provide isolation and protection Similar to Facebook and other online service “apps” Code runs in browser or an external web site; access SharePoint via Client API’s Works in Office 365 and other hosted services Better on premises as well! Better stability, upgradability, and control Thinking Outside the Box

Comparing the Models Traditional Solutions Server API Code runs inside SharePoint (farm level or user code service) Deploy in Solutions Gallery (Sandbox or Central Admin) Limited Cloud Support Run as user or be omnipotent Modern Solutions Client API Code runs outside of SharePoint (browser or external web server) Deploy via App Catalog (Enterprise or Office Store) Designed for the Cloud Run with granular App Permissions

The SharePoint App Model Host Web App Web SharePoint Hosted App Provider or Auto-Hosted App App Azure or other provider Host Web App Web (optional) App is installed here App runs here

Browser Based Isolation App Azure or other provider Host Web App Web (optional) Different domain names leverage browsers’ same-origin policy for isolation

The App Model Today

? Will Sandboxed solutions really go away, and when? Where are we supposed to host provider-hosted apps? Will Auto-hosted apps be available on premises? And if they are – will they run on premises or in Windows Azure? Will the app model be another flash in the pan like Sandboxed Solutions or Silverlight? Will Microsoft stop supporting Farm Solutions some day? Will customers migrate to SharePoint Online? What’s a SharePoint Professional to do? Are my customers ready for SharePoint 2013? Can we transition from licenses to hosted services?

Develop Outside the Box Instead of…Start to… Running code on the server  Run code in the browser Using the Server API  Use the Client API Designing solutions the traditional way  Design solutions that are structured like apps Buying products that work only on premises  Buy products that work in Office 365 Office 365? Pretend you might be going to Office 365… It’s a good bet Microsoft will invest in development approaches that work on Office 365 Your on-prem SharePoint farms will enjoy the stability and ease of upgrades that Office 365 demands

Real World Scenario IT Issues Dashboard Visual tracking of issues across a large department Common uses: Track service requests (help desk, etc.) Track workflow performance (used with an audit list) Dashboard to display SharePoint list data The challenge:

demo IT Issues Dashboard Content Editor Web Part SharePoint Hosted App

Develop Outside the Box 1.In the Browser 2.External Web Server Programming in Azure and External Web Sites 3.In Workflow Manager SharePoint 2013 and Workflow Foundation 4.5

demo Site Provisioning Web Part Content Editor Web Part SharePoint Hosted App Client Object Model Lists and provisions child sites using a custom Web Template Common uses: Manage sites within a department site collection Manage project sites Automatic navigation to child sites

Site Provisioning Web Part HTML and CSS Get SP Context Find WebTemplate 5 Create Child Site 3 Get, display sites 3, 4, 5

App Authentication User accesses SharePoint JSOM or REST API’s using inherent SharePoint security already in place Used by Javascript on web pages in App web or using Cross-domain library Only runs as User – no App identity Internal Standard Authorization protocol used in many public web sites (FaceBook, Twitter, Live, Google, etc.) – “Valet Key” to access information Requires external authentication server (e.g. Azure ACS) Office 365 Auto-Hosted Apps automatically set up for OAuth External (OAuth) SharePoint server is configured to trust an external server to authenticate users (Server  Server) No external authentication server – great for on-premises scenarios Uses SSL Certs for simplicity – App code needs access to SSL Private Key External (S2S)

Standard in use by dozens of public sites Similar to a valet key App gives to a partly trusted 3rd party Grants limited access SharePoint grants the app access on the user’s behalf No need to pass the user’s credentials SharePoint can limit the scope of access OAuth – Open Authorization

demo Location Mapping Web Part Provider Hosted App Client Object Model with OAuth Geocodes list items and displays them on a map Event receiver geocodes items Common uses: Display store or customer locations Adapt to plot events or photos on a map Get ready for the new GeoLocation features in SharePoint 2013

Location Mapping Web Part Handle List Event 2 Locations List HTML and CSS Geocode; Update list Get SP Context Display Map GeoLocation Field 1 1

Workflow Manager SharePoint 2013 SharePoint Designer 2013 Visual Studio 2012 SharePoint 2010 Workflow Engine Workflow Manager 1.0 SQL Server and Windows Server ClientOM REST Services  Workflow Manager hosts WF 4.5 workflows  Workflows are 100% declarative  Extend via web services, not installed assemblies

demo Reusable Workflow Steps Reusable workflow step runs in Workflow Manager 1.0 Accesses SharePoint REST API Works with Visual Designer in SP Designer 2013

Microsoft Moved the Cheese Traditional SharePoint Development (Code runs on SharePoint servers) New App Model (Code runs outside of SharePoint) Old Packaging New Approach (Code runs outside of SharePoint) SharePoin t Developer

Resources and Call to Action Prepare for the future – develop outside of SharePoint Update Development Skills Learn client side development (Javascript, jQuery, Client OM, etc.) Learn SharePoint App design patterns Learn Azure and Oauth Develop more in the browser, less on the server Favor client APIs over server APIs Resources Architectural Overviewhttp://bit.ly/FutureProof-A SP-Hosted – Site Creation Samplehttp://bit.ly/FutureProof-B Provider-Hosted – Locations Samplehttp://bit.ly/FutureProof-C Workflow – Site Creation with RESThttp://bit.ly/SiteCreationWorkflow