2013 Cloud App Model

1. 2013 Cloud App Model Presenter: Al Carroll May 15th 2013

2. Introductions CTN Dynamic is a Custom Support Organization. CTN Dynamic provides support for Microsoft SharePoint, Dynamics CRM, and GP platforms, to companies of all sizes. Our team of Level 3 Application Support Architects provides each of our customers with dedicated support of their specific environment with measurable SLAs. http://www.ctndynamic.com • Audience Poll Time Ben Carroll SharePoint Architect (and nice guy) Email: bcarroll@ctndynamic.com or BenIsAGreatGuy@gmail.com LinkedIn: www.linkedin.com/pub/ben-carroll/5/941/937/ (I would love feedback and questions/discussion via email)

3. Agenda Overview Where Apps fit in the SharePoint 2013 Customization Pathways? Apps Architecture Planning for Apps Apps Development App Environment Configuration App Security Data Storage and Access with Apps Monitoring Apps Demo Questions

4. Overview It’s all about the Apps (..almost)

5. What is the Cloud? IT as a service IaaS, PaaS, SaaS

6. Why your bosses and clients might care When does it make sense for an organization to consider cloud computing alternatives to in-house IT services? CIOS’ - Is it faster? Can I manage it? Can I save money? CMO or CFO – can I side-step around IT when I need to? Can I save Cloud is a Business Enabler

7. Why you (developer) should care emerging force in software development, almost as big the Internet was in the mid-1990s.. Software delivery becomes easier than ever before with the power of the cloud at your back. interconnected and integrated applications. In the cloud, the integration story is usually clearer and easier than on premise. more is better for available computing power. ignore cloud computing at your peril

8. SharePoint 2013 Apps Overview Apps are secure, with permissions independent of user permissions Lower risk than farm and sandbox solutions since app code never runs in a SharePoint Host Environment Easy to deploy, monitor, find, upgrade, and retire. Site owners can discover and download apps for SharePoint from a public SharePoint Store or from their organization's internal App Catalog and install them on their SharePoint sites. Not a complete replacement SharePoint features and solution packages but provide pathways for a majority of scenarios where we would've used the former. Simple lifecycle – Apps can be installed, upgraded, and uninstalled by site owners. Integrate with Office Apps Not available in SharePoint Foundation 2013

9. App User Experiences • Immersive Apps • Part Apps (App Parts) • Custom Action Apps • Branding and UI Integration • App Templates: pull CSS from hosting SharePoint Environment when creating Visual Studio Apps • Chrome Control – JavaScript based control which allows for consumption of styling of the parent AppWeb

10. The App Store Microsoft hosts and controls a public SharePoint Store. Developers can publish and sell their custom apps. End users and IT professionals can purchase apps for personal or organizational use. This SharePoint Store will manage discovery, purchase, upgrades, updates, and dispute resolution. Company-developed and approved apps can also be deployed to an organization's internal App Catalog hosted on SharePoint 2013 or SharePoint Online

11. Advantages of Apps • Advantages to Users • Apps are available through theApp Catalog or App Store • Provide easiest discovery & installation without intervention of SharePoint Admins • Apps provide upgrade support • Advantages to Administrators • Less risk than Sandboxed or Farm Solutions since they execute outside the server. • Apps are Configurable by Administrators allowing them to restrict usage of Apps • Scale App Components rather than SharePoint when appropriate • Advantages to Developers • Web Programming skills are reusable in creating Apps • Common web standards of HTML, JavaScript, CSS can be used to develop Apps • Visual Studio 2012 supports App project templates • Like Sandboxed Solutions, developers can access SharePoint objects inside Apps • Opportunity to create & publish Apps to SharePoint store

12. How are apps for SharePoint and SharePoint sites related? Site owners can add apps for SharePoint to their sites. App containing SharePoint components, store those components in a subweb of the site that is automatically created upon app installation. Apps have their own, isolated URLs, separate from the URL for the site containing the app. If the app is a Provider-hosted then components are stored in the in the cloud.

13. Where are Apps hosted? • Provider-hosted • HTML and JavaScript hosted by SharePoint Environment of Provider • Hosted in the cloud (Windows Azure auto-hosted) • Hosted in a SharePoint environment • Several combinations of these options.

14. SaaS Licensing for SharePoint Because of default external sharing, site owners can easily share sites and content with external users without requiring internal Active Directory accounts.. SharePoint Online's social features have been spread throughout the product, including activity tracking via the personal Newsfeed, file sharing through SharePoint's SkyDrive Pro, and a centralized favorite Sites page. Optional integration of Exchange Online enables SharePoint Online to centralize task assignments across sites and even Outlook tasks that would otherwise never hit SharePoint. SharePoint Online for Enterprise also supports Excel services-based business intelligence, a new workflow engine based on Windows Workflow Foundation 4 that supports loops and a number of new actions in SharePoint Designer 2013, and enhanced video management capabilities complete with search integrations.

15. Azure Workflows In addition to a new development model for SharePoint app functionality, SharePoint 2013 introduces a new model for developing workflows. SharePoint 2013 offers the .NET 4.5 Windows Workflow Foundation as a new approach to enacting custom logic inside of a SharePoint site. The .NET 4.5 Workflows are hosted outside of SharePoint on Windows Azure Workflow service. Office 365 uses this new Azure service automatically, not requiring developers to acquire a Windows Azure account. The integrations in Office 365 are provided automatically. The benefits of including .NET 4.5 Workflows include a number of new workflow capabilities such as stages and loops, the ability to invoke web services, and, of course, the scalability and performance benefits to run on the Azure platform.  New in SharePoint 2013 is integration with Project2013, complete with Project-based workflows. As developers and site owners approach creating workflows for SharePoint 2013, they have two choices of platforms: the new platform leveraging Windows Azure Workflow Services and .NET 4.5 or the old SharePoint 2010 platform. As with other SharePoint 2010 customizations, the entire 2010 workflow platform was brought forward into SharePoint 2013 so that no existing investments need change. Workflows can be built with the Office SharePoint Designer or with Visual Studio 2012. In either case, workflows are declarative-only constructs that rely on XAML files to define and frame the execution of the logic. The implication of this change is that workflows are no longer compiled but are instead interpreted. This interpretive approach is what enables workflows to be executed outside of the SharePoint run time and offers opportunities for numerous visualization and editor tools.

16. What is the URL for an app for SharePoint? Apps by default are deployed to their own web site in an isolated domain name, separate from your farm, thus are unable to affect your SharePoint Sites. This prevents cross-site scripting between the apps and sites and unauthorized access to data. Each app install has a unique URL in your SharePoint environment. You determine the template for that URL by specifying a domain name and an app prefix, and then app URLs are automatically generated based on that template. Paths for the apps are based on the URL for the site where they are installed. Upon app installation, a subweb of that site is created to host app content. The subweb for the app is hierarchically below the site collection, but has an isolated unique host header instead of being under the site's URL.

17. Impacts of apps for SharePoint Supporting apps for SharePoint in your environment does require configuration changes to your environment. There are two main considerations: • Requirements for supporting apps for SharePoint   • Subscription Settings and App Management service applications must be running. • A DNS domain to contain the URLs for apps for SharePoint in your environment must be created. • Plan for capacity  Each app for SharePoint creates a subweb under the site on which it is installed with its own URL. Environments with lots of apps have lots of subwebs. Keep this in mind during capacity planning

18. Where Apps fit in the SharePoint 2013 Customization Pathways?

19. Custom Development Directions Farm Solutions Sandbox Solutions Apps

20. Apps compared to Sandbox Solutions • Microsoft wants you to use App Model to most places where you would’ve used Sandbox Solutions. (Pssst… Hey buddy…. sandboxes are deprecated going forward) • App solutions can be used to deploy declarative SharePoint Objects like lists • Apps can’t do everything that farm and sandbox solutions can, but there are workarounds for many scenarios. (more on that in another slide..) • You will have to use solutions in some cases. Content type or list template available to an entire site collection would require a sandbox solution • Apps can include SharePoint Solutions but NOT server side code. • Shiny new things in Apps that aren’t in Sandbox Solutions • App Marketplace • Oauth support

21. When to use Apps vs. Farm Solutions There is overlap between the two due to the evolution of SharePoint Apps • use one of the SharePoint client object models or REST endpoints to access SharePoint content and components. These client APIs are designed for end user functionality, (site owners, site members, and tenant admins). • Apps can be installed by tenant and site collection administrators. • Since SharePoint Apps are website scoped and cannot include custom code that runs on the SharePoint server, it cannot call administrative APIs. • In general use apps for end users functionality and farm solutions for administrator functionality. Farm solutions installed by farm admins with farm, web application, or site-collection scope, and can access the server object model and run code on the SharePoint Server. Server object model has APIs enabling SharePoint management, configuration, and security, including extending Central Administration, backups, timer jobs, and PowerShell. allows manipulation of SharePoint components and end user features, but in SP2013 the design intention is to use apps unless a single solution requires both administrative and end user functionality.

22. App Approaches to Pre-App Scenarios Custom server side code running on the SharePoint servers is not allowed in SharePoint 2013 Apps, which at first glance may appear to be a big limitation BUT we can just move business logic to the client or the cloud and accomplish MOST of what you would’ve done with server side code. Use SharePoint’s REST/OData service for accessing SharePoint lists and data. Access SharePoint data remotely via JavaScript, .Net Client Object Model, or Silverlight OM. Where you would’ve created web parts in SP2010 –SharePoint apps can include remote pages with custom Web Parts or surface a page from a remote web application in an app part on a SharePoint site page. The remote page will have the same look and feel as a Web Part. An app for SharePoint can contain remote event receivers that provide the same functionality as Event Receivers and Feature Receivers. Custom web services can be created as remote services. Apps can include remote web pages that can use built in SharePoint web parts. These pages are available from every website where the app is installed and function like Application Pages.

23. Apps Architecture

24. Tenancies and App Scope.. Tenancy-scoped • App installed in app catalog site • App available to multiple host webs • Host webs access one app instance • Centralized app management • Typical farms do not have explicitly created tenancies. On-premise farms can be configured with a farm-wide tenancy default. • Apps that contain a custom action for the ribbon or app parts can’t be batch installed. Custom actions that are deployed as menu items are allowed. Site-Scoped (Web Scoped) • App installed in specific site • App launched from same site • Site is called Host Web

25. Hosting Azure Auto-hosted Appsinclude a Windows Azure Web site, and possibly a SQL Azure DB automatically provisioned transparent to end user when an app is installed. Azure Web Sites infrastructure manages isolation of tenancies. You don’t have access to all Azure services like Media Services or Service Bus As with provider-hosted apps, auto-hosted apps can have SharePoint components stored in the optional app web too. Cloud hosted apps include at least once component that is hosted outside of the SharePoint farm, but they may also include SharePoint-hosted components. We break this down into Auto-hosted and Provider-hosted Provider-hosted (developer hosted)appsare hosted by the provider /developer, or even on your own separate hardware (this could be in the cloud).  Data storage , business logic, and account isolation is up to the provider or developer, Apps can have SharePoint components too, stored in an optional app web hosted in the SharePoint farm.  Provider-hosted apps provide lots of flexibility, for example being able to use any platform and programming language for your application – even non-Microsoft. SharePoint-hosted–Apps include only SharePoint components and logic that runs on the client. There are no external components and all components of the are contained within a special App Web.  The app is installed on an existing site, but it actually runs from and stores all its data within this App web, which is a sub site of the site where the App is installed. No server side code is allowed for SharePoint-hosted apps, only JavaScript calls between the client machine and farm.

26. App Webs, Host Webs, Features, and SP Components in Apps Host Web is the website where an app for SharePoint is installed. However, the significant parts of the app for SharePoint, whether they are SharePoint components or external components, are not deployed to the host web. External parts are deployed to external servers or cloud accounts. App Web is a special SharePoint Site where an App’s SharePoint components are deployed and has its own domain. A limited set of UI elements allow users access to the app's other components and are deployed to the host web as a Host Web Feature. Host Web Features are in the root app package’s XML Hierarchy instead of inside a .wsp file. Components deployed to the app web are in Features within a .wsp file. Both types of Features must have Web scope. Only these two types are allowed. Most SharePoint component that don’t include server side code running on SharePoint servers can be included in an app and deployed to the app web.

27. App Packages An app for SharePoint package is essentially cab file with an ".app" extension, containing an app manifest. App Manifests set app properties and provide SharePoint with installation instructions. App Packages meet the Open Packaging Conventions (OPC) standard. You can open the file by adding a ".zip" extension on the filename and then opening it in Windows Explorer or with winzip.

28. App Permissions Apps that use an App web, the App will have full control rights to the App web, so it will only need to request and have permissions assigned to resources in the Host web or other locations outside the App web. Apps use permission requests to specify the permissions that are needed at a particular scope.  There are different scopes that can be specified for content and in addition to these, there are also scopes for items such as performing search queries, accessing taxonomy data, and microfeed activities. App permission rights indicate the activities that an app is permitted to do within the requested scope which are also detailed in the article referenced above. Unlike SharePoint user roles, these rights levels are not customizable. Users installing apps must have full permissions on the Host web that an App is requesting. On installation the user will be notified as to what permissions the App requires. Selective delegation and authorization Neither users launching an app, nor resource owners granting an app permission to access resources, have to give an app their username or password. SharePoint 2013 use OAuth so users and resource owners to grant only the specific permissions that the app requests. Cross-domain access: An app for SharePoint that includes a remote web application that uses JavaScript for its data access logic can use a JavaScript cross domain library to get authorized access to SharePoint data within the tenancy where the app is installed. 

29. Service Applications • Two service applications required for apps • App Management Service • Site Subscription Management Service • These must be created in on-premise farms for apps to work

30. Planning for Apps

31. DNS and SSL Important for Apps More in the configuration section

32. Plan The App Catalog & Store The SharePoint Store is accessible to the general public. On Premise Farm Admins can configure whether users can purchase from the store. App Catalog - If you allow apps, you can configure a special site that contains the apps for SharePoint that site owners can install. Farms can support multiple App Catalogs, one per web application. To configure a web application’s App Catalog, you supply names of the site collection admins who will have approval rights. The admins can then upload apps into the AppCat. The App Catalog can be accessed from a link in Central Administration or directly by using the URL.

33. Plan Monitoring Apps • Farm Admins can monitor apps usage and errors by adding apps to the Monitor Apps page in SharePoint on-premises. • The maximum number of apps that can be monitored on the Monitor Apps page is limited to 100. • The Monitor Apps page requires search analytics and usage file import timer jobs to be running: • ECM analytics timer job name: Usage Analytics timer job for Search Service • Usage DB timer job name: Microsoft SharePoint Foundation Usage Data Import

34. Plan for app licenses SharePoint 2013 does not enforce app licenses. Developers who build apps must add code that retrieves license information and then addresses users appropriately. SharePoint 2013 provides the storage and together with SharePoint Store web services the app license renewal. SharePoint Store handles payments for the licenses, issues the correct licenses, and provides the process to verify license integrity. Note that licensing only works for apps that are distributed through the SharePoint Store. Apps that you purchase from another source and apps that you develop internally must implement their own licensing mechanisms. SharePoint 2013 supports the following app licenses formats:

35. Plan for App Permissions App permission request App permission rights • Read • Write • Manage • Full control • Tenancy • SPSite • SPWeb • SPList App Permissions manage app’s ability to access and use internal SP2013 resources and perform tasks for users. SharePoint 2013 uses the Windows Azure Access Control Service (ACS) to issue time- and scope-limited access tokens for apps. In SharePoint, ACS is the app identity provider. App Authentication verifies a claim that an app makes and asserts that the app can act on behalf of an authenticated SharePoint 2013 user. App Authorization verifies that an authenticated app has permission to access a specified resource and perform a defined action. Admins can allow a SharePoint 2013 site owner, or user with elevated permissions, to purchase and install an app that a defined set of internal SP2013 users can access.

36. App permission request scopes • SharePoint 2013 apps use app permission request scopes and permission requests to specify the level at which the app is intended to run, and the permission level that is assigned to the app. • SharePoint 2013 supports the following permission request scopes: • SPSite Defines the app permission request scope as a SharePoint 2013 site collection. • SPWeb Defines the app permission request scope as a SharePoint 2013 web site. • SPList Defines the app permission request scope as a SharePoint 2013 list. • Tenancy Defines the app permission request scope as a SharePoint 2013 tenancy.

37. App Permission Inheritance Apps follow familiar SharePoint Permissions Inheritance. If an app is granted permission to one scope, the permission also applies to the children of that scope. If an app can access a Site then it can access children of the site such as its lists and libraries. Since Apps don’t know the topology of site collections from which they request permissions, the scopes are expressed as a type and URI rather than as the URL of a specific instance. Content database related permissions are organized under this URI: http://sharepoint/content.

38. App authorization policies SharePoint 2013 provides the following app authorization policies: User and app policy authorization succeeds if both the current user and the app have permissions to perform the actions that the app is attempting. App-only policy  authorization succeeds if app has sufficient permissions, regardless of user permissions. This is required when the app is not acting on behalf of a user. User-only policy authorization succeeds if the user has sufficient permissions to perform the action that the app is designed to perform. The user-only policy is required when a user is accessing their own resources..

39. App Development Environments and Deployment

40. SharePoint 2013 Developer Tools Napa Visual Studio 2012 SharePoint 2013 Designer

41. Napa - Not just a tasty vegetable.. Essentially a cloud or browser IDE and simplified browser version of Visual Studio Office 365 Developer Sites have unlimited license One way “upsizing” to Visual Studio 2012 Does not support code behinds Client side code only

42. SP 2013 Deployment Options • On-Premise • Installed on your hardware • Access to all of SharePoint’s features • Hosted • Installed 100% in the cloud usually on Office 365 • Feature set is limited • Hybrid

43. Languages and Environments for Apps Dev • Languages • Client side JavaScript for SP-Hosted Apps • C# and VB.NET for Provider or Autohosted Apps • Local Development Environments • For SharePoint Hosted: Napa within Office 365 • For Provider or Autohosted: Visual Studio 2012, Office, SharePoint Designer • A setup guide for development environments • http://blogs.technet.com/b/wbaer/archive/2012/10/10/setting-up-a-sharepoint-2013-development-environment-101.aspx

44. Distribute with App Packages • Apps distributed using app packages • Package is a .zip file with .app extension • Built according to Open Package Convention (OPC) Standard • Same format used for Office Apps • Must contain AppManifest.xml • Package contains inner WSP for app web • Elements deployed to app web using solution package • Solution package built into app package as inner WSP • Cloud-hosted apps will not have an inner WSP unless they are implemented to create an app web • Visual Studio then generates the needed files to publish an app for SharePoint. Developers can find your deployment package in the app.publish\version folder of your projects output folder. • The folder will contain a single .app file for the application • Cloud based apps will also have any other files required for the app. • Autohosted and provider hosted apps will include files that need to be published in the host web application.

45. App Packaging and Deployment App manifest (.xml) or .app package Developer Document Sharing Office Store or App Catalog Web Page Consumers & Corporate Users Web Server (Internet or Intranet)

46. Packaging for Host Web and Autohosted Apps • Host web feature elements added at top level • Elements.xml file for each app part, custom action, and host web feature • Visual Studio adds GUID to file names • Autohosted apps packaged with extra resources • Office 365 requires resources to deploy remote webs be built in the app package as a Web Deploy Package (.web.zip) • Office 365 requires resources to create SQL Azure DB within app package as Data Tier Application Package (.dacpac)

47. Registering App Dependencies • If your app is dependent on a SharePoint capability that’s unavailable and cannot be made available on the app web, then it won’t work. • Developers can ensure that your app is not installed where the requisite services and Features are not available by registering the dependencies of the app in app manifest. The installation infrastructure for apps for SharePoint checks for prerequisites and will block app installation if any are not available. • For services, such as Excel, Access, or Visio services, the infrastructure will verify that the service is installed and licensed. • For Features, such as a Task list, the infrastructure will verify that the Feature is deployed and activated or activatable with Web Scope on the App Web • Implicitly register dependencies with permission requests in the AppPermissionRequests section of the app manifest. • Explicitly register dependencies with AppPrerequisites when your app has a dependency that is not implied by its permission requests, you register each dependency with an AppPrerequisite element in the app manifest. There are three attributes in this element; Type, ID, and an optional MinimumVersion. • If your developers forgot to do this or are unaware then this should be one of the initial places you point them when they complain that you have the environment configured incorrectly. Then make them buy you lunch.

48. Register autohosted components • AutoProvisioning is a type of app prerequisite used only with autohosted apps. It registers components of the app that need to be autohosted. When prerequisite type is AutoProvisioning, the ID attribute is not a GUID. Instead, it is one of the following: • “RemoteWebHost” (To register a Windows Azure Web Site.) • “Database” (To register a SQL Azure.) • “Autohosted app that include Windows Azure Web Site and a SQL Azure database, get a separate AppPrerequisite element for each respectively. The following markup registers both: • <AppPrerequisites> <AppPrerequisite Type=”AutoProvisioning” ID=”RemoteWebHost” /> <AppPrerequisite Type=”AutoProvisioning” ID=”Database” /> </ AppPrerequisites>” --MSDN

49. Update Your App • The App framework in SharePoint 2013 enables preservation of the app’s data and roll back if an update fails. • To update apps, developers use the same Product ID in the app manifest that was used for the original deployment. The version number should be greater than the version currently deployed. • Once an app is updated, a notice that an update is available appears next to the app’s listing in the Site Contents page of every website where the app is installed. • SharePoint’s Upgrade Actions: • Prompt the user to approve any changes in the permissions requested by the app. • Makes the app temporarily unavailable to users while the app is updating. • If the app is autohosted and includes a SQL Azure database, the update process will use the Data-Tier Application Package (DAC) functionality of SQL Server to determine whether the update changes the schema of any SQL Azure databases. • It is not possible for SharePoint 2013 to make every kind of schema change. If you have schema changes in your app, it might be necessary to include that logic in one of four places • In a Data Script inside the app package. • In a PostDeployment script in the DACPAC that is executed as part of the DAC upgrade. • In the PostUpdate web service , which you would create and register in the app manifest. • In the first run after update logic of the app itself. • If the app is provider-hosted, the developer provides the update logic for all of the non-SharePoint components so that a rollback can take place if the update installs.

50. App Environment Configuration