36
1 | SharePoint Saturday Milan – 18 May 2013

SharePoint development evolution from classic to app

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: SharePoint development evolution from classic to app

1 | SharePoint Saturday Milan – 18 May 2013

Page 2: SharePoint development evolution from classic to app

2 | SharePoint Saturday Milan – 18 May 20132 | SharePoint Saturday Milan – 18 May 2013

Grazie ai nostri Sponsor!

Gold Silver

Page 3: SharePoint development evolution from classic to app

3 | SharePoint Saturday Milan – 18 May 2013

Marco Rizzi – Solution Architect – Avanade [email protected] - @marcorizzi – http://marcorizzi.com

App model per SharePoint Saturday Milan

Page 4: SharePoint development evolution from classic to app

4 | SharePoint Saturday Milan – 18 May 20134 | SharePoint Saturday Milan – 18 May 2013

Old school Are you sure that is the

best approach?

Experiences New way of thinking Think fresh Evolution

Page 5: SharePoint development evolution from classic to app

5 | SharePoint Saturday Milan – 18 May 20135 | SharePoint Saturday Milan – 18 May 2013

WSP vs App WSP (farm solution)

Design Farm Solutions for Administrators

Full control of the platform (server object model)

Farm solutions cannot be installed on SharePoint Online, only on premise. Microsoft handles all the management of SharePoint Online, there is no need for administrative extensions.

App Design App for end-users Client object models Deployed on SharePoint

farm as package but executed outside SharePoint

Be installed by tenant and site collection administrators both on premise and SharePoint Online

Replacement of Sandboxed solutions (internals inherits some components)

Page 6: SharePoint development evolution from classic to app

6 | SharePoint Saturday Milan – 18 May 2013

Apps by Microsoft

Content of the section comes from msdn and technet

Page 7: SharePoint development evolution from classic to app

7 | SharePoint Saturday Milan – 18 May 20137 | SharePoint Saturday Milan – 18 May 2013

Doing thinks the app way Custom code that runs on the SharePoint servers is not

allowed in apps for SharePoint. This is not a significant limitation. It simply means that your custom business logic moves either "down" to the client device or "up" to the cloud.

A similar point applies to the fact that Features in apps for SharePoint cannot have site collection, web application, or farm scope. This doesn't mean that you give up some user interface (UI) element or functionality. It simply means that the implementation of the component moves out of SharePoint and onto a client or remote web application or remote database.

7

Page 8: SharePoint development evolution from classic to app

8 | SharePoint Saturday Milan – 18 May 20138 | SharePoint Saturday Milan – 18 May 2013

App developmentThe most important guidance is develop an app rather than a classic solution whenever you can. Apps for SharePoint advantages:

They provide users with the easiest discovery, purchase, and installation process.

They provide administrators with the safest SharePoint extensions.

They provide you with the simplest marketing and sales system based on a Microsoft-provided online app store.

Maximize the flexibility in developing future upgrades. Maximize the ability to leverage existing non-SharePoint

programming skills. Integrate cloud-based resources in smoother and more

flexible ways.

8

Page 9: SharePoint development evolution from classic to app

9 | SharePoint Saturday Milan – 18 May 20139 | SharePoint Saturday Milan – 18 May 2013

App development They enable your extension to have permissions that

are distinct from the permissions of the user who is running the app.

They enable you to use cross-platform standards, including HTML, REST, OData, JavaScript, and OAuth.

They enable you to leverage the SharePoint cross-domain JavaScript library to access SharePoint data. Alternatively, you can use a Microsoft-provided secure token service that is OAuth-compliant.

They can extend SharePoint Online websites as well as on-premises SharePoint websites.

9

Page 10: SharePoint development evolution from classic to app

10 | SharePoint Saturday Milan – 18 May 201310 | SharePoint Saturday Milan – 18 May 2013

App object model Client object model for managed code

.NET object model, Silverlight object model, Mobile object model

Javascript object model To be used in either inline script or separate .js files. Same functionality as the .NET Framework and

Silverlight client object models. Set of *.js files located at %ProgramFiles%\Common

Files\Microsoft Shared\web server extensions\15\TEMPLATE\LAYOUTS on each server

Deprecated API Still supported for backward compatibility, but

recommend to not use them: the ASP.NET (asmx) web services, and direct Remote Procedure Calls (RPC) calls to the owssvr.dll file.

10

Page 11: SharePoint development evolution from classic to app

11 | SharePoint Saturday Milan – 18 May 201311 | SharePoint Saturday Milan – 18 May 2013

Factors to determine API to use

11

If you want to do this ... ... use these APIs

Create an ASP.NET web app that performs CRUD operations across a firewall on SharePoint data or external data that is surfaced in SharePoint by a BCS external content type

JavaScript client object model

Create an ASP.NET web app that performs CRUD operations on SharePoint data or external data that is surfaced in SharePoint by a BCS external content type, but does not have to call SharePoint across a firewall

.NET Framework client object model, Silverlight client object model, or REST/OData endpoints

Create a LAMP web app that performs CRUD operations on SharePoint data or external data that is surfaced in SharePoint by a BCS external content type

REST/OData endpoints

Create a Windows Phone app that performs CRUD operations on SharePoint data Mobile client object model

Create a Windows Phone app that uses the Microsoft Push Notification Service to alert the mobile device of events in SharePoint

Mobile client object model and the server object model

Create an iOS or Android app that performs CRUD operations on SharePoint data REST/OData endpoints

Create a .NET Framework application that performs CRUD operations on SharePoint data

.NET Framework client object model

Create a Silverlight application that performs CRUD operations on SharePoint data Silverlight client object model

Create an HTML/JavaScript application that performs CRUD operations on SharePoint data

JavaScript client object model

Create an app for Office that works with SharePoint JavaScript client object model

Create a custom Windows PowerShell command Server object model

Create a timer job Server object model

Create an extension of Central Administration Server object model

Create consistent branding across an entire SharePoint farm Server object model

Create a custom Web Part, application page, or ASP.NET user control Server object model

Page 12: SharePoint development evolution from classic to app

12 | SharePoint Saturday Milan – 18 May 201312 | SharePoint Saturday Milan – 18 May 2013

Doing thinks the app way

12

If you want the functionality of ...

... try these approaches.

Custom Web Parts

An app for SharePoint can have remote pages that contain custom Web Parts. Another option is to expose a page from a remote web application in an app part on a SharePoint site page. The remote page can have essentially the same UI controls and functionality as a Web Part. For more information, see How to: Create app parts to deploy with apps for SharePoint.

Event receivers and Feature receivers

An app for SharePoint can contain functionally equivalent remote event receivers. For more information, see Handling events in apps for SharePoint.

Custom field (column) types

An app can deploy a new field (column) that is based on one of the existing field types. The Calculated and Computed field types are especially flexible. Another option is to present your data in a remote web page with customized controls or grids.

Custom web services built on the SharePoint Service Application Framework

You can develop your custom web services as remote services.

Application pagesAn app for SharePoint can include remote web pages that are available from every website on which the app is installed. An app can also use any of the built-in SharePoint Web Parts on site pages.

Page 13: SharePoint development evolution from classic to app

13 | SharePoint Saturday Milan – 18 May 201313 | SharePoint Saturday Milan – 18 May 2013

Doing thinks the app way Some SharePoint components are used in end-user

scenarios but do not have any equivalents in the SharePoint app model. For these you must use farm solutions. Custom site definitions   Delegate controls Custom themes Custom action groups and custom action hiding User controls (.ascx files) - No scenario actually requires

these.

Page 14: SharePoint development evolution from classic to app

14 | SharePoint Saturday Milan – 18 May 2013

Moving to the Cloud approach

Page 15: SharePoint development evolution from classic to app

15 | SharePoint Saturday Milan – 18 May 201315 | SharePoint Saturday Milan – 18 May 2013

Shift to cloud ready SharePoint Online

Use Cloud approach (app) Remote PowerShell for SharePoint

Online

On Premise Use Old school approach (wsp) as little

as possible User PowerShell for SharePoint Use Cloud ready approach (app) as

much as possible

15

Page 16: SharePoint development evolution from classic to app

16 | SharePoint Saturday Milan – 18 May 2013

App everywhere. Is it true?

Description

Page 17: SharePoint development evolution from classic to app

17 | SharePoint Saturday Milan – 18 May 201317 | SharePoint Saturday Milan – 18 May 2013

App by Chris O'Brien By default, any SharePoint artifacts provisioned (lists, web

parts, content types, site columns, master pages, content pages, other files) do not get provisioned in the site end user browses –  rather, they get created in a special “app web” on a special URL which is isolated from the original SharePoint web. This could be particularly relevant if, for example, if there needed to be some kind of aggregation or link between user content and content related to the app

Deep changes to the user site are not possible with an app – site definitions, branding, themes, most types of ribbon customization or link changes which would require a CustomAction are examples

Timer jobs are not possible within an app – within a SharePoint-hosted app, it’s difficult to see how any “scheduled processing” could ever be implemented. ….

Custom field types are not possible within an app

Page 18: SharePoint development evolution from classic to app

18 | SharePoint Saturday Milan – 18 May 201318 | SharePoint Saturday Milan – 18 May 2013

App by Peppe.Net Abbiamo bisogno di modificare fortemente SharePoint e i

suoi vari componenti? Utilizzeremo una Farm solution! Abbiamo bisogno di modificare l'aspetto grafico del

prodotto? Utilizzeremo una Farm solution! Abbiamo bisogno di interagire con dati e informazioni

presenti in siti, site collection o web application differenti? Utilizzeremo sempre una Farm solution ....

Le App sono fantastiche per lo sviluppo di applicazioni e funzionalità mirate, che non hanno dipendenze dal "mondo SharePoint esterno", che possono essere curate a fondo per poi essere fruite da differenti browser e device fisici e per cui è possibile stabilire dei permessi sull'intera funzionalità esposta e non sul contenuto

Page 19: SharePoint development evolution from classic to app

19 | SharePoint Saturday Milan – 18 May 201319 | SharePoint Saturday Milan – 18 May 2013

App in the Enterprise In a large company, it’s probably not

realistic to expect all users to install such internal apps, even if we want to make the functionality available to everyone.

In a large company, sites have to be created using templats

SharePoint Online doesn’t support features stapling or custom site definitions.  So how can an organization deploy capabilities to a group of existing sites or new sites that match specific criteria?

Page 20: SharePoint development evolution from classic to app

20 | SharePoint Saturday Milan – 18 May 2013

Provisioning

Description

Page 21: SharePoint development evolution from classic to app

21 | SharePoint Saturday Milan – 18 May 201321 | SharePoint Saturday Milan – 18 May 2013

Provisioning what? Create site collection and sub-sites Branding (master page, page layouts,

theme) Information Architecture

Site structure Security and permissions Content type Search + other service application

integration

Page 22: SharePoint development evolution from classic to app

22 | SharePoint Saturday Milan – 18 May 201322 | SharePoint Saturday Milan – 18 May 2013

Provisioning tasks Designed for administrative task → farm approach How to be cloud ready ?

App that perform configurations on the hosted site Manually activation: app needs to be opened Automatic activation: app needs to fire an event (es.

install, update) Events are not “safe” Not easily managed by the end-users (retry

experience) Monitoring is weak by the admin (no alerts)

Workflow Used to configure site collection and site

Site workflows Workflows started by app

22

Page 23: SharePoint development evolution from classic to app

23 | SharePoint Saturday Milan – 18 May 2013

Self service site provisioning

Page 24: SharePoint development evolution from classic to app

24 | SharePoint Saturday Milan – 18 May 201324 | SharePoint Saturday Milan – 18 May 2013

Provision sites with app Self-service provisioning is improved in

SharePoint 2013 by allowing an administrator to specify a custom creation form

Page 25: SharePoint development evolution from classic to app

25 | SharePoint Saturday Milan – 18 May 201325 | SharePoint Saturday Milan – 18 May 2013

Provision sites with app The app needs the ability to create sub-

sites and site collections anywhere in the tenancy, it will need FullControl permission on the entire tenancy

Page 26: SharePoint development evolution from classic to app

26 | SharePoint Saturday Milan – 18 May 2013

App stapling

Description

Page 27: SharePoint development evolution from classic to app

27 | SharePoint Saturday Milan – 18 May 201327 | SharePoint Saturday Milan – 18 May 2013

App stapling Use the options for deploying the app at “tenant scope”. This works for both on-premises deployments and

Office 365/SharePoint Online. Microsoft even provide a nice admin interface for tenant-

scope installs, which offers the following deployment options: Deployment to named site collections Deployment to all sites under a particular managed

path Deployment to all sites created from a certain site

template

27

Page 28: SharePoint development evolution from classic to app

28 | SharePoint Saturday Milan – 18 May 201328 | SharePoint Saturday Milan – 18 May 2013

App stapling - Internals When deploying apps in this way, there is a crucial detail to

be aware of – something which could either be highly-desirable or a deal-breaker. Essentially, all installed instances of the app *share* a single app web. This means any lists or libraries you provision as part of your app, are shared amongst all the webs where the app is installed. As I say, this could be exactly how you want your app to operate, or completely against it’s design.

All app instances share a single app web. The instance which is installed to the App Catalog site is

used for all instances – effectively the user is always redirected to this URL on the app domain, regardless of which site they entered the app from

Page 29: SharePoint development evolution from classic to app

29 | SharePoint Saturday Milan – 18 May 201329 | SharePoint Saturday Milan – 18 May 2013

App stapling - Considerations There are also important by-products of this:

Users and site collection administrators in sites where the app is installed cannot remove the app regardless of their permissions there This makes sense because they would effectively be

uninstalling the single instance used by everyone Individual “usages” of the app do not get reported by

Get-SPAppInstance – only the instance in the App Catalog site gets returned (N.B. applicable to on-premises SP2013 only)

Events bound to the app on installation, upgrade and delete are fired only one time in the single instance app

Page 30: SharePoint development evolution from classic to app

30 | SharePoint Saturday Milan – 18 May 2013

App self executed

Description

Page 31: SharePoint development evolution from classic to app

31 | SharePoint Saturday Milan – 18 May 201331 | SharePoint Saturday Milan – 18 May 2013

App self executed App performs some operations during install, update,

delete event. App allowed of type: cloud

Security to avoid app deletion Set permission to app in the app catalog

Readers to see and open app on the target site Contributors can install, upgrade and delete app on

the target site

31

Page 32: SharePoint development evolution from classic to app

32 | SharePoint Saturday Milan – 18 May 201332 | SharePoint Saturday Milan – 18 May 2013

App self executed Autoupdate app

On premise -> Timer-job or powershell extension SharePoint Online -> Workflow or scheduled task

How to update an app Check new version of app in the app catalog If new version is found, extract app package and then

upgrade the app to the target site collections

32

Page 33: SharePoint development evolution from classic to app

35 | SharePoint Saturday Milan – 18 May 2013

Conclusion

Page 34: SharePoint development evolution from classic to app

36 | SharePoint Saturday Milan – 18 May 201336 | SharePoint Saturday Milan – 18 May 2013

An eye on the future Rethink the application architecture Integrate, Integrate, Integrate and

Integrate Stay close to out-of-the-box means be

ready for the future (upgrade & vnext) At the end of the game, wild

customizations do not pay. Whether you like or not the future is

APPization HTML5, JS, CSS will become your best

friends

Page 35: SharePoint development evolution from classic to app

37 | SharePoint Saturday Milan – 18 May 2013

Q&A

Page 36: SharePoint development evolution from classic to app

38 | SharePoint Saturday Milan – 18 May 2013

Grazie