Downloaded 45 times
Uploaded byJeremy Thake
Getting started with microsoft office 365 share point online development
This document provides an overview of developing applications for Microsoft Office 365 SharePoint Online. It discusses the application development platform and getting started options like using web parts, SharePoint Designer, and Visual Studio. It also covers sandboxed solutions, the new app model, and approaches for migrating existing customizations and applications to the Office 365 platform.
More Related Content
Similar to Getting started with microsoft office 365 share point online development
More from Jeremy Thake
![Vibe Coding vs. Spec-Driven Development [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/vibecodingvsspecdrivendevelopment-251209105622-43f455e7-thumbnail.jpg?width=640&height=640&fit=bounds)
Getting started with microsoft office 365 share point online development
- 1. Getting Started withMicrosoft Office 365 SharePoint Online Development Jeremy Thake Chief Architect Level: Intermediate @jthake #SPLive360
- 2. Jeremy Thake AvePoint Labs Author Chief Architect @jthake #SPLive360
- 3. Agenda • Application Development Platform • Getting Started • Sandboxed Solutions • App Model • Migrating Apps @jthake #SPLive360
- 4. Application Development Platform @jthake #SPLive360
- 5. Building Blocks • Authentication & Authorization • Customization & Personalization • Branding • Disaster recovery • Availability • Site collections & Sub sites @jthake #SPLive360
- 6. No more… • installing SQL • configuring IIS • deploying components to server • writing service level agreements • writing disaster recovery plans @jthake #SPLive360
- 7. List Building Blocks • Attachments • Metadata • Versioning • Views • Full API: Web services, REST, RSS… • Security • Event Receivers • Workflow • Publishing @jthake #SPLive360
- 8. What to worryabout • UI pattern consistency • Don‟t bend it the wrong way – If you question whether its right, it probably isn’t • Performance considerations • Monitoring – Resource Usage – No ULS logs, Event Viewer @jthake #SPLive360
- 9. Getting Started @jthake #SPLive360
- 10. Approaches • Web parts on pages Web UI • Site / List Settings • Branding SharePoint Designer • Business Connectivity Services • Visual Studio “Lite” NAPA • Not a web browser! Visual Studio 2010 • Debugging @jthake #SPLive360
- 11. Don’t work directlyon Production • Develop in Development environments!!! • Great for version 1.0, not so great for 1.1 whilst live users in environment – 24 hour SLA on recovering a site collection • SharePoint Designer encourages this @jthake #SPLive360
- 12. Development Environment • Must have Visual Studio where SharePoint installed for server side development • Use a “development” site collection in your Office 365 SharePoint 2010 Online environment – Client Object Model • Install SharePoint 2010 locally on Windows 7 @jthake #SPLive360
- 13. Use a virtualmachine • VMWare Workstation/Sun VirtualBox on Windows 7 • HyperV on dual boot Windows Server 2008 R2/Windows 7 • HyperV on Windows 8 RC • Steal some of IT private cloud to run one ;- ) • Azure, CloudShare, fpWeb, Rackspace @jthake #SPLive360
- 14. Visual Studio 2012 • Create Silverlight Web Parts • Publish SharePoint Solutions to Remote SharePoint Servers • Test SharePoint Performance by Using Profiling Tools • Create Sandboxed Visual Web Parts • Support for JavaScript Debugging and IntelliSense for JavaScript http://msdn.microsoft.com/en-us/library/ee290856(VS.110).aspx @jthake #SPLive360
- 15. Cloud-hosted Apps dev environment Development Machine SharePoint 2013 Azure Development env Web application App 2 App 2 Site Collection Web SQL Root Site Sites App 1 App 2 App 3 IIS Web Server App 3 App 3 App 3 Web Windows SQL Service SQL 2012 Visual Studio 2012 @jthake #SPLive360
- 16. Evolution of customizationsin SharePoint _api _vti_bin _vti_bin Declarative Application s& Workflow Events CSOM _api CSOM @jthake #SPLive360
- 17. Sandboxed solutions @jthake #SPLive360
- 18. Sandboxed Solutions • Restricted API due to multi-tenant environment • No LOB: Web Services, ATOM, ODBC • No file access • Current site collection scope only • No Page object (JavaScript reg) • Deployed via Site Collection Site Settings http://msdn.microsoft.com/en-us/library/gg615454.aspx @jthake #SPLive360
- 19. *smile* • Office 365 customizations • Faster deploys – Doesn’t require IISRESET as assemblies not in GAC • No Farm access required @jthake #SPLive360
- 20. WARNING • No “Full trust proxies” in Office 365 • Only Site Collection Admins can activate if managed code in packages • Site Collection Admins can deploy these! • Can use Silverlight to overcome some restrictions @jthake #SPLive360
- 21. TIPS • Use Sandbox Solutions (default) as can‟t use Full-Trust Solutions in SharePoint 2010 Online • Won‟t get compile time warnings on incorrect API usage, only on upload to SharePoint – Use the FxCop rules http://o365fxcoprules.codeplex.com/ @jthake #SPLive360
- 22. Web Part example • displayed data from a list • perform a SharePoint database query • the sandbox 20 database queries = 1 resource point • is turned displayed 20 times off • site collection would have used 1 until daily resource point of 300 points available • reset could be displayed 6,000 times in a 24 hour period @jthake #SPLive360
- 23. App Model @jthake #SPLive360
- 24. App Model scenarios SharePoint SharePoint Azure Web application App 2 App 2 Site Collection Website SQL Root Site s App 1 App 2 App 3 SP Auto Provider IIS Web Server Hosted Hosted Hosted App 3 App 3 Web SQL Sub Site App 3 Provider Hosted @jthake #SPLive360
- 25. App Versioning SharePoint SharePoint Azure Web application App 2 App 2 Site Collection Website SQL Root Site s V1.1 V2.0 V1.0 V1.1 V1.0 V2.0 App 1 App 2 App 3 V1.0 V1.0 V1.0 IIS Web Server App 3 App 3 App 3 Web Web SQL V1.0 V1.1 V1.1 Sub Site App 3 V1.0 V1.1 @jthake #SPLive360
- 26. Application IFRAME @jthake #SPLive360
- 27. OAuth Authentication SharePoint SharePoint Azure Web application App 2 App 2 Site Collection Website SQL Root Site s App 1 App 2 App 3 IIS Web Server App 3 App 3 Web SQL Site Collection Root Site App 3 @jthake #SPLive360
- 28. Deployment Model Office 365 Permissions On-Prem Permissions SharePoint Sandbox YES YES Full Trust NO YES SharePoint Hosted YES OAuth via ACS YES High-Trust (S2S) Remote Provider Hosted YES OAuth via ACS YES High-Trust (S2S) • Developer hosts app • Could be in Azure Auto-Hosted YES OAuth via ACS NO • App can deploy website and SQL Azure db • Hosted in Office 365 Azure Cloud @jthake #SPLive360
- 29. Compare customization models Full trust WSP Sandboxed WSP Apps Where does server-side code Farm (User Code Farm (w3wp.exe) Anywhere but farm run? Service) Scalable Based on farm Limited Highly Who installs and removes Farm admin Site collection admin Users Supported in SP2013 Yes Yes Yes SharePoint Online compatible No Yes Yes Auto-hosting compatible No No Yes Requires local farm for Yes Yes No developers Remote deployment and No No Yes debugging from Visual Studio @jthake #SPLive360
- 30. Migrating Apps @jthake #SPLive360
- 31. Web UI • Side by side windows – Site Settings – List Settings – Page content • Windows Explorer – Document Content @jthake #SPLive360
- 32. SharePoint Designer • Side by side across windows – Business Connectivity Services – Web Parts – Content Types • Copy & Paste across windows – Master Pages – Page Layouts – Workflows (no custom activities) @jthake #SPLive360
- 33. Sandboxed Solutions • Will work in SharePoint 2010 Online just like Standard or Enterprise @jthake #SPLive360
- 34. Full-Trust Solutions • APIs used • Switch to “Sandboxed” and just try it • Run FxCop against it • Change assembly target for Visual Studio 2010 @jthake #SPLive360
- 35. Custom crap! • Remember, no access to servers AT ALL • So everything must be in Solution Package • No manual deployment of files to file server • We‟ve been teaching you this since „06 @jthake #SPLive360
- 36. 3rd Party Tools • Graphical User Interface to move Site Collection artifacts and content • Lots of players – AvePoint – Axceler – MetaVis – MetaLogix @jthake #SPLive360
- 37. References • Sandboxed Solutions • App Model • Office 365 Developer Hub • NothingButSharePoint.com • Critical Path setup guide – Configure apps in your dev environment • SharePoint 2013 Developer site sign up @jthake #SPLive360
- 38. Q&A Jeremy Thake www.NothingButSharePoint.com THU 09:15 Acing Application Lifecycle Management jeremy.thake@avepoint.com @jthake www.linkedin.com/in/jeremythake @jthake #SPLive360
Editor's Notes
- #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.
- #17 Isn’t there a CSOM missing in 2013
- #18 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 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.
- #31 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.