Freigeben über

Using SharePoint as a Back-End Server - Introduction

  • Artikel

Finally I found the time to create this post. It has been a while since I started utilizing SharePoint as a backend server but never found the time to put it to words. As usual I will start with the scenario and later try to detail the process.

Think of a web application where you have to provide blog like functionality to your end users. Assume that this application also enables its users to do threaded discussions. Let’s assume that this application will also serve different groups of users where the membership of a user would determine whether or not a user can create a comment on a post. To make thing a little bit more simpler, think that you need to provide the functionality for users creating their own groups and manage those groups.

Now let’s take the requirements couple of steps further. Assume that you want to provide a fancier user interface compared to SharePoint’s native UI – one that is developed in Silverlight with nice transitions. Your users started to demand a Windows Desktop application that would allow them to use the system both offline and online. As the Web and Windows applications make their grounds, you decided to provide your users a native Windows Phone 7 application experience.

One approach is do custom development – unleash the power of the Microsoft .NET platform and utilize Microsoft SQL Server as much as you can. You will have to tackle with database structures, manage authentication and authorization, and address other common tasks but again that is the nature of custom development.

There is an alternative solution. Why not utilize a product that would address most of the requirements (and even more) that we have talked above – why not utilize SharePoint to handle both the business logic and the data related activities and concentrate on user interface. SharePoint’s native user interface can be used for administration purposes. As different user interface clients will utilize the functionality provided by SharePoint, a WCF layer will be a perfect wrapper. In this WCF layer, some additional logic can be implemented to address any functionality that SharePoint does support out of the box.

By utilizing SharePoint as a backend server, we have reduced the amount of coding we have to do by at least %60. We no longer have to worry about authorization, no longer have to design database tables to support blog like functionality. Suddenly, we have a search system that indexes all the data, we have picture libraries, agendas that we can expose as services. Again, we have the administration system ready to use where we can even separate the administrators from normal users.

 

With this architecture in place, I have suddenly created a framework that lets me utilize SharePoint as a backend server. I can now access SharePoint through my WCF Services and make it create me a blog. Again I can ask SharePoint to list all the profiles. I can let my users manage their profile securities. For all this functionality, I have to write only a small bit of code just to utilize the SharePoint.

The problem at this stage is how to make this work. The whole set up is the same as setting up a normal SharePoint. After installing the SharePoint you will create a services machine to host your WCF Services. Now you have to choose how to communicate with SharePoint.

To communicate with SharePoint you have couple of methods that you can choose from. Below is the list of possible ways:

  • SharePoint Front-End Protocols: SharePoint Front-End protocols are a layer of web services that you can make your software talk with. It is very straight forward and you can even utilize the web services from your clients. I find the main drawback to be the performance. More information can be found here: SharePoint Front-End Protocols
  • SharePoint .NET API: To use the SharePoint API, you have to make your services layer a part of the SharePoint farm. After you do that, you can start using the SharePoint API inside your WCF service code. You will open the site, open the web, find the list and get the data as you would do if you were to implement a SharePoint web part. I find this to be faster (in terms of performance) compared to SharePoint Web Services. I mostly use this approach for adding, updating and deleting data.
  • SharePoint Foundation RPC Protocol: This protocol can be used in Win32-based applications or in ASPX applications to make HTTP POST requests to the server. Methods in this protocol that do not modify the contents of the database can also be used in URL protocol to make HTTP GET requests. I prefer this when doing data retrieval on lists. More information can be found here: https://msdn.microsoft.com/en-us/library/ms478653.aspx
  • SharePoint Back-End protocols: This protocol set is a huge set of protocols which helps you manage SharePoint Back-End functionality such as listing the profiles, adding new Sites etc. Most work using SQL Service Stored Procedures which is very fast since you are removing layers that reside between your application and your database storage. For more use the following link: SharePoint Back-End Protocols

The list above can be enhanced more with SharePoint 2010. With SharePoint 2010 we get some other methods listed as follows:

  • Microsoft SharePoint Foundation 2010 – Managed Client Object Model: The new client-side object model provides remote access to the functionality of the SharePoint Foundation server-side object model. In previous releases of SharePoint Foundation, SOAP Web services provided access to only a fraction of the server-side object model, but in SharePoint Foundation 2010, the client object model fills many of the gaps. For more information: Managed Client Object Model
  • Microsoft SharePoint Foundation 2010 – REST Interfaces: The new SharePoint Foundation REST interface exposes lists and libraries as a relational data service, and serves as a standards-based interface for interoperability with other platforms. More details can be found at the following URL: REST Interface

In my case I was using SharePoint 2007 and I have fully utilized the last 3 methods of access for SharePoint 2007. My WCF services host is a part of SharePoint farm. This lets me to access the SharePoint .NET API and perform the Create, Update and Delete operations against my data that resides on SharePoint. I use RPC to list all my data. This covers my CRUD against any data object. For some heavy load operations, such as listing all the profiles in SharePoint, I use SharePoint Back-End protocols. I use SharePoint Sites structure to structure the data and in each site I have blogs and threaded discussion lists that I let my users work on. Exposing all this functionality by encapsulating them in a WCF layer lets any UI technology utilize my solution.

I am planning to provide more details of each protocol in following posts under this title – of course as long as the time permits.