This chapter explores Microsoft SharePoint 2013 and what it offers to developers who are creating real-world business solutions. To begin, you will focus on the main features and architecture of SharePoint, as well as the rich set of capabilities the platform provides. Next, you will compare the various SharePoint editions. Finally, you will explore the available developer tools. If you already know SharePoint 2013 or have worked with it, you can probably skip this chapter; however, if you haven’t yet acquired SharePoint at all, or if you are working on previous versions of SharePoint, such as SharePoint 2007 or SharePoint 2010, you should continue on with the tour.
Microsoft often defines SharePoint as a business collaboration platform that makes it easier for people to work together. As a software developer, I prefer to define it as a platform with a rich framework for developing business solutions. From a developer’s perspective, SharePoint is simply a rich set of tools, classes, libraries, controls, and so on, that are useful for building business solutions focused on collaboration, content management, social networking, content searches, and more.
Many people think of SharePoint as a platform that’s ready to use for building websites—usually for intranet or extranet scenarios. That’s true, but it’s less than half the story! Certainly, SharePoint is a platform for building websites, and of course, it can target intranet and extranet sites. But it is much more, as well; you can use it to build any kind of web solution, including Internet publishing sites, by taking advantage of its well-defined and ready-to-use set of tools, based on a secure, scalable, and maintainable architecture. You can think of SharePoint as a superset of Microsoft ASP.NET, with a broad set of services that can speed up the development of web-based collaborative solutions.
You should use SharePoint as a shared connection point between users, customers, and whoever else uses your websites and the applications they utilize. The basic idea of SharePoint is to share content, applications, and data to improve collaboration and provide a unique user experience.
SharePoint itself is primarily a container of content and apps. Content is organized in lists, and each list is made up of items. A list can consist of simple items with custom metadata properties called fields. Lists can also be libraries of documents, which are a particular kind of item that correspond to document files. Almost always when you develop a SharePoint solution, you manage lists and items. In Chapter 2 you will learn more about the architecture of data management in SharePoint 2013.
Microsoft grouped the features and services provided by SharePoint 2013 into five main categories of benefits: Share, Organize, Discover, Build, and Manage. Figure 1-1 shows these benefits, and the sections that follow provide a brief description of each.
SharePoint 2013 enables you to share ideas and content with others. For example, you can use SharePoint for storing and sharing documents, contacts, and tasks; organizing meetings; managing business processes; and more. When you share something with SharePoint, you can also put it in the social network of your colleagues, customers, partners, and contacts in general, regardless of whether they are on your corporate network, on Facebook, on Twitter, or elsewhere. Through SharePoint, people can discover what you shared, as well as share contents with you. Using the new social features of SharePoint 2013, you can keep track of what your colleagues are working on.
With SharePoint 2013 and the new Microsoft Office 2013, you can publish documents and content from any Office application, sharing them with people inside or outside your organization. You can take advantage of these capabilities from your desktop computer as well as from any Internet-capable mobile device, such as Microsoft Surface and other tablets running Microsoft Windows 8 or RT, as well as smartphones based on the Windows Phone operating system or devices based on iOS.
When you share content through SharePoint, you can update your activity feed in order to make people aware of what you are doing, keeping in touch with your colleagues wherever you are, with any kind of device.
Through SharePoint 2013, you can organize your projects and tasks, and even integrate SharePoint with Microsoft Outlook and Microsoft Project to keep your projects on track. The product will help you manage tasks, as well as their status and due dates. You will be able to keep your team connected, through specific team sites, which enable you and others to track meetings, share documents, store emails, and do whatever else is useful for your team collaboration.
The new SkyDrive Pro feature provided by SharePoint 2013, which supersedes SharePoint Workspace, allows you and your colleagues to sync all the shared files to your desktop, as well as to your tablet, with Windows 8. This way, the content will always be with you, even when you are offline, traveling, or working at home. Upon connection with the network, any files you worked on offline will be automatically synchronized with their online counterparts.
Since it was first introduced, one of stand-out features of SharePoint has been its search engine. Having a platform for storing, sharing, and organizing content would be useless without the capability to discover and retrieve it. With SharePoint 2013, you can search for content via a professional search engine, which can be customized for your needs.
With SharePoint 2010, Microsoft introduced an improved and more accurate relevance engine that was based on usage and history. Moreover, it included the FAST for SharePoint edition for supporting large-scale search scenarios, together with professional search-oriented features. Now, the FAST for SharePoint engine is no longer a separate product, and all of its main features are included in the standard SharePoint 2013 search engine. In addition, the SharePoint 2013 search engine has the ability to suggest more relevant results and provide recommendations on people and documents to follow. The search engine is now people-centric and social-centric, enabling you to find people and connect with them, based on their interests, projects they contributed to, and documents they worked on.
You can use all the content, search results, people, and insights to create reports, scorecards, dashboards, and whatever else is helpful for providing meaningful data. Microsoft Excel 2013, Excel Services, PowerPivot, and Power View for SharePoint can assist you in this task as well.
Given all these capabilities, you can consider SharePoint 2013 a solid platform for building data and content-based, search-driven applications, oriented toward social networking and collaboration.
One of the most exciting new features of SharePoint 2013 is its apps-extensibility model. Thanks to this new feature, you can develop custom apps for Office 2013 and SharePoint 2013, using the power of the cloud. You can design everything from business apps for the marketplace at large to a corporate catalog targeting your employees.
Developing a custom app is as simple as combining the apps-extensibility model with such well-known technologies and protocols as JavaScript, HTML, OAuth, and the versatility of the cloud. If you prefer, of course, you can also host your custom apps on-premises, but hosting an app in the cloud provides you with a more scalable infrastructure ready to grow with your business. For an in-depth discussion of creating custom apps, see Part III
Nowadays, a key aspect of an IT solution is management, both from a tooling perspective and from the viewpoint of budget and costs reduction. SharePoint 2013 gives you a mature, maintainable, and manageable environment, which can be hosted on-premises as well as in the cloud, using Microsoft Office 365. You can also keep some of your services and content on-premises while deploying others on Office 365, within a hybrid infrastructure.
The new capabilities of Office 365 reduce the time to market for your solutions, allowing you to concentrate your resources and time on the project, the contents, and the custom features, rather than on the infrastructure under the cover.
Many of the solutions in this book are suitable both for on-premises and cloud scenarios, thanks to the common infrastructure behind the scenes.
To give you a better understanding of what SharePoint is and how to best use its features, this section takes a brief tour through the product and provides introductions to a few of its most useful features and capabilities.
The target audience for this book consists of SharePoint developers, not IT professionals. Therefore, the book does not cover administrative tasks, and it does not provide instructions on how to set up SharePoint from scratch. Nevertheless, as soon as you install a SharePoint server farm, you are presented with an administrative console called SharePoint Central Administration (SPCA) with which you manage the entire farm.
More Info
To learn how to deploy and administer a SharePoint farm, read Microsoft SharePoint 2013 Administrator’s Companion, by Brian Alderman (Microsoft Press, 2013).
SPCA is a website based on the SharePoint engine; it’s designed to administer and monitor a SharePoint server farm. When you deploy a new farm, by default the first server takes the role of SPCA host. Nevertheless, in a well-defined SharePoint server farm, you should deploy at least two servers hosting SPCA, for better availability and business continuity of the farm. Using SPCA, you can configure servers and servers’ roles, define farm topology, and create new web applications and site collections.
Because SPCA is an actual SharePoint site, you can use everything you will learn in this book to customize this site, too. Thus, you can build solutions to extend the SharePoint administrative interface. However, keep in mind that because SPCA is an administrative site responsible for the whole farm, you should avoid using it as a development or test site.
The following list describes the main areas of SPCA:
Application Management Here, you can manage existing web applications, as well as create new web applications, site collections, and content databases. You will learn more about these topics later in this chapter and in Chapter 2.
Monitoring From this area, you have access to a set of tools for monitoring the farm, checking for issues, and solving problems.
Security Here, you can manage administrative accounts and services’ accounts of the farm, and configure all the security-related features.
General Application Settings This is the area where you manage general settings, such as site directory and search engine settings, content deployment features, form services, and more.
System Settings From this area, you can manage servers in the farm, the farm topology, services on servers, and farm customization features.
Backup and Restore This area provides access to all the tools for managing and handling disaster recovery tasks.
Upgrade and Migration Here, you can manage upgrade and patching tasks.
Apps This area provides access to the app configuration and management tools. You can configure and monitor installed apps and apps licenses, as well as your corporate catalog of apps.
Configuration Wizards This area provides a wizard to configure the farm from scratch.
Note
You should consider using the configuration wizards very carefully, and in most cases you should avoid using them. In fact, a real SharePoint farm should never be installed using a wizard. On the contrary, you or the IT professionals you work with should carefully design the farm, assign roles to the servers, determine the services to run, and in general think about and model whatever else is needed to make your SharePoint farm work properly.
Figure 1-2 shows the SPCA home page. Note the status bar at the top of the screen, which in Figure 1-2 highlights some issues regarding the farm’s current configuration that were detected by the SharePoint Health Analyzer service. The SharePoint Health Analyzer is a very useful tool that monitors the status of the farm, helping to maintain it at the optimum service level.
As with many other server products from Microsoft, SharePoint can be managed using Windows PowerShell and scripting. SPCA is a good option for managing a SharePoint farm through a set of visual tools and a web browser. However, having a text-based scripting engine to query, manage, configure, and even install a SharePoint farm from scratch is a fundamental aid for IT professionals. In SharePoint 2013, everything you can do with SPCA can also be done using some PowerShell scripts. Moreover, PowerShell enables additional controls that are not available from SPCA.
The power of having a scripting engine for managing almost every aspect of a SharePoint farm is enormous and unpredictable. For example, you can define a PowerShell script to deploy a farm from scratch, or you can use a script to add a server to an already existing farm. You can create and configure web applications, sites, and services using a script. Moreover, you can create scripts to configure the topology of your farms. All these scripts become extremely useful and powerful whenever you need to reproduce the same tasks for multiple customers or sites.
Even if you are a developer, you can benefit from having a rich library of predefined and parameter-based PowerShell scripts. In fact, you can use those scripts to deploy development farms, as well as test environments. Moreover, using a script, you can deploy your customizations onto an on-premises farm. This book will not cover PowerShell in depth, because there are many other topics to cover that deal more specifically with SharePoint development. Nevertheless, you should consider reading a book on PowerShell for SharePoint as a companion to this book.
More Info
To learn more about Windows PowerShell, consult “Windows PowerShell” on MSDN (http://msdn.microsoft.com/en-us/library/dd835506.aspx) or Windows PowerShell Pocket Reference, by Lee Holmes (O’Reilly, 2012).
One fundamental concept embodied by SharePoint is that of a site collection. A site collection is a logical container that holds a set of SharePoint sites hosted in a web application. Whenever you work in SharePoint and you want to publish a site, regardless of whether it’s an Internet, intranet, or extranet solution, you will have at least one web application with one site collection, made of one site. Grouping sites in site collections allows those sites to share content, administrative settings, security rules, and, optionally, users and groups.
To create a new site collection, you need a web application, which you can create by selecting the Manage Web Applications menu item from the SPCA home page, or by using the corresponding PowerShell command. Avoid using the web application that hosts SPCA. After you have a web application, you can create a new site collection by selecting the Create Site Collection menu item on the SPCA home page. A dialog box will appear, asking you for a title, a description, and a URL relative to the parent web application.
Every site collection is administered by a site collection administrator, who is a user authorized to administer an entire site collection, including the websites it contains. Every site collection must have at least one site collection administrator, but it can have more than one. Thus, when creating a new site collection, you need to designate a primary site collection administrator and, optionally, a secondary one. After having created a site collection, you will be able to add as many site collection administrators as you like. A site collection administrator has the rights to create, update, or delete any site contained in a site collection. The administrator also has full rights to administer content within those sites.
When you create a site collection, you should also choose a template from which to start. If you need, you can select it from a number of predefined templates that are shipped with SharePoint. By default, the template will create a new site collection with at least one site at the root of the site collection. Templates are divided into functional groups and into two families. In fact, SharePoint 2013 comes with a new family of templates, as well as the previous template family from SharePoint 2010, for backward compatibility. Following are the five main functional groups of SharePoint 2013 templates:
Collaboration These are sites whose structure has been designed to facilitate collaboration. The Collaboration group includes the following templates: Team Site, Blank Site, Document Workspace, Blog, Group Work Site, Developer Site, Project Site, Community Site, and Visio Process Repository.
Meetings This group contains templates for sites related to meetings and meeting organization. The available templates are Basic Meeting Workspace, Blank Meeting Workspace, Decision Meeting Workspace, Social Meeting Workspace, and Multipage Meeting Workspace.
Enterprise These templates target enterprise-level needs in the areas of document management, policies, and so on. They include Document Center, Discover Center, Records Center, Business Intelligence Center, Enterprise Search Center, My Site Host, Community Portal, and Basic Search Center.
Publishing This group corresponds to sites intended for web-publishing purposes. The available templates are Publishing Portal, Enterprise Wiki, and Product Catalog.
Custom This is where you can develop your own site templates. Also in this group is a list of all the available custom templates, if any exist.
Figure 1-3 shows the home page of a site collection created by using the Team Site template of SharePoint 2013.
Every SharePoint site is composed of lists of items. When the items are simple—that is, they don’t correspond to documents or files, but are made of custom metadata properties only—they’re termed lists and list items. When the items correspond to files, they’re called document libraries or just libraries.
Every site template includes some predefined lists that are created when you construct a site using that template. For example, a team site provides a Documents library, a Site Assets library, a Site Pages library, and a few other predefined lists and libraries. Regardless of the site template you start from, you can always create new lists, libraries, and content, as well as activate features to customize your site.
You can browse the contents of these lists and libraries, and, if you have the proper permissions, you can create new apps, which can be lists of contents, libraries, or custom apps either taken from the public marketplace or installed from the corporate catalog. Consider that in SharePoint 2013, everything is called an app. However, a list or a library is still what it is—nothing more and nothing less. You can also add items to already existing lists or upload new files (for libraries) by simply dragging and dropping them from the file system to the webpage. Figure 1-4 shows the UI of SharePoint 2013 while browsing the contents of a document library.
Note also that Figure 1-4 shows the ribbon, which is a feature introduced with SharePoint 2010, to better support end users through a UI similar to the well-known Office interface.
When you want to create a new app, you simply click the gear icon, which is located in the upper-right corner of the webpage, and then select Add An App. As shown in Figure 1-5, you’ll see the Apps You Can Add list, from which you can select the type of app that you would like to create.
If none of the supplied templates of lists and libraries quite fits your needs, you can try or buy an app from the marketplace, and you can install an app from a corporate catalog. Of course, in order to access these, your farm should be connected to the Internet and configured for supporting apps.
App Parts are new features of SharePoint 2013, enabling you to enrich pages with external apps and content, which you can create on site or download from third-party sites or the cloud—for example, through the marketplace. An App Part is a block of HTML code, empowered with JavaScript and secured with OAuth, typically hosted outside the current site, and eventually integrating and/or consuming some contents within the current site. Later, in Part III of this book, you will learn how to create App Parts and how to consume them from a SharePoint site.
Web Parts have been some of the most notable features of SharePoint since its early versions. In fact, in SharePoint you can define pages made of configurable building blocks (Web Parts) that can be enabled, moved, or hidden by end users. The goal of this feature is to allow users to define their own pages, selecting content from a set of available Web Parts, with full personalization. Every page made of Web Parts is called a Web Part page.
With SharePoint 2013, the importance of Web Parts is declining, while the use of App Parts is becoming more prominent. You can think about App Parts as the heirs of Web Parts. A typical SharePoint 2013 solution contains some custom lists and document libraries, along with some apps presented as App Parts and configured in custom pages that show and manage the data stored in those lists and libraries, as well as outside the current site.
In this section, you’ll take a look at SharePoint architecture from a developer’s perspective. Figure 1-6 shows some of the main components of SharePoint, from the foundation elements up to the main enterprise-level features.
At the very base of SharePoint 2013 sits the operating system. Starting with SharePoint 2013, the minimum requirement for a production environment is Microsoft Windows Server 2008 R2 Service Pack (SP) 1 (Standard, Enterprise, or Datacenter) or Microsoft Windows Server 2012 (Standard or Datacenter). Although in SharePoint 2010 it was possible to install the product on a workstation machine running Microsoft Windows 7 or Microsoft Windows Vista SP1/SP2, this is no longer allowed with SharePoint 2013. Because SharePoint 2013 is available only in 64-bit versions, the minimum requirement for a deployment environment is a server-based 64-bit operating system (Windows 8 does not qualify as a host operating system for SharePoint 2013).
More Info
For further details about the software and hardware requirements of SharePoint 2013, read the document “Hardware and Software Requirements for SharePoint 2013” on TechNet Online, at http://technet.microsoft.com/en-us/library/cc262485.aspx.
In addition to the operating system, SharePoint 2013 also requires a database server based on Microsoft SQL Server 2008 R2 SP1 or Microsoft SQL Server 2012. Regardless of which edition of SQL Server you plan to use, you must be running a 64-bit version of the product. SharePoint uses the SQL Server database to store the configuration of SharePoint server farms, as well as the contents of deployed websites and the configuration and contents of all the services under the cover of the overall farm infrastructure.
On top of the operating system and database is an application server provided by Internet Information Services (IIS) 7.5. IIS 7.5 is mandatory, both because it hosts the web applications and because it publishes endpoints for SharePoint infrastructure services, making use of the Windows Process Activation Service (WAS) feature of IIS 7. Use of IIS 8 is suggested in new scenarios that you build from scratch, allowing you to take advantage of all the new features of Windows Server 2012 and IIS 8.
More Info
You can find more details about WAS on the “Hosting in Windows Process Activation Service” page on MSDN, at http://msdn.microsoft.com/library/ms734677.aspx.
Because SharePoint 2013 is based on Microsoft .NET Framework 4.5 and extends ASP.NET 4.5, the infrastructure requires .NET Framework 4.5. Another element at the foundation of SharePoint 2013 is the Windows Identity Foundation 1.0 framework, which provides claims-based services, extended in order to support OAuth and the new security model of SharePoint 2013. Part VI digs deeper into these topics.
On top of this foundation sits Microsoft SharePoint Foundation 2013, which is a free platform for building basic SharePoint solutions. Although free and the most basic edition of SharePoint, SharePoint Foundation 2013 contains a great deal of functionality that developers can use to meet the needs of basic portal scenarios.
At the top of the architecture is the SharePoint Server 2013 platform, together with its high-level and enterprise-level services, such as Excel Services, Managed Metadata Services, the User Profile services, the search engine, and so forth.
From a hardware perspective, the minimum memory requirement for a SharePoint 2013 server is 8 GB for a development environment, but this hardly gives you enough room to work. A more realistic minimum, however, is 16 GB for a successful development environment. For a production environment, the suggested memory is 12 GB for a web front-end or an application server, and 24 GB for an all-in-one server. Moreover, every SharePoint 2013 server should have a 64-bit CPU with a minimum of four cores.
Whenever you deploy a SharePoint environment, in reality, you’re deploying a logical architecture called a SharePoint farm. A SharePoint farm is a set of servers that have different roles and offer various services that together make up a server farm suitable for hosting a full SharePoint deployment. Here are the common server roles in a SharePoint farm:
Front-end web servers These servers publish websites, often called web applications.
Application servers These servers host back-end services, such as Search services, the User Profile service, Excel Services, and so forth.
Database servers These servers store configuration and content data for the entire SharePoint farm.
The smallest farm you can build is based on a single server; this type is often called the single server farm deployment. However, it is highly recommended that you avoid such a scenario, except for testing or development.
In fact, for the sake of scalability and business continuity, you should deploy a minimum of two front-end web servers, two application servers, and a back-end database server capable of supporting failover (clustering, mirroring, or AlwaysOn). This topology is commonly termed the smallest fault-tolerant farm deployment. If you need to scale out and support a wider range of users and sites, you can deploy a more complex farm by introducing some dedicated application servers. For example, real medium-scale and large-scale farms typically have dedicated servers for the search services, as well as dedicated servers for hosting the Office Web Apps services (which is a deployment requirement).
Due to the number and size of servers required for hosting a real production SharePoint farm, SharePoint 2013 farms are usually hosted in virtualized environments, either on-premises or in the cloud. For example, you could evaluate hosting SharePoint 2013 on an Infrastructure as a Service (IaaS) environment like Microsoft Windows Azure Virtual Machines. Moreover, you could also consider directly using Microsoft Office 365.
More Info
You can find further information about topologies and architectural diagrams on the “Technical diagrams for SharePoint 2013” page, on TechNet at http://technet.microsoft.com/en-us/library/cc263199(v=office.15).aspx.
Regardless of the deployment topology you choose, SharePoint uses a SQL Server database for storing farm configurations and content. Specifically, it creates a main and fundamental farm configuration database as soon as you deploy a new farm. Usually, this database is called SharePoint_Config or SharePoint_Config_{UniqueId}. If you use the automated setup process, this database is created for you when you deploy the farm for the first time. If you use PowerShell to deploy a new farm, which is highly suggested, you can determine the name of this database by yourself. Furthermore, the SharePoint Deployment And Configuration Wizard creates a set of satellite database files for the main services deployed. For example, it creates a database that stores the contents of the SPCA administrative site. In case you use a PowerShell script to deploy the farm, you can determine the name and location of all SharePoint databases.
From a hierarchical perspective, each SharePoint farm is composed of services, which include all the infrastructure services that make up the SharePoint environment. The most important kind of services are web application services, which correspond to the entry point for web-published solutions. Each web application is made up of at least one site collection and one content database. However, you can deploy multiple site collections within a single web application, and you can deploy multiple content databases for a single web application. A content database is a database file that stores content for one or more site collections. As it relates to SharePoint, content can include items, documents, documents versions, pages, images, and so on. Thus, the database behind a site collection can grow very fast.
Starting with SharePoint 2010 and much more with SharePoint 2013, the server roles and the configurable services have been improved to better support scale-out scenarios. In fact, you can now distribute different roles to dedicated servers, eventually with hardware redundancy.
Figure 1-7 shows a graphical representation of a SharePoint farm with a couple of front-end web servers, both of which publish the same web applications with network load balancing. The first web application (Web Application #1) is made of two site collections (Site Collections #1 and #2), both of which share a common content database (Content #1). The second web application (Web Application #2) is made up of a third site collection (Site Collection #3) and stores its contents in a dedicated content database (Content #2). All the site collections contain one or more websites.
On the back end, there are four application servers, hosting SPCA, the search services, Excel Services, and some other services.
All the data are persisted in a back-end database server that stores various database files for different purposes.
Introduced in SharePoint Foundation 2010, service applications are software services that run in a SharePoint farm. Service applications are intended for sharing resources and capabilities across multiple sites and servers in the same farm, or even across farms. Most importantly, they are extensible and scalable, unlike the Shared Service Providers (SSPs) of Microsoft Office SharePoint 2007.
To clarify the idea of a service application, consider a couple of examples. The search engine in SharePoint 2013 is based on a service application. This means that you can share the same search engine across different servers in the same farm, which is not surprising, but you can also share the same search service across multiple farms. For example, in very large scenarios, you could deploy a search-dedicated farm, without any front-end web server, that exposes only a wide set of servers providing query, index, crawler, content -processing, and analytics components. You could then use this farm to serve many other SharePoint 2013 farms, taking advantage of that shared search service. Another example is Excel Services: if you have a farm that uses Excel Services extensively to make calculations and create reports on external data, you could decide to deploy Excel Services on two or more dedicated servers in the farm, using them from all the other servers.
These configurations are possible because the architecture of service applications has been designed with scalability in mind. Thus, every service application that runs on a server in the farm can support scalability, and can be installed on two or more servers. At the same time, a farm uses a proxy to consume a service application, which can be published locally, or in some cases can be published by a third-party farm. While a front-end web server consumes a service application, however, it ignores the real location of the service and simply concentrates on consuming it. This is possible because each SharePoint Foundation 2013 farm has a native service application, called the Application Discovery and Load Balancer Service, that coordinates service discovery and load balancing for services deployed on more than one application server. By default, each service application proxy communicates behind the scenes with the back-end service application via a secure channel based on Windows Communication Foundation (WCF).
Every SharePoint farm includes one or more back-end database servers. In fact, the back-end SQL server stores the entire configuration of the farm, as well as contents of every site collection and the data for many service applications. For example, the search service stores crawled contents, properties for crawled data, and configuration properties in multiple separate and dedicated database files. For the sake of precision, in SharePoint 2013, the Search service application allocates four databases. The Managed Metadata service has another dedicated database file, but the list of native services using one or more databases on the back end could be longer.
Important
Even though you can open a SharePoint database in SQL Server Management Studio and inspect the databases of a SharePoint farm, you should avoid doing that. In addition, you should not base your software solutions on the data structure of SharePoint databases. Thus, you should avoid querying and writing the content of these databases directly. If you do need to read or write their content, take advantage of the various libraries, APIs, and object models discussed later in this book.
Now let’s concentrate on pages and content. Recall that each time you create a new site collection using SPCA, you have the opportunity to choose a starting site template. The site template is a set of configuration, layout, and content files that define a site model. You can build your own site templates (you will learn how to do that later in Part VI), or you can select one of the existing site templates that are packaged with SharePoint. Whichever site template you choose, under the covers, SharePoint starts from a set of files stored in the file system of all front-end web servers, and then creates some records in the content database that will host the site collection that you are creating. After the site collection has been created, when you browse to a page using a web browser, the SharePoint engine determines whether the page you have requested resides entirely on the file system, or whether it needs to retrieve some personalized content from the content database and merges that with the page model from the file system, or even whether the page content is completely stored in the content database.
Having a back-end content database available gives you the option to deploy multiple front-end web servers that can share the same content, improving horizontal scalability when necessary. At the same time, maintaining basic page models in the file system improves performance, because loading a page from the file system, unless it has been personalized, is generally faster than retrieving it from an external database server. In the section “SharePoint for developers,” later in the chapter, you’ll see how SharePoint differentiates between file system and database content sources.
SharePoint 2013 is offered in several editions. Even though this book is for developers (as opposed to sales or marketing personnel), it is useful to know the main differences between each edition of the product. The goal of this section is to give you the base knowledge required to choose the appropriate SharePoint edition for each of your projects.
More Info
For a full comparison of the SharePoint editions, see the page “SharePoint Online” at http://technet.microsoft.com/en-us/library/jj819267.aspx.
SharePoint Foundation 2013 is the most basic edition of the product. It is free—providing that you run it on a licensed copy of Microsoft Windows Server—and it offers the fundamental features for building simple document storage and collaboration solutions. By default, this edition’s main capabilities are accessibility, cross-browser support, basic search features, out-of-the-box pages and Web Parts, new UI features based on dialogs and ribbons, blogs, and wikis.
The Foundation edition also supports the basic infrastructure of Business Connectivity Services, although without any client-side or Office capability. Of course, you’ll also find the SPCA controls, all the farm management tools, and services such as the SharePoint Health Analyzer. In fact, if you wanted to, you could deploy a multitier farm using just SharePoint Foundation. Finally, SharePoint Foundation offers all the features supporting custom development, including the Web Parts/App Parts programming model, the Server Object Model, the Client Object Model, event receivers (local or remote), claims-based security, and so on. All these topics will be covered in detail in Part II and Part III
You should use this edition of SharePoint whenever you want to develop custom solutions that do not require any high-level features, such as the document management tools, user profiles, managed metadata, and so on. When you simply need to use SharePoint as a web-based “sharing point” to store content, such as documents, contacts, tasks, and so on, this is the edition that best meets those needs. Quite often, SharePoint Foundation is the right starting point for gaining experience with SharePoint. It also serves well as a bridge: you can start installing Foundation; plus, later on, you will be able to upgrade to SharePoint Server, if the need arises.
The Microsoft SharePoint Server 2013 Standard edition is built on top of SharePoint Foundation 2013, adding useful features for building business-level solutions. In particular, you will find features supporting Enterprise Content Management (ECM) and Web Content Management solutions. This edition also provides legal compliance capabilities, including records management, legal holds, and document policies. It also offers support for document sets, which give you the ability to manage related documents as if they were a single entity. It supports document IDs, which assign a unique protocol number to SharePoint site documents. Using this edition, you can target content based on audiences, which are profile-based groups of targets. Moreover, you have the capability to use the Managed Metadata service for managing common metadata properties, navigation elements, publishing, and product catalogs across multiple site collections and web applications.
SharePoint Server is the right choice for implementing business-level solutions. For example, SharePoint Server can help you create a content management system (CMS) solution that provides content publishing, content approval, page layouts, web standards (XHTML, WCAG 2.0, and so on) support, and so forth. This edition also supports tags and metadata-driven search refinement, people search, and the whole set of social features. As a business-level tool, it provides features for managing not only content, but also people, profiles, and personal sites. Finally, this edition of the product provides support for developing and executing workflows, hosted either on-premises or in the cloud on Windows Azure.
Microsoft SharePoint Server 2013 Enterprise edition targets large business solutions and enterprise-level organizations. It extends the capabilities of SharePoint Server Standard by offering support for dashboards, key performance indicators (KPIs), and business intelligence features. It improves search capabilities by offering contextual search, deep search query refinement, extreme scale-out search capabilities, rich web indexing, and so on. It also provides support for Excel Services, Visio Services, Forms Services, and Access Services.
When you need to develop business analysis solutions or complex search-based solutions, you should choose the Enterprise edition.
From a developer perspective, you can install the SharePoint Server Enterprise edition if you have licensing coverage for that, and you can develop solutions for all the editions using a unique environment.
Microsoft SharePoint Online is the cloud-based SharePoint offering, based on the Software as a Service (SaaS) paradigm included in Microsoft Office 365. With this edition, you can build SharePoint solutions without building a SharePoint farm on-premises. Instead, by having your farm in the cloud, you can enjoy an external solution free of management costs. As a developer, you are freed to focus only on data, processes, ideas, the content that you want to share, and the apps you want to build. The SharePoint Online offering is available in Standard mode, as well as in Dedicated mode. The Standard offering uses an environment shared with other customers, although it is isolated according to a clear set of multitenancy rules, and you can only extend that environment with code executed in a sandbox or custom apps. On the contrary, the Dedicated offering allows you to have a dedicated server farm on which you can deploy custom solutions with full-trust execution rights, as long as your solutions passes a verification process.
SharePoint offers developers numerous features and capabilities for building custom web solutions. This section provides an overview of those features and services so you can better understand the topics that you will be exploring in the rest of this book.
As a developer, you might be wondering how SharePoint 2013 integrates with ASP.NET to service requests and provide its high-level features on top of the ASP.NET native infrastructure.
Since IIS 7.0, in Windows Server 2008, application pools can run in one of two modes: integrated mode or classic mode. Classic mode works like older versions of IIS (IIS 6), taking advantage of the Internet Server Application Programming Interface (ISAPI) filter based on the Aspnet_isapi.dll file. Integrated mode provides a unified request-processing pipeline for requests that target both managed (.NET) and unmanaged (non-.NET) resources. Every request is served by a module registered in the application configuration.
SharePoint 2013 provides a Microsoft.SharePoint.ApplicationRuntime namespace in the Microsoft.SharePoint.dll assembly. This namespace contains a set of classes that integrate and/or override the default behavior of ASP.NET while in IIS integrated mode. The primary class that handles SharePoint requests is called SPRequestModule. It is configured in the web.config file of every SharePoint site, in the system.webServer/modules section. This class registers a number of application events that handle requests, authentication, errors, and so on. One fundamental task of this module is to register the virtual path provider (SPVirtualPathProvider), which resolves requests by determining whether the requested content should be retrieved from the content database or from the file system. A virtual path provider is a class that provides contents to the ASP.NET pipeline by retrieving them from a virtual file system.
SharePoint offers developers a rich set of server-side tools. First, you can use the SharePoint Server Object Model, which allows you to interact with SharePoint through a large set of libraries and classes. Using these classes, you can read, manage, and administer data stored in SharePoint. More generally, you can use the Server Object Model to do almost anything that SharePoint itself can do, because SharePoint itself uses that same object model. You can use the Server Object Model on a SharePoint server only, because it has some dependencies not satisfied by other servers. You will learn more about this tool in Chapter 5
On the server side, you can also use the LINQ (Language Integrated Query) programming model, exploiting the LINQ to SharePoint provider, by which you can query and manage SharePoint data using a fully typed programming model, much as you would when managing data stored in SQL Server using LINQ to SQL. Chapter 6 discusses this LINQ query provider in more detail.
One of the biggest news of SharePoint 2013, from a developer perspective, is the improvement of the client-side technologies for consuming SharePoint data and interacting with remote SharePoint servers. In fact, you can exploit a rich set of client-side technologies offered specifically for this purpose. For example, the SharePoint Client Object Model lets you interact with SharePoint from a client using a set of classes that are similar to the Server Object Model, but work on any client that supports .NET, Microsoft Silverlight, or JavaScript. The Client Object Model is available in three different flavors: .NET managed, Silverlight, and JavaScript. The Client Object Model versions are almost functionally identical on all three platforms. You can also use SOAP (Simple Object Access Protocol) services published by SharePoint, even though they are deprecated and available for backward compatibility only. Furthermore, you can use the REST (Representational State Transfer) API to access and manage SharePoint data by using a protocol for querying and updating data via an HTTP/XML communication channel called OData (Open Data Protocol, documented at http://www.odata.org). Moreover, starting with SharePoint 2013, you can take advantage of a new and rich set of APIs published via HTTP and accessible from any device; these APIs are useful for consuming data and interacting with site collections, sites, services, and whatever else you could need to create a SharePoint app or solution. From a security viewpoint, you can use the common OAuth (Open Authentication) standard to secure communication and authenticate/authorize both users and apps while consuming data and interacting with SharePoint services.
All of these client-side technologies are discussed throughout the book, and in particular in Parts II and III.
Another area of interest for developers is customizing the UI. Many SharePoint developers working on SharePoint 2010 or earlier spent their time developing Web Parts, Web Part pages, and UI customizations. SharePoint 2013 still provides a rich object model, and even backward compatibility, for building custom Web Parts and Web Part pages, as well as a set of UI customization tools that simplify working with AJAX (Asynchronous JavaScript and XML), dialog boxes, the ribbon, and so on. Now, with SharePoint 2013, you can extend and customize the UI by creating apps and App Parts. You can think about App Parts as blocks of content, consumed from a remote app, that play the same role as Web Parts did in the past. You will see how to develop App Parts in Part III of this book.
As soon as you begin working with SharePoint, you will face the need to define packages for automatically deploying data structures. Working with SharePoint generally involves designing new lists and new content types, which are reusable typed definitions of metadata models. However, if you define your models using the web browser, you won’t have a high-level modeling approach; everything you do must be migrated and/or executed again in the quality assurance (QA) and production environment.
Fortunately, there are tools and techniques that allow you to model a data structure—optionally based on custom contents and fields—and deploy that model to customers’ sites. These tools also provide support for deploying updated versions of the solution in the future. You’ll see more on this subject later in this chapter, in the section “Features, solutions deployment, and sandboxing.” You will learn how to define custom data models for automated provisioning in Data provisioning
With SharePoint, since version 2007, you can use local event receivers to intercept users’ actions and/or events and subsequently execute some lightweight server-side code. Now, with SharePoint 2013, you also have the capability to create remote event receivers for invoking external and remote services. These receivers are capable of handling events like item insertion, updating, deletion, and so on. This is a useful feature for implementing simple process-handling solutions or business-processes coordination, activating external processes upon user actions in SharePoint. Moreover, you can use remote event receivers to make apps communicate with parent websites. Chapter 10 dives into this subject.
Similarly, when you need to define complex and long-running business processes that respond to events from the UI and interact with end users, you can define workflows. With SharePoint 2013, the workflow engine has been redesigned from scratch, using the new Workflow Manager 1.0 engine, based on Workflow Foundation 4.5, together with a new application server role that can be hosted on Windows Azure or on-premises. This functionality deserves a thorough exploration, so this book discusses it in four dedicated chapters, in Part V
As a complete development platform, SharePoint 2010 introduced deployment services and capabilities by which you can deploy and upgrade solutions during a project’s lifetime. In SharePoint 2013, all these features are still available and suitable for developing complex customizations and solutions. Specifically, SharePoint offers the opportunity to create deployment packages, called Windows SharePoint Services Solution Packages (WSPs). You can use these packages to automate setup and maintenance tasks across an entire server farm. In addition, you can deploy these solutions in a sandboxed environment. The packages consist of features, which are atomic sets of extensions that you can develop, install, activate, and manage with a specific set of administrative tools. In Chapter 4 you will learn how to create and deploy such packages. In Part III of the book, you will learn how to create and deploy custom apps as a suitable alternative to implementing SharePoint solutions.
The SharePoint security infrastructure is another topic that affects both software development and the architecture of solutions. In fact, to develop robust and solid solutions, a developer should have a high degree of confidence in, and knowledge about, SharePoint authentication and authorization policies. The key security aspects of SharePoint 2013 are its claims-based approach and support for the OAuth protocol. Part VI of the book is fully dedicated to security matters.
Business Connectivity Services is another feature that is generally useful when developing solutions. This feature supports consuming external data within SharePoint, and has a design almost identical to data directly stored in SharePoint. The sources of this external data can be an RDBMS, like SQL Server or any ODBC-compliant data source; a WCF/SOAP service; a custom .NET object model; or an OData service. Chapter 14 will cover this topic.
Another interesting capability is that you can administer and automate SharePoint administrative tasks using the Windows PowerShell console. Windows PowerShell is a task-based command-line shell and scripting language designed especially for system administration. It can execute commands and scripts authored by developers or system administrators, as long as they have some minimal development expertise. What makes Windows PowerShell a powerful framework for developers is its extensibility model, together with its capability to execute custom code. For example, from the Windows PowerShell console, you can not only administer a farm, but also create scripts for populating data into target lists of SharePoint. You can manage, create, and configure testing environments, and you can create custom scripts to deploy your solutions.
SharePoint developers can take advantage of some Microsoft-supplied tools to support their work and reduce the effort involved in developing custom solutions. This section lists these tools and identifies when they might be useful.
SharePoint Designer 2013 is a rapid application development (RAD) tool for developing SharePoint no-code solutions. You can download it for free from Microsoft’s website, at http://www.microsoft.com/download/details.aspx?id=35491. SharePoint Designer 2013 targets advanced users, who can use it to design and compose solutions without writing any code. For example, using SharePoint Designer 2013, you can
Personalize pages, page layouts, Web Parts, Web Part pages, layouts, and themes.
Create and manage lists and document libraries.
Design simple workflows or import workflows designed using Microsoft Visio 2010 or 2013.
Manage content types and site columns to model typed lists of contents.
Model and register external data sources using the Business Data Connectivity engine.
Create pages with lists data bound to external data sources.
Manage users and groups.
Manage files and assets of the target site.
Figure 1-8 shows the main page of SharePoint Designer 2013 when connected to a SharePoint site. As you can see, it provides a user-friendly interface, consistent with the Office 2013 user experience.
As a developer, you will primarily use this tool to prototype solutions, to design Business Data Connectivity models, and to customize layouts—working with themes, master pages, XSLTs, and pages.
Note
This book will not cover SharePoint Designer 2013 in depth, because it is aimed at developers who are willing to develop SharePoint solutions by writing custom code. For deep coverage of SharePoint Designer 2013, read Microsoft SharePoint Designer 2013 Step by Step, by Penelope Coventry (Microsoft Press, 2013).
Visual Studio 2012 can be extended with a set of tools for developing SharePoint 2013 apps and solutions. These tools are named the Microsoft Office Developer Tools for Visual Studio 2012 and can be installed through the Web Platform Installer kit or downloaded manually from MSDN. When you install Visual Studio 2012, you have also the opportunity to activate the SharePoint 2010 Developer Tools option, which installs a set of project and item templates that are ready to use in SharePoint solutions that target SharePoint 2010. Most of the code and projects you develop using the SharePoint 2010 developer tools are also supported by SharePoint 2013, for the sake of backward compatibility. Nevertheless, it is highly recommended to develop using the SharePoint 2013 tools and the new apps-oriented development model introduced in SharePoint 2013.
More Info
The Microsoft Office Developer Tools for Visual Studio 2012 can be directly downloaded from the following URL: http://msdn.microsoft.com/en-US/sharepoint/aa905690.aspx.
The development tools for SharePoint also include some deployment tools, which are useful for packaging, releasing, and upgrading a SharePoint solution.
Note
To use Visual Studio 2012 for developing SharePoint 2013 apps and solutions, you must run it under an administrative account, because you need some high-level permissions to manage the SharePoint servers while deploying solutions. In addition, you need to attach to the IIS worker process while debugging code. It is suggested to run your desktop as a standard user, but run Visual Studio 2012 with a Run As command to impersonate an administrative user. Moreover, to develop SharePoint solutions (WSPs), you need to have SharePoint installed on your development machine. On the contrary, to develop SharePoint apps, you do not need to have SharePoint on board, and you can remotely connect to an external SharePoint environment, including SharePoint Online on Office 365.
Figure 1-9 shows the Add New Project form of Visual Studio 2012, showing the project templates installed by the SharePoint extensions.
You can create the following types of projects:
App for SharePoint 2013 This is the project template for creating a SharePoint 2013 app. It will be discussed in depth in Chapter 8
SharePoint 2013 Project This is an empty project for starting a new SharePoint implementation. It provides a set of references to only the most useful libraries of SharePoint, and it provides support for automatic deployment.
SharePoint 2013 Silverlight Web Part This is a project intended for developing a Web Part with a GUI based on Microsoft Silverlight.
SharePoint 2013 Visual Web Part This is a project intended for developing a Web Part with a GUI based on an ASCX web control of ASP.NET.
Import SharePoint 2013 Solution Package This imports an old or third-party solution package (WSP).
Import Reusable SharePoint 2013 Workflow This project template is useful for importing workflows designed with SharePoint Designer 2013 that need to be extended or improved with Visual Studio 2012.
Regardless of which project template you start from, you can develop any of these extension types, because these models simply prepare a preconfigured environment. In fact, it’s quite common to start with the App for SharePoint 2013 template or the SharePoint 2013 - Empty Project template, and then add items as you need them.
Microsoft Office Developer Tools for Visual Studio 2012 also provides a rich set of item templates for creating various types of content in SharePoint app projects. Here is a list of some of the main items:
List This is for specifying a custom list of fields or creating a new list from an existing list template.
Remote Event Receiver This allows you to handle SharePoint events using a remote service.
Content Type This is for creating a reusable collection of fields and settings that you can apply to a SharePoint list.
Workflow This allows you to create and deploy a workflow for SharePoint, based on the new workflow engine of SharePoint 2013.
Empty Element This is an XML feature element for hosting files, pages, or any other customization, compliant with the features and elements schema available in SharePoint since version 2010.
Site Column A site column item is useful for creating custom content types and list definitions.
Module This is a module item for deploying files, pages, assets, and more on SharePoint.
Client Web Part (Host Web) This is a client Web Part (App Part) for supporting a custom SharePoint app.
UI Custom Action (Host Web) This is typically used in an app that adds a UI extension to its host site; for example, it can add an action to the ribbon or to a list menu.
Task Pane App This is an app that appears in the task pane of an Office application.
Content App This is an app that appears in the body of an Office document.
Another interesting feature offered by Visual Studio 2012 is SharePoint Server Explorer, an extension to Server Explorer in Visual Studio 2012 for targeting SharePoint servers. Through this extension, you can register as many SharePoint servers as you need and browse their topology and configuration using the classic tree-view approach, such as in Visual Studio Server Explorer windows.
As shown in Figure 1-10, the SharePoint Server Explorer interface lets you browse and manage the following:
Sites and subsites
Content types
Features
List templates
Lists and document libraries
Workflows
In addition, because SharePoint Server Explorer is based on an extensible object model, you can extend it to provide new functionalities, using Visual Studio 2012 to develop such solutions. You can already find many custom extensions that can be downloaded for free.
One last set of tools available in Visual Studio 2012 include Solution Explorer and the Feature Designer. These are tools for graphically designing and managing SharePoint packages (WSPs) and features. They are particularly useful for automating deployment of SharePoint solutions. You will learn more about these tools in Chapter 4.
This chapter explained what SharePoint is, what its main capabilities are, and how developers can take advantage of those capabilities. It described the product architecture and gave a quick comparison of the various SharePoint editions so that you can choose the one that best fits your needs. Finally, it covered the main tools available for developing SharePoint solutions.