Site Sections
Posts
48
Comments
32
Trackbacks
0
August 2009 Entries
Mission Imposible Part 1 (introduction)
I feel a series coming on! I have been involved with a client to develop and customize their present SharePoint Environment. I have incorporated several solutions I would like to share. It was a learning experience and it was definitely Fringe SharePoint!!! The purpose of this post is to set up the scenario and to describe all the factors that were involved with the decision making of the overall solution. I hit several walls and blocking issues and feel it's important for anyone doing anything remotely close to this or maybe incorporating parts of this solution to understand.

This customer has a fairly common portal. I will try to describe the portal in generic terms, it is not important to understand the specific purpose of sub sites but to understand the overall structure of sites. The environment looks like the following:



The above is pretty common in companies. Usually there is only one company but I am using this example to show the hierarchy relationship of sites. This specific company was getting quite a bit of growth on the departments sites. It was expecting quite a bit of growth in the future and wanted to manage the quota at the department level. 

Problem 1: you cannot place quota on sub sites. It can only be set at the Site collection level.

The next thing that the client was complaining about was the fact that departments moved companies. In the present environment a department site needed to be moved(imported/exported) to other locations(Companies).

Problem 2: No way for companies to be able to move sites without having more than desired access to the site and server.

From an admin perspective, it is getting tougher and tougher to maintain the site collection because of the growing quota. Maintaining site quota to 100G recommended limit from Microsoft will very quickly be exceeded.

Problem 3: In order to manage content database size you will need to have a little more complicated process to provisioning new sites. Or create and manage Web Application to house a section of the sites so they are created under a new content database.

One thing I should mention is that several extensions of a web Application have been created to expose the sites with anonymous access, SSL and basic authentication schemes. Using the diagram above, it is desired that everyone inside and outside the company be able to access the Company level of the site collection. This part of the site is to be exposed anymously, Once navigating to the department level, it is desired that authentication occurs at that point. The department sites would need to be exposed over SSL.

Each Company has a webpart that lists all the department sites under that company. This web part has evolved over time, to satisfy and work under changing security schemes. It first started as a dataview webpart. Issues were encountered with the authentication of the connection string. It then was re-engeneered to be a visual studio web part and pull sub sites relative to the company the webpart was added to. The functionality of the webpart is really to list all the department sites by name and have a clickable link to them.

I feel like this is getting really long winded but In my next post I will describe the overall solution and split it up into sections that you can develop yourself as you see fit and just tackle one problem at a time.


Stay tuned!

Juan

 
Posted On Tuesday, August 25, 2009 7:25 PM | Feedback (0)
Extending SharePoint: Checking if a List exists (Web Services)
During my project that is heavily centered around web services, I often found that before I could execute one overall integration, I would need about 3 or 4 web Service calls to collect all the parameters I needed to actually call the web service call I was really trying to execute. I came across an interesting situation where I need to retrieve the List from SharePoint. A web service call will send back an XMLElement with all the information available for a list. The problem is that the list needs to exist for a web service call to succesfully execute. If the list does not exist then it will return an exception.

This is more along the lines of what I was implementing: (the object '_service' is the the instantiated ListSoapClient that is available through WCF to make my calls)

 private XmlElement GetListWSCall(string listName)
        {
           XmlElement retval = null;
            try
            {
                retval =  _service.GetList(listName);
               
            }
            catch (Exception ex)
            {
                retval = null;
            }
            return retval;
        }

The problem with this is that if the Library does not exist it will be handled by an exception. Bill Simser wrote a good article on this already, so please read his blog post about this issue. What I would like to point out is my solution for the web service call not the object model he worked with. Same concept though.

I wrote a method as well that would check if the List exited in SharePoint. I simply got all the lists for a given endpoint and then used Linq to get at the document library name. It looks like this:

 public bool DocLibExists(string listName)
        {
            try
            {
                var allLists = _service.GetListCollection();
               
               return allLists.ChildNodes.OfType<XmlElement>().ToList().Exists(x => x.Attributes["Title"].Value ==listName);
            }
            catch (Exception ex)
            {
              //handle whatever connection error you might get form the web service call.
            }
            return false;
        }

I have really replaced all of my "foreach" statements and even the typical Linq statments by this somewhat daisy chain of linq query calls. It makes for tighter code as long as the daisy chain does not get huge.  Your result set you get back is really an XmlElement with child nodes that are represent a list in SharePoint. All you are really after in this scenario is the "Attributes". When you debug and inspect the XmlElement you can take a look at all the Attributes and adjust your code accordingly to get what you are really after.


That's all for now, More to come!

Juan
Posted On Wednesday, August 19, 2009 5:39 PM | Feedback (2)
Unexpected WCF web Service Behaviour
          I am currently on a project that consists of an integration between a web application and SharePoint. Both applications live in their own servers and so it was necessary to use web services. I have come to many weird glitches and many unresolved issues at this time, I will make an effort to document as much as possible to save people time when working with WCF, SharePoint Web Services, and Visual Studio 2008.0

The first issue I'm going to write about is fairly easy to identify but it was frustrating dealing with.

The code that I wrote looked something like this:

        _service.UpdateList(listID, GetDocLibNameChange(newListName),null, null, null, listVersion);

The _service is the ListSoapClient that I have access to through WCF. I simply update the name of the document library to something else. I feel I should post the code for the update XmlElement, there is detailed information and documentation on updating just about everything about a document library. This scenario was real simple, I only needed the ability to change the document library name. This is the code for the GetDocLibNameChange() method that puts together that XmlElement:

private XmlElement GetDocLibNameChange(string newName)
        {
            var xmlDoc = new XmlDocument();
            var elBatch = xmlDoc.CreateElement("List");
            elBatch.SetAttribute("Title", newName);
            return elBatch;
        }


That's it! Almost, I was getting a weird outcome where when I executed the UpdateList web service method I was getting an exception. Of course the exeption was a generic SOAP Exception, which I could not make tails of, and really couldn't because there was not much more than just Soap Exception.  It turns out that the Update was still occuring!! So, update worked but exception was coming back!

 SOLUTION:
    If you read MSND page on this method, it specifies that the ListID is really a string of the list guid: "{GUID}". It turns out I got careless and was just passing in the list name. Note to self, pass in the expected paramaters!!! I felt like bloggint this to show 2 things:
    1) The update still occured even with the excpetion.
    2) How useless the soap exception messages and stack trace really are!

 Happy Coding!

Juan
Posted On Wednesday, August 19, 2009 5:17 PM | Feedback (0)
Archives
Post Categories
Twitter










Tag Cloud