This document summarizes a presentation about relearning SharePoint development given by Bob German from BlueMetal Architects. It discusses: - The history of SharePoint development approaches from 2003 to 2013 and Microsoft's push to develop solutions outside of SharePoint using apps and client-side APIs. - Three main approaches to modern SharePoint development: developing in the browser, in the cloud, and using Workflow Manager. - Examples of solutions that were re-architected from traditional server-side code to follow these new approaches. - A call to action for SharePoint professionals to update their skills and start developing more in the browser and using client APIs rather than server APIs.

1. @BASPUG @Bob1German
Relearning SharePoint
Development
The New Way to Develop Solutions and Apps

2. @BASPUG @Bob1German
BlueMetal Architects

We are experts at building solutions that exactly meet the needs
of our customers by apply the right people, processes and
platforms.

Our focus is on modernizing applications through expertise in
Creative, Social, Development and Data.

We have offices in Boston, New York, and Chicago.
Bob German
Principal Architect at BlueMetal Architects
Developer and architect on the SharePoint platform
since it was called “Site Server 3.0”
Co-author of SharePoint 2010 Development with
Silverlight for Addison-Wesley
http://blogs.msdn.com/BobGerman
About the Speaker
@Bob1German

3. 2003
2001
• ASP Classic “Digital Dashboard”
• CAML is born
2003
• First .NET version; limited API
• No documented deployment model
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
A Brief History of SharePoint Development

4. 2003
2001
2003
@BASPUG @Bob1German
• ASP Classic “Digital Dashboard”
• CAML is born
• First .NET version; limited API
• No documented deployment model
approaches to SharePoint
development:
1
2007
Hosting:
2010
• Added Sandbox
• Added Client APIs
2013
• Deprecated Sandbox
• Added App Model, more Client APIs
3
Farm Solution
• Well documented model with
“Features” and “Solutions”
2
Sandboxed
App
On-prem
On-prem,
O365
On-prem, O365
Code runs: In browser or
On
SharePoint
servers
In browser or
In SP user
code service
process
In browser or
On external site,
out of
SharePoint
Capability: Unlimited
Very Limited
Emerging
API:
Server
Server
(limited)
Client
Security:
Code can be
omnipotent
Code runs as a Code runs as
user
app or user
A Brief History of SharePoint Development

5. Welcome
to the App
Model
Host
Web
App
Web
External
Hosting
The Maturing of SharePoint
Development
• Complete App isolation
• Isolated execution (outside of SharePoint)
• Isolated storage (SharePoint “App Web”)
• SharePoint can completely clean up when
app is removed
• Granular App Permissions – Control
what each app can do on behalf of
users

6. Welcome
to the App
Model
@BASPUG @Bob1German
App is
installed
here
App runs
here
Host
Web
App
Web
SharePoint
Hosted App
Host
Web
App Web
(optional)
App
Azure
or other provider
Provider or
Auto-Hosted App

7. App Web
 Provisioned by SharePoint on app
installation
 Code in Javascript on browser
No Server Code – period!
(though you can leverage
installed ASP
.NET controls)
 May contain declarative, webscoped features (lists, site pages,
client script, images, css)
 Access host web via cross-domain
library
“Cloud”
(Provider or Autohosted)
 Auto-hosted apps are provisioned
by Office 365 on app installation
(Office 365 only; not yet released)
 Any hosted web site can work;
pretty much anything goes
 Access host and app webs via
OAuth – run under:
 End user’s permissions
 App permissions
Host
Using the App Web and the Cloud
Web
App
Web

8. @BASPUG @Bob1German
Host
Web
http://myserver/sites/myweb/
App Web
Cross-Domain
Library
http://app12345/sites/myweb/
(optional)
App
Azure
or other provider
OAuth
http://whatevs.com/somepath/
Different domain names leverage
browsers’ same-origin policy
App Isolation

9. The Good
 Complete isolation
 Apps can’t interfere with the operating
system
 Apps can’t interfere with other apps
 Apps have granular permissions – no more
omnipotent code
 Central distribution
 Vet and control apps
 No more messes
 The system can clean remove an app
completely
 App isolation should make upgrades easier
The Bad and The Ugly
 Applications are restricted
 Can’t take advantage of server APIs
 More difficult to interact with other apps
 Can’t elevate privileges –
no more omnipotent code
 Central distribution
 Need to configure, host apps
 Version 1 Challenges
 No auto-hosted apps on prem or in Store
 Limited functionality
 Can’t
change host web page (e.g.
branding)
 Client API’s much better but not complete
 Can’t be provisioned in site templates
The App Model Today
 Most solutions need to be
rewritten

10. @BASPUG @Bob1German
Is my organization ready
for SharePoint 2013?
Will the app model
be another flash in the
pan like Sandboxed
Solutions or Silverlight?
Will Sandboxed solutions
really go away, and when?
Will Microsoft stop
supporting Farm Solutions
some day?
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 my organization want
to run SharePoint in
the cloud?
What’s a SharePoint
Professional to do?

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

12. Develop Outside the Box
@BASPUG @Bob1German
 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:
 The solution: Run it all in a Content Editor Web Part
(or in a SharePoint Hosted App)
Real World Scenario: IT Issues Dashboard

13. 1. Develop in the Browser
Browser Programming and SharePoint Hosted Apps
2. Develop in the Cloud
Programming in Azure and External Web Sites
3. Develop in Workflow Manager
SharePoint 2013 and Workflow Foundation 4.5
Develop
Outside the
Box

14. 1. Developing on the
Client

15. @BASPUG @Bob1German
 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
 Began its life humbly as a sandboxed solution
 Now living a dual life:
In a Content Editor Web Part in SharePoint 2010
In an App in SharePoint 2013
Site Provisioning Tool

16. 1
HTML and CSS
2
Get SP Context
1
3, 4, 5
1
2
3
Get and display sites
4
Find WebTemplate
3, 4, 5
2
5
Create Child Site
2010
Code Walk-through
2013

17. 2. Developing in the
Cloud

18. @BASPUG @Bob1German
 Geocodes list items and displays them on a map
 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
 This one started as a SharePoint Provider Hosted App
 Now moonlighting:
As a server-side event handler and
Visual Web Part in SharePoint 2010
As a remote event handler and Client Web Part
in a SharePoint Provider Hosted App
Location Mapping Tool

19. 1
GeoLocation Field
2
2
Locations List
1
5
1
4
2
3
HTML and CSS
4
Handle List Event
5
6
5
Geocode; Update list
7
3
3
6
Get SP Context
6
2010
Code Walk-through
7
Display Map
4
7
2013

20. 3. Developing for
Workflow Manager

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

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

23. @BASPUG @Bob1German
 Prepare for the future:
Pretend you might be going to Office 365
 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
Architectural Overview
http://bit.ly/FutureProof-A
SP-Hosted – Site Creation Sample
http://bit.ly/FutureProof-B
Provider-Hosted – Locations Sample
http://bit.ly/FutureProof-C
Workflow – Site Creation with REST
http://bit.ly/SiteCreationWorkflow
Slides
Summary and Call to Action

24. BOSTON | NEW YORK | CHICAGO
44 Pleasant Street, Watertown, MA 02472
www.bluemetal.com
Blog.bluemetal.com
@bluemetalinc
Thank You!