Getting started with SharePoint 2013 online development

Editor's Notes

• #2: Getting started with SharePoint 2010 Online developmentJeremy Thake, SharePoint MVP, will introduce SharePoint 2010 Online as an application development platform inside Office 365. The session will explain how to get started with the different approaches from web UI configurations, to SharePoint Designer 2010 customizations to full blown Visual Studio development with Sandbox Solutions. Jeremy will introduce the concepts of how Application Lifecycle Management can be introduced to this along with migrating existing applications across from on-premise. From this session you should walk away with:Using SharePoint Online 2010 as an Application Development PlatformGetting Started with SharePoint Online 2010 developmentApplication Lifecycle Management with SharePoint Online 2010 in Office 365Migrating SharePoint 2010 Apps to SharePoint Online 2010 
• #5: Using SharePoint Online 2010 as an Application Development PlatformMicrosoft launched Office 365 (O365) in June 2010, including SharePoint 2010 Online, as an update to its existing Business Productivity Online Services (BPOS) suite that offered SharePoint 2007 Online. SharePoint is a platform that presents many different workloads such as: collaboration, enterprise content management (ECM), search, communities, line-of-business (LOB) integration and business intelligence. As a rapid application development platform, it allows business owners to build business solutions without the need for development resources and other IT department interaction.SharePoint has had a major release every three years, with SharePoint 2007 being the first to be made available as a software-as-a-service offering in BPOS. It has been available on-premise since 2000, when it was affectionately known as Tahoe. It is worth noting, though, that there is functionality available on-premise that is not available in BPOS/O365.SharePoint is a web-based platform, and being hosted in the cloud provides a highly accessible platform from anywhere on the internet securely. The key benefit to a platform is that it provides a common framework for solutions to build on, rather than each solution being built by different teams using different frameworks which subsequently leads to maintenance and operational issues. From a business user perspective, it also offers a common user interface and allows co-existence of solutions and high interoperability between them. Microsoft has invested considerable effort to ensure that integration with the rest of the stack is exceptional, with strong stories in Microsoft Office client suite, Lync, Dynamics CRM, SQL, and Exchange. If your organization already has some, or all, of these products being used, it is very quick to get productivity gains for solutions due to the familiarity already existing out there in the field.SharePoint provides the ability for solutions to be built using the common framework – here are some of the areas that are leveraged:Security model – both authentication and authorization (including claims based) are heavily leveraged in solutionsLists and Libraries – the ability to add strongly typed metadata to items in a list or library with additional versioning, workflow, event receivers, alerting, and RSS feedsPublishing – a WYSIWYG interface for web pages that allows adding of Web Parts to pages to build strong mash ups between solutionsService Applications – the ability to leverage the User Profile Service (UPS) to store/retrieve user data across solutions, have a centralized taxonomy/folksonomy with the Managed Metadata service (MMS), or integrate LOB applications using Business Connectivity Services (BCS)APIs – there are various APIs available to consume including a Representational State Transfer (REST) interface for all lists and libraries, a client object model for various areas of the framework and a sandboxed server object model to reach deeper areas of the frameworkOne thing to consider is that SharePoint is not recommended for all solutions. In the field, the areas that seem to start stretching the platform’s capabilities are: highly relational data and large datasets (millions rows) due to performance implications, and wanting a “non-SharePoint” looking user interface without risking supportability issues in upgrade to the next major version.In the next article, we will discuss getting started in building a solution on SharePoint 2010 Online.
• #10: Getting Started with SharePoint Online 2010 DevelopmentAs discussed in the previous article, SharePoint is a rapid application development platform. What brings real power to the organization, however, is that there are different tiers available to build solutions:Beginner – many solutions can be built purely from the web user interface SharePoint provides by creating new sub sites, lists, and libraries as well as modifying configuration settings and content within pagesIntermediate – in addition to the web user interface, SharePoint Designer 2010 provides a rich client that further richens solutions with complex declarative workflows, declarative line-of-business integration with BCS and the ability to customize the user interface with ASP.NET, JavaScript, HTML, and CSSAdvanced – in addition to the later, more advanced development skills within Visual Studio 2010 you can build complex solutions leveraging managed code to construct event receivers, imperative workflows, custom web parts, and package these for re-use across SharePointThe benefit of both the beginner and intermediate tiers is that it can be done remotely from any personal computer with a browser and SharePoint Designer 2010 rich client, respectively. It is worth highlighting that when building solutions, they should be constructed in a development environment rather than directly into production. The primary reason for this is so that when v1.0 of the solution is in production and used by the business, you can make changes without affecting the business operation and then release v1.1 once quality assurance has occurred and a change management release window has been agreed upon.Microsoft Office 365 has no concept of a development or staging environment, only offering production; this immediately encourages the wrong practice. The easiest approach is to create a development site collection from the Office 365 administration panel and ensure that, in terms of security, it is restricted. This approach will not allow for remote debugging of managed code required by advanced tiers, but will suffice for beginner and intermediate tiers.Another cloud approach to development environments would be to use a third-party dedicated server provider to spin up a SharePoint 2010 environment. One of the major risks here is that this will be an on-premise instance and has slightly different functionality in certain scenarios. If you steer clear of the server object model and stick to the Representational State Transfer (REST), client object model, and sandboxed server object model, you should prevent the mistake of leveraging unsupported features when deploying to SharePoint 2010 Online.True on-premise options for development environments require hardware that may not be readily available or may take time to procure and provision. The options are:Install on Windows 7 workstation – will require additional software on your workstation such as SQL and some functionality will be missing, such as user profile service applicationVirtualization on workstation – leverage virtual machines on your existing workstation to give added benefit of isolation, snapshotting, cloning, and sharing VMs with your teamDedicated servers (virtual/physical) – typically the slowest route to obtaining an environment but will mean an “always on” environment accessible by all in the team and better performing than workstation environments.In the next article, we will discuss how you can introduce application lifecycle management (ALM) into SharePoint 2010 Online development processes.
• #15: Application Lifecycle Management with SharePoint Online 2010 in Office 365As discussed in the previous article, the original promotion of a v1.0 solution from development to production is relatively easy out of the box by saving the site as a template and restoring it. The problem with this, however, is that when you modify v1.0 in development to make v1.1 and are ready to promote it, you cannot use this approach because it will overwrite anything in production and therefore lose all production data. The only out-of-the-box approach to promote subsequent versions is to repeat all the steps made in development in the production environment. This in itself introduces risks, such as incorrectly repeating steps with misconfiguration or simply omitting steps that are later discovered.Some artifacts can be exported individually and imported into existing sub sites relatively easily:Copying and pasting file contents from one SharePoint Designer 2010 window to another, from one sub site to anotherExporting web parts from pages and importing them onto the target pagesExporting and importing a declarative SharePoint Designer 2010 workflow from one sub site to the otherConfiguration settings in existing sub sites, content types, lists, and list items require a manual export/import out of the box. For simple solutions, this could be a matter of minutes. However, in more complex solutions this may require too many steps and lead to downtime of the existing solution in production, potentially causing business disruption issues. A way to automate these changes from one version to another is to leverage the advanced tier of Visual Studio 2010 development of sandboxed solutions. One thing to take into account with this approach is that this will still require you to declaratively in XML, and imperatively in managed code, write the incremental changes to go from one version to the next.Sandboxed solutions are really a sub set of full trust solutions that are built on on-premise environments. Why? Certain managed code server side APIs are not available for use, such as elevated security permissions. There are two important reasons for this: First, there are security concerns that the Office 365 SharePoint 2010 Online multi-tenant environment and managed code accessing site collections not owned by the customer. Second, the managed code contained in Sandboxed solutions are executed in their own worker process and monitored for certain resource counters such as the number of exceptions thrown and CPU cycles consumed. This allows SharePoint to disable sandboxed solutions that consume more than their limit, and therefore do not affect other site collections and customers within the same SharePoint multi-tenant farm.Visual Studio 2010 SharePoint Sandbox solutions support Team Foundation Server (TFS) as well as other source control providers  for source control. One of the core tenants of application lifecycle management is continuous integration with automated builds based on source control check-ins. This immediately becomes very complex in SharePoint 2010 Online and simply cannot be done without the advanced tier. In addition to the sandboxed solutions, a strong knowledge of PowerShell is required to remotely automate these builds into environments.There are vendors that produce products that will automate this promotion of artifacts from one environment to the other for those without the appropriate resources.In the next article, we will discuss migrating solutions from SharePoint 2010 on-premise to SharePoint 2010 online. third-party providers? Server providers? Could use a really quick 2-3 word descriptor here
• #23: Application Lifecycle Management with SharePoint Online 2010 in Office 365As discussed in the previous article, the original promotion of a v1.0 solution from development to production is relatively easy out of the box by saving the site as a template and restoring it. The problem with this, however, is that when you modify v1.0 in development to make v1.1 and are ready to promote it, you cannot use this approach because it will overwrite anything in production and therefore lose all production data. The only out-of-the-box approach to promote subsequent versions is to repeat all the steps made in development in the production environment. This in itself introduces risks, such as incorrectly repeating steps with misconfiguration or simply omitting steps that are later discovered.Some artifacts can be exported individually and imported into existing sub sites relatively easily:Copying and pasting file contents from one SharePoint Designer 2010 window to another, from one sub site to anotherExporting web parts from pages and importing them onto the target pagesExporting and importing a declarative SharePoint Designer 2010 workflow from one sub site to the otherConfiguration settings in existing sub sites, content types, lists, and list items require a manual export/import out of the box. For simple solutions, this could be a matter of minutes. However, in more complex solutions this may require too many steps and lead to downtime of the existing solution in production, potentially causing business disruption issues. A way to automate these changes from one version to another is to leverage the advanced tier of Visual Studio 2010 development of sandboxed solutions. One thing to take into account with this approach is that this will still require you to declaratively in XML, and imperatively in managed code, write the incremental changes to go from one version to the next.Sandboxed solutions are really a sub set of full trust solutions that are built on on-premise environments. Why? Certain managed code server side APIs are not available for use, such as elevated security permissions. There are two important reasons for this: First, there are security concerns that the Office 365 SharePoint 2010 Online multi-tenant environment and managed code accessing site collections not owned by the customer. Second, the managed code contained in Sandboxed solutions are executed in their own worker process and monitored for certain resource counters such as the number of exceptions thrown and CPU cycles consumed. This allows SharePoint to disable sandboxed solutions that consume more than their limit, and therefore do not affect other site collections and customers within the same SharePoint multi-tenant farm.Visual Studio 2010 SharePoint Sandbox solutions support Team Foundation Server (TFS) as well as other source control providers  for source control. One of the core tenants of application lifecycle management is continuous integration with automated builds based on source control check-ins. This immediately becomes very complex in SharePoint 2010 Online and simply cannot be done without the advanced tier. In addition to the sandboxed solutions, a strong knowledge of PowerShell is required to remotely automate these builds into environments.There are vendors that produce products that will automate this promotion of artifacts from one environment to the other for those without the appropriate resources.In the next article, we will discuss migrating solutions from SharePoint 2010 on-premise to SharePoint 2010 online. third-party providers? Server providers? Could use a really quick 2-3 word descriptor here
• #24: An app uses permission requests to specify the permissions that it needsThe requests specify both the rights and scope which are neededScopes indicate where in the SharePoint hierarchy a permission request applies. SharePoint supports four different content scopes:SPSite—site collectionSPWeb—websiteSPList—listTenancy—the tenancy scope is at http://<sharepointserver>/<content>/<tenant>/There are also scopes for things like performing search queries, accessing taxonomy data, user profiles, etc.
• #25: Permission rights indicate what an app is permitted to do within a scope. SharePoint supports four rights levels for content (there are others for things like search, term store, etc.):Read-OnlyWriteManageFull ControlUnlike SharePoint user roles, these rights levels are not customizableIf an app is granted permission to a scope, the permission applies to all children of the scopeIf an app is granted perms to an SPWeb, the app is also granted perms to each SPList in the SPWeb, and all SPListItems in each list, but NOT each subweb
• #33: Migrating SharePoint 2010 On-Premise Applications to SharePoint 2010 OnlineAs discussed in the previous article, the promotion of solutions from one environment to another can prove complex. To add to this complexity, when organizations decide to move from SharePoint 2010 on-premise to SharePoint 2010 online, any full trust solution packages used in the advanced tier cannot be deployed into the multi-tenant environment. To migrate these solution packages, they need to be manually converted to a sandbox solution in Visual Studio 2010. This is as simple as changing the property in the Solution property pane, but don’t be fooled by building your solution and it compiling. It will only fail once it is deployed and executed at runtime. There is an additional CodePlex project with FXCop rules that will do this at compile time for you, as well.In some circumstances, developers can get lucky and find that they have only used functionality within the limits of sandboxed solutions. In other cases, where they have used APIs outside of these limits or are consuming too much CPU time, developers will need to start looking at approaches to work around this. I have also worked with customers that have de-scoped functionality to get around the limitations.There are a few key approaches to handling solutions that require functionality that is blocked when using sandboxed solutions:Client side code – Script blocks built within the ASPX pages can call out to external web services, which cannot be done by sandboxed managed code. The SharePoint client object model is a sub set of the server side API, consumed by JavaScript, and allows for very similar actions as what can be done via server side API.Azure Service Bus – For functions requiring complex calculations that would reach the limits of the resources measured in the sandboxed solution, organizations are moving these calculations to the Azure Service Bus.SQL Azure – In some cases, where on-premise solutions accessed SQL databases inaccessible by SharePoint 2010 online, organizations are also moving their data into the Azure cloud.Azure Web Application – In some cases, the user interface (UI) layer and business logic are completely pulled into an Azure application. Often, the data layer is left inside SharePoint lists and libraries. The UI of the application is then added to SharePoint 2010 as an IFRAME. The other issue with migrations, often with large amounts of data, is the time it takes to actually do the full migration. Sometimes the initial move of all the content into SharePoint 2010 Online does not occur within the outage window available. Organizations find themselves doing an initial migration of the bulk of the content, but then take a full outage of the production solution to do an incremental migration of the changes from when the bulk was done to present and then switch to SharePoint 2010 online solution. In this instance, third-party products are the only real viable approach.