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 worry about
• 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
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 directly on 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 virtual machine
• 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 customizations in
SharePoint
_api
_vti_bin _vti_bin
Declarative
Application
s&
Workflow
Events
CSOM _api
CSOM
@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
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
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
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
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.
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.
Isn’t there a CSOM missing in 2013
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
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.
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.