INTRODUCTION
If you are a SharePoint developer you know that there are two basic ways to develop against SharePoint. 1)
The object Model 2) Web services.
SharePoint object model has
the advantage of being quite rich. Anything you can do through
the SharePoint UI as an administrator or end user, you can do through
the object model. In fact everything that is done through
the UI is done through
the object model behind
the scenes.
The major disadvantage to getting at SharePoint this way is that
the code needs to run on
the server. This means that all web parts, event receivers, features, etc… all of this is code that is deployed to
the server.
The second way to
get to SharePoint is through
the built in web services. There are many articles on how to manipulate web services, how to authenticate to them and interact with them.
The basic idea is that a remote application or process can contact SharePoint through a web service. Lots has been written about how great these web services are. This article is written to document
the limitations, some of
the issues and frustrations with working with SharePoint built in web services. Ultimately, for
the tasks I was given to , SharePoint built in web services did not suffice.
My evaluation of SharePoint built in services was compared against creating my own WCF Services to do what I needed.
The current project I'm working on right now involved several "integration points". A remote application, installed on a separate server was to contact SharePoint and perform an task or operation. So I decided to start up Visual Studio and built a DLL and basically have 2 layers of logic. An integration layer and a data layer. A good friend of mine pointed me to SOLID principles and referred me to some videos and tutorials about it. I decided to implement
the methodology (although a lot of
the principles are common sense and I already incorporated in my coding practices). I was to deliver this dll to
the application team and they would simply call
the methods exposed by this dll and voila! it would do some task or operation in SharePoint.
SOLUTION
My integration layer implemented an interface that defined some of
the basic integration tasks that I was to put together. My data layer was about
the same, it implemented an interface with some of
the tasks that I was going to develop. This gave me
the opportunity to develop different data layers, ultimately different ways to
get at SharePoint if I needed to. This is a classic SOLID principle. In this case it proved to be quite helpful because I wrote one data layer completely implementing SharePoint built in Web Services and another implementing my own WCF Service that I wrote. I should mention there is another layer underneath
the data layer. In referencing SharePoint or WCF services in my visual studio project I created a class for every web service call. So for example, if I used List.asx. I created a class called "DocumentRetreival" this class would do
the grunt work to connect to
the correct URL, It would perform
the basic operation of contacting
the service and so on. If I used a view.asmx, I implemented a class called "ViewRetrieval" with
the same idea as
the last class but it would now interact with all he operations in view.asmx. This gave my data layer
the ability to perform multiple calls without really worrying about some of
the grunt work each class performs. This again, is a classic SOLID principle.
So, in order to compare them side by side we can look at both data layers and with is involved in each. Lets take a look at
the "Create Project" task or operation.
The integration point is described as , "dll is to provide a way to create a project in SharePoint". Projects , in this case are basically document libraries. I am to implement a way in which a remote application can create a document library in SharePoint. Easy enough right? Use
the list.asmx Web service in SharePoint. So here we go! Lets take a look at
the code.
I added
the List.asmx web service reference to my project and this is
the class that contacts it:
class DocumentRetrieval
{
private ListsSoapClient _service;
d private bool _impersonation;
public DocumentRetrieval(bool impersonation, string endpt)
{
_service = new ListsSoapClient();
this.SetEndPoint(string.Format("{0}/{1}", endpt, ConfigurationManager.AppSettings["List"]));
_impersonation = impersonation;
if (_impersonation)
{
_service.ClientCredentials.Windows.ClientCredential.Password = ConfigurationManager.AppSettings["password"];
_service.ClientCredentials.Windows.ClientCredential.UserName = ConfigurationManager.AppSettings["username"];
_service.ClientCredentials.Windows.AllowedImpersonationLevel =
System.Security.Principal.TokenImpersonationLevel.Impersonation;
}
private void SetEndPoint(string p)
{
_service.Endpoint.Address = new EndpointAddress(p);
}
/// <summary>
/// Creates a document library with specific name and templateID
/// </summary>
/// <param name="listName">New list name</param>
/// <param name="templateID">Template ID</param>
/// <returns></returns>
public XmlElement CreateLibrary(string listName, int templateID, ref ExceptionContract exContract)
{
XmlDocument sample = new XmlDocument();
XmlElement viewCol = sample.CreateElement("Empty");
try
{
_service.Open();
viewCol = _service.AddList(listName, "", templateID);
}
catch (Exception ex)
{
exContract = new ExceptionContract("DocumentRetrieval/CreateLibrary", ex.GetType(), "Connection Error", ex.StackTrace, ExceptionContract.ExceptionCode.error);
}finally
{
_service.Close();
}
return viewCol;
}
}
There was a lot more in this class (that I am not including) because i was reusing
the grunt work and making other operations with LIst.asmx, For example, updating content types, changing or configuring lists or document libraries.
One of
the first things I noticed about working with
the built in services is that you are really at
the mercy of what is available to you. Before creating a document library (Project) I wanted to expose a IsProjectExisting method. This way
the integration or data layer could recognize if a library already exists. Well there is no service call or method available to do that check. So this is what I wrote:
public bool DocLibExists(string listName, ref ExceptionContract exContract)
{
try
{
var allLists = _service.GetListCollection();
return allLists.ChildNodes.OfType<XmlElement>().ToList().Exists(x => x.Attributes["
Title"].Value ==listName);
}
catch (Exception ex)
{
exContract = new ExceptionContract("DocumentRetrieval/GetList/GetListWSCall", ex.GetType(), "Unable to Retrieve List Collection", ex.StackTrace, ExceptionContract.ExceptionCode.error);
}
return false;
}
This really just gets an XMLElement with all
the lists. It was then up to me to sift through
the clutter and noise and see if Document library already existed. This took a little bit of getting used to. Now instead of working with code, you are working with XMLElement response format from web service. I wrote a LINQ query to go through and find if
the attribute "
Title" existed and had a value of
the listname then it would return True, if not False. I didn't particularly like working this way. Dealing with XMLElement responses and then having to manipulate it to
get at
the exact data I was looking for. Once
the check for
the DocLibExists, was done, I would either create
the document library or send back an error indicating
the document library already existed.
Now lets examine
the code that actually creates
the document library. It does what you are really after, it creates a document library. Notice how
the template ID is really an integer. Every document library template in SharePoint has an ID associated with it. Document libraries, Image Library, Custom List, Project Tasks, etc… they all he a unique integer associated with it. Well, that's great but
the client came back to me and gave me some specifics that each "project" or document library, should have. They specified they had 3 types of projects. Each project would have unique views, about 10 views for each project. Each Project specified unique configurations (auditing, versioning, content types, etc…) So what turned out to be a simple implementation of creating a document library as a repository for a project, turned out to be quite involved.
The first thing I thought of was to create a template for document library. There are other ways you can do this too. Using
the web Service call, you could configure views, versioning, even content types, etc…
the only catch is, you have to be working quite extensively with CAML. I am not fond of CAML. I can do it and work with it, I just don't like doing it. It is quite touchy and at times it is quite tough to understand where errors were made with CAML statements. Working with Web Services and CAML proved to be quite annoying.
The service call would return a generic error message that did not particularly point me to a CAML statement syntax error, or even a CAML error. I was not sure if it was a security , performance or code based issue. It was quite tough to work with. At times it was difficult to work with because of
the way SharePoint handles metadata. There are "Names", "Display Name", and "StaticName" fields. It was quite tough to understand at times, which one to use. So it took a lot of trial and error. There are tools that can help with CAML generation. There is also now intellisense for CAML statements in Visual Studio that might help but ultimately I'm not fond of CAML with Web Services.
So I decided on
the template. So my plan was to create create a document library, configure it accordingly and then use
The Template Builder that comes with
the SharePoint SDK. This tool allows you to create site templates, list template etc… It is quite interesting because it does not generate an STP file, it actually generates an xml definition and a feature you can activate and make that template available on a site or site collection.
The first issue I experienced with this is that one of
the specifications to this template was that
the "All Documents" view was to have 2 web parts on it. Well, it turns out that using
the template builder , it did not include
the web parts as part of
the list template definition it generated. It backed up
the settings,
the views,
the content types but not
the custom web parts. I still decided to try this even without
the web parts on
the page. This new template defined a new Document library definition with a unique ID.
The problem was that
the service call accepts an int but it only has access to
the built in library int definitions. Any new ones added or created will not be available to create. So this made it impossible for me to approach
the problem this way.
I should also mention that one of
the nice features about SharePoint is
the ability to create list templates, back them up and then create lists based on that template. It can all be done by end user administrators. These templates are quite unique because they are saved as an STP file and not an xml definition. I also went this route and tried to see if there was another service call where I could create a document library based no given template name. Nope! none.
After some thinking I decide to implement a WCF service to do this creation for me. I was quite certain that
the object model would allow me to create document libraries base on a template in which an ID was required and also templates saved as STP files. Now I don't want to bother with posting
the code to contact WCF service because it's self explanatory, but I will post
the code that I used to create a list with custom template.
public ServiceResult CreateProject(string name, string templateName, string projectId)
{
string siteurl = SPContext.Current.Site.Url;
Guid webguid = SPContext.Current.Web.ID;
using (SPSite site = new SPSite(siteurl))
{
using (SPWeb rootweb = site.RootWeb)
{
SPListTemplateCollection temps = site.GetCustomListTemplates(rootweb);
ProcessWeb(siteurl, webguid, web => Act_CreateProject(web, name, templateName, projectId, temps));
}//SpWeb
}//SPSite
return _globalResult;
}
private void Act_CreateProject(SPWeb targetsite, string name, string templateName, string projectId, SPListTemplateCollection temps) {
var temp = temps.Cast<SPListTemplate>().FirstOrDefault(x => x.Name.Equals(templateName));
if (temp != null)
{
try
{
Guid listGuid = targetsite.Lists.Add(name, "", temp);
SPList newList = targetsite.Lists[listGuid];
_globalResult = new ServiceResult(true, "Success", "Success");
}
catch (Exception ex)
{
_globalResult = new ServiceResult(false, (string.IsNullOrEmpty(ex.Message) ? "None" : ex.Message + " " + templateName), ex.StackTrace.ToString());
}
}
private void ProcessWeb(string siteurl, Guid webguid, Action<SPWeb> action) {
using (SPSite sitecollection = new SPSite(siteurl)) {
using (SPWeb web = sitecollection.AllWebs[webguid]) {
action(web);
}
}
}
This code is actually some of
the code I implemented for
the service. there was a lot more I did on Project Creation which I will cover in my next blog post. I implemented an ACTION method to process
the web. This allowed me to properly dispose
the SPWEb and SPSite objects and not rewrite this code over and over again.
So I implemented a WCF service to create projects for me, this allowed me to do a lot more than just create a document library with a template, it now gave me
the flexibility to do just about anything
the client wanted at project creation. Once this was implemented ,
the client came back to me and said, "we reference all our projects with ID's in our application. we want SharePoint to do
the same". This has been something I have been doing for a little while now but I do hope that SharePoint 2010 can have more of an answer to this and address it properly. I have been adding metadata to SPWebs through property bag. I believe I have blogged about it before. This time it required metadata added to a document library. No problem!!! I also mentioned these web parts that were to go on
the "All Documents" View. I took
the opportunity to configure them to
the appropriate settings. There were two settings that needed to be set on these web parts. One of them was a Project ID configured in
the webpart properties.
The following code enhances and replaces
the "Act_CreateProject " method above:
private void Act_CreateProject(SPWeb targetsite, string name, string templateName, string projectId, SPListTemplateCollection temps) {
var temp = temps.Cast<SPListTemplate>().FirstOrDefault(x => x.Name.Equals(templateName));
if (temp != null)
{
SPLimitedWebPartManager wpmgr = null;
try
{
Guid listGuid = targetsite.Lists.Add(name, "", temp);
SPList newList = targetsite.Lists[listGuid];
SPFolder rootFolder = newList.RootFolder;
rootFolder.Properties.Add(KEY, projectId);
rootFolder.Update();
if (rootFolder.ParentWeb != targetsite)
rootFolder.ParentWeb.Dispose();
if (!templateName.Contains("Natural"))
{
SPView alldocumentsview = newList.Views.Cast<SPView>().FirstOrDefault(x => x.
Title.Equals(ALLDOCUMENTS));
SPFile alldocfile = targetsite.GetFile(alldocumentsview.ServerRelativeUrl);
wpmgr = alldocfile.GetLimitedWebPartManager(PersonalizationScope.Shared);
ConfigureWebPart(wpmgr, projectId, CUSTOMWPNAME);
alldocfile.Update();
}
if (newList.ParentWeb != targetsite)
newList.ParentWeb.Dispose();
_globalResult = new ServiceResult(true, "Success", "Success");
}
catch (Exception ex)
{
_globalResult = new ServiceResult(false, (string.IsNullOrEmpty(ex.Message) ? "None" : ex.Message + " " + templateName), ex.StackTrace.ToString());
}
finally
{
if (wpmgr != null)
{
wpmgr.Web.Dispose();
wpmgr.Dispose();
}
}
}
}
private void ConfigureWebPart(SPLimitedWebPartManager mgr, string prjId, string webpartname)
{
var wp = mgr.WebParts.Cast<System.Web.UI.WebControls.WebParts.WebPart>().FirstOrDefault(x => x.DisplayTitle.Equals(webpartname));
if (wp != null)
{
(wp as ListRelationshipWebPart.ListRelationshipWebPart).ProjectID = prjId;
mgr.SaveChanges(wp);
}
}
This Shows you how I was able to set metadata on
the document library. It has to be added to
the RootFolder of
the document library, Unfortunately,
the SPList does not have a Property bag that I can add a key\value pair to. It has to be done on
the root folder. Now everything in
the integration will reference projects by ID's and will not care about names. My, "DocLibExists" will now need to be changed because a web service is not set up to look at property bags. I had to write another method on
the Service to do
the equivalent but with ID's instead of names.
The second thing you will notice about
the code is
the use of
the Webpartmanager. I have seen several examples online, and also read a lot about memory leaks,
The above code does not produce memory leaks.
The web part manager creates an SPWeb, so just dispose it like I did.
CONCLUSION
This is a long long post so I will stop here for now, I will continue with more comparisons and limitations in my next post. My conclusion for this example is that Web Services will do
the trick if you can suffer through CAML and if you are doing some simple operations. For Everything else, there's WCF!
**** fireI apologize for
the disorganization of this post, I was on a bus on a 12 hour trip to IOWA while I wrote it, I was half asleep and half awake, hopefully it makes enough sense to someone.
