Introduction to Sharepoint 2013 : ADDRESSING THE NEEDS OF THE DEVELOPER

At its essence, SharePoint is a platform. And to see how SharePoint can help you as a developer, you must understand those platform capabilities. When you explore and learn the range of functionality that make up the platform, you’ll begin to see some interesting and compelling opportunities emerge for the developer.

Take a look at a practical example. As you have seen, a business productivity platform implies having a platform for end users to make them more collaborative and productive in their day-to-day work lives — and SharePoint can certainly do that. In short order, it can be used as an application for end users. For example, a Human Resources (HR) department might use SharePoint to manage employee reviews, or a sales team might use it to manage a monthly sales-forecasting dashboard for BI.

In all of these scenarios, SharePoint first represents an end user collaboration platform, and second represents a base that skilled developers can augment or extend. So, when your sales manager comes to you (the developer) and asks you to design a SharePoint site collection that integrates daily sales data from an SAP system and plot high-potential markets on a map in the SharePoint site — so salespeople can see current sales pipeline versus opportunity areas — you wonder in what ways this type of app would manifest in SharePoint.

Let’s look at this task from two perspectives:

• End users want a site they can open, manage their sales documents and spreadsheets, filter and pivot data in, and then get a quick view on the map to see where they should be targeting. They want ease of use and actionable apps.
• Developers want to craft an experience that is easy to use and intuitive — but also efficient to manage.

As a developer, you’ll want to keep both perspectives in mind when performing the task. In doing so, implementing a solution for each task will likely require leveraging a combination of native features — such as document libraries and lists — and core services, capabilities, and APIs built into the platform to get you to the next level from a development perspective. You can also integrate either third-party or your own custom cloud-based services to round out the development experience.

For this particular example with your sales manager, you could use a combination of Business Connectivity Services (BCS), which is a set of services within SharePoint that enables you to connect to LOB systems and Excel Services, so you can create “pivotable” spreadsheets for salespeople. The end result of using BCS is a dynamically generated list app to contain the sales data and a document library app where you would house the spreadsheets. Therefore, you need to create two types of apps — a document library that leverages Excel Services and an external list app that loads the external LOB data. You could then integrate an HTML or JavaScript-based app that uses a cloud-deployed service to create a Bing map, and then overlay pushpins that are color-coded green for high potential, and red for low potential (or saturated) markets. This app would be the third one needed — but behind it sits a service you’re plugging into (such as the Bing Maps service) and your own custom service that has the logic to create the pushpins based on some set of business rules or information. You can accomplish the development and deployment of these three apps either using apps that are deployed to an existing Team site, or by creating your own custom site with the Sales department branding.

The key takeaway from this example is that depending on what your audience requires, you can use SharePoint to create interesting experiences. You should be thinking about all these options as you design and build your SharePoint experience.

Extending SharePoint 2013

Although SharePoint represents a set of connected apps and functionality, it still has a vast array of opportunities for developers to extend and enrich the end-user experience at multiple levels. This experience is obviously important when you think about SharePoint in the context of the enterprise developer. However, when independent software vendors (ISVs) think about the custom experience they want to deploy to their customers, having a reliable platform beneath their feet that they can deploy to and use to customize their SharePoint solutions becomes vital. Furthermore, they require a place to monetize; that is, a marketplace that provides not only a place for deployment and advertising, but also a place for in-product or catalog integration. Their business depends on platform stability, predictability, accessibility, and discoverability. So what does it mean to extend SharePoint 2013?

With the entry and integration of broader cloud-hosted models, extending and building on SharePoint means a wider array of Web development partners, customers, and ISVs can participate in the SharePoint phenomenon. Some of these forms of participation include the following:

• Building “light” apps (for example, HTML and JavaScript apps) for SharePoint
• Leveraging the new cloud-hosted app models to either build Windows Azure–based apps or use technologies from a broader set of Web standards and technologies

To further understand this extensibility in a paper available through Forester Research (www.forrester.com/rb/Research/now_is_time_to_determine_sharepoints_place/q/id/45560/t/2) entitled, “Now Is the Time to Determine SharePoint’s Place in Your Application Development Strategy,” John R. Rymer and Rob Koplowitz reinforce a model of SharePoint 2013 that is composed of different layers. The two authors propose that SharePoint has an application layer, where end users integrate with the out-of-the-box collaboration and productivity applications; a customization layer, where either power users or developers can begin to customize the SharePoint experience for the end user; and a third layer, which is the application development layer.

This application development layer is where things get very interesting for developers. At this layer you’ll mostly find the solution developer who builds and deploys (or integrates through existing SharePoint artifacts such as Web parts or event receivers) applications or business solutions. What’s also interesting is how this application development layer has evolved. Figure 1 illustrates how SharePoint 2013 has evolved from earlier application development paradigms.

FIGURE 1

Figure 1 shows that SharePoint 2007 ran custom code or services from IIS or other servers. The custom code for the most part ran within an application pool using IIS resources. In 2010, SharePoint supported running on IIS (or other servers) and also introduced sandboxed solutions and the Client-side Object Model (CSOM), which then enabled contained solutions and client-side code to run. This version also brought the introduction of a Windows Azure that was more integrated with the SharePoint development paradigm — both on the server and on the client. In 2013, this development paradigm takes Windows Azure integration to the next level — in some cases natively using Windows Azure as the deployment, storage, and computing mechanism. Figure 1 illustrates workflow running in Windows Azure and hooking into SharePoint through a refactored REST API (_api). Thus, at the application development layer quite an evolution has occurred within SharePoint 2013.

In light of these different layers, extending SharePoint means something slightly different in SharePoint 2013 than in past versions, including:

• A more open approach to development
• A broader integration with the cloud
• Support for open source and non-Microsoft technologies
• Bringing your own hosted apps to the SharePoint experience
  

Breaking It Down for Developers

As you might have gathered by now, SharePoint development can mean a number of things. For example, if you want to simply add an app to a page, you might consider yourself a developer. If you customize the branding of a SharePoint site, you might only have to interact with page layouts or master pages (that is, the way in which you structure content in SharePoint) but you still may be a developer. Finally, if you do deeper-level solution development, you might be creating HTML5 and JavaScript applications that interact with SharePoint through native APIs, or use .NET and the cloud-hosted app model with Windows Azure. This type of development would mean you’re a developer who uses Visual Basic or C# along with potentially leveraging different application programming methods such as Model, View, and Controller (MVC) apps and REST services. As you delve more into the managed-code side of the house to build your SharePoint apps, you will, of course, enter into a more complex development paradigm.

Exploring the Different Levels of SharePoint Development

The point is that there are different levels of “development” in regards to SharePoint, and each level serves the end user of the SharePoint site in some way. One way of looking at it is to think of development as cutting across a spectrum with the following areas:

• Power user: Someone who has advanced privileges on a SharePoint site, administers permissions, manages administration of a SharePoint site, manages apps on the site, and might even create lightly customized sites for consumption.
• Designer: Someone who is largely in charge of branding and master page customizations, designing the user experience, designs graphics for the site, implements CSS or other style sheets, and so on.
• Website developer: Someone who develops managed code, mark-up code, or unmanaged/client-side code solutions for SharePoint sites. This is you!

Although those of you who have a SharePoint background might split this spectrum even further, development in general can fall within the preceding three areas. You might argue that the people performing both tasks of site-branding and app development are equally identified as developers on the SharePoint platform, but the fact is that actual development can range from using HTML5 and JavaScript to .NET and service-based technologies (that is, REST or WCF) to non-Microsoft Web technologies. This spectrum is not only symptomatic of SharePoint being a broad platform but also a symptom of the different standards, applications, and interoperability that SharePoint must support as a good citizen of the Web. Web interoperability is even more important with the 2013 release given the focus on cloud-hosted apps.

If you break down these levels of development and use across Rymer and Rob Koplowitz’s different layers of SharePoint, you’ll find that the largest population of SharePoint consumers interacts with the applications layer. These consumers are the end users, and they represent your core audience for building and deploying your custom applications to SharePoint. Power users of SharePoint might operate at the customization layer because they possess a high degree of SharePoint knowledge.

Then there is the Web (or SharePoint) developer. You are, in many cases, the person who develops those custom applications for SharePoint or the next killer app in the ISV ecosystem.

As a power user, designer, or Web developer, you have a number of development tools at your disposal. They range from in-browser tools, for example, Napa, to designer tools such as SharePoint Designer, to more traditional development IDEs, including Visual Studio 2012, that support managed, unmanaged, and client-side code; debugging; ALM; and so on.

With regard to developer productivity, this means that you can use either Visual Studio 2012 or SharePoint Designer (SPD) as your core set of developer tools. As a professional Web developer, you’ll likely use Visual Studio as your core toolset — especially if you’re a .NET programmer looking to get into the SharePoint space. As for SPD, you’re more than likely going to use it to edit master pages and page layouts, as well as to build noncomplex workflows using a Visual Rules approach (for example, using Visio 2013 and SPD). As a complement to these tools, you might also use Expression Blend either as a way to build more advanced and interactive UIs (through Expression Blend) or through Expression Web for baseline Websites.

In terms of rich platform services, SharePoint 2013 offers the developer a wide array of methods for getting, managing, and updating objects and data within a SharePoint site. With this version of SharePoint you’ll see increased investments in REST and OData, app authentication through OAuth, and, of course, a host of client-side APIs using the client-side object model to enable many different types of application programming and solution development.

Deploying Your Application

After you build your application, you need to deploy it. In SharePoint 2013, you can deploy two primary types of apps: Apps for SharePoint and SharePoint Solutions.

Those who have been around SharePoint before might recognize Solutions: they are the Windows SharePoint Services Solution Packages (WSPs) that represent small- to large-scale packages that are used to customize or augment SharePoint sites in some way. SharePoint Solutions are typically run as full-trust solutions and require a farm-level deployment. In SharePoint 2010, you could also run Solutions (.WSP) in a partial-trust sandboxed environment, and although this sandboxed environment still exists in 2013, it will be deprecated in the future.

Apps for SharePoint (.APP) are new to SharePoint 2013 and are standalone applications that provide specific configuration information and functional components to a SharePoint site. Apps for SharePoint are easy to install, use, manage, upgrade, and delete. You can add Apps for SharePoint from a corporate catalog or the Marketplace. You can also leverage two different hosting models: one that is a lighter app and is hosted within SharePoint (think HTML and JavaScript apps) and one that is hosted within the cloud-hosted model (think Windows Azure–hosted apps).

Within these different types of SharePoint deployment techniques, you can do the following:

• Import a standard Windows SharePoint Services Solution Package (WSP) into your SharePoint farm.
• Build and deploy a solution to a SharePoint instance within the corporate firewall.
• Build and deploy solutions to a SharePoint site hosted on the wider Internet.
• Package and deploy the .APP to the cloud, but configure and register it to load in SharePoint.

As you think about SharePoint 2013 development, keep the following things in mind:

• SharePoint’s new direction is more cloud-centric. You should be thinking about this from design to deployment.
• SharePoint has a rich object model, as well as a set of services and APIs that you can leverage when developing custom solutions.
• Visual Studio 2012 has a mature, out-of-the-box experience for building and deploying SharePoint solutions.
• You can build and debug SharePoint sites remotely.
• A number of ways are available to interact with SharePoint data (for example, the client-side object model).
• You can leverage BCS to build rich LOB apps.
• Multiple integration points exist across other Microsoft and third-party applications (such as Office 2010, SAP, PeopleSoft, Microsoft Dynamics, Microsoft Silverlight, and so on).
• A cloud-based deployment methodology now exists for SharePoint 2013 that is defined using the .APP deployment.
• You can deploy SharePoint 2010 solutions on premises or to the cloud (that is, SharePoint Online). However, the future is deployment to the cloud.