harePoint has a very extensive API that connects to almost any part of the SharePoint functionality through your code. With SharePoint 2003 Microsoft has re-written most of the base API using .NET. Because it is now fully .NET-based, the SharePoint API gives you the full power of the .NET framework in manipulating the various aspects of a SharePoint portal. The API gives you access to manipulate almost the entire SharePoint object model.

There are two ways to manipulate SharePoint Portal objects. One is using the SharePoint Object Model API and other is connecting to the Web service interfaces exposed by SharePoint and using the functionality given. The former provides more power and control over almost all parts of SharePoint, while the latter is good to use if you want to use a non-.NET-based language or you want to manipulate the site parameters from an external machine.

Introducing Widgets, Inc.
One of the most common tasks in migrating the existing documents of any company to the SharePoint-based Intranet/Internet site, is to create proper area structures and add documents to them, so that the documents are logically ordered and sorted. This logical separation helps users find the required information quickly when they navigate through the proper area structure.

SharePoint Areas help organize and logically divide the information of any Website into various small sections. A section may be a document library, or pages with custom Web parts, displaying data based on the current area.

The sample case discussed in this article revolves round a hypothetical organization called Widgets Inc. who manufacture and sell widgets. Widgets Inc. keeps detailed records of all their many customers and their entire business revolves round proper and up to date customer information. They would like to organize all this customer data into a Sales Portal, for easy access by their sales team.

Presently, they store their customer information under various heads, like “Proposals,” “Invoices,” “Contact Details,” “Business Research,” and “Contracts.” The main problem in migrating all this information to their Sales Portal is that someone has to create all these folder structures as areas.

Figure 1. Area Hierarchy: The image shows the area hierarchy for storing documents.

Based on the above scenario, there are three obvious solutions you can use in order to meet Widgets Inc.’s objective:

1. Manual creation: You would need to sit and create the entire list of sub areas under the main Customers area?a very error-prone and time-consuming process. And what if you wanted to add another sub-area under each customer or rename a particular area?
2. Use a commercial tool: This would automate the manual process, speeding it up and making it error-free. The main problem with a commercial tool is that it may not be flexible enough to render your area structure exactly the way you want it to look. Don’t forget that there’s also a cost involved in buying a tool, along with the accompanying learning curve.
3. Build your own utility: This requires good technical knowledge and will take some time, but is a cost-effective way to end up with a solution fully-customized to your exact specifications.

With some quick coding and effective use of the SharePoint API, you can create your own Area Creator utility that you can use to automate this otherwise cumbersome and error-prone process.

The Solution
First, you’ll need a reference area structure as input. This will function as a template to the areas and subareas you need to create from the utility. Put the reference area structure in an XML file and use it as a reference while creating all the subareas under each customer. The goal is to build a quick-usage utility that any user can run. The external XML files need to be bundled along with the utility. The person running it should also remember to edit the XML in case the folder structure needs to be modified.

Another way to do this is to create a hidden area in SPS itself which will replicate the exact folder structure you need. You can use it as a reference area, read it using the SharePoint API, and as a guide to create subareas under each customer area. Next, you will need a list of customers based on which areas will be created. This utility application uses hard coded values for the customer list, but you can modify the code to read the customer list from a database, flat file, or even an existing Sales/Lead Management application.

The SharePoint namespaces to include are:

using Microsoft.SharePoint.Portal;using Microsoft.SharePoint.Portal.SiteData;using Microsoft.SharePoint.Portal.Topology;

In order to do anything with the SharePoint Portal, the code first needs to connect to the SharePoint Portal Server instance:

PortalContext portalContext = null;TopologyManager topologyManager = new TopologyManager();Uri uri = new Uri(strURL);PortalSiteCollection sites =  topologyManager.PortalSites;portalContext = PortalApplication.GetContext(sites[uri]);

The above code establishes a connection to the running instance of the SharePoint Portal Server and gets a reference to the site pointed by the strURL variable. Once you’ve got the context of the site you want your areas in, go to the topics area, and the Customers area under it.

Guid topicsGuid = AreaManager.GetSystemAreaGuid( portalContext, SystemArea.Topics );Area topicsArea = AreaManager.GetArea( portalContext, topicsGuid);Area rootArea = null;foreach(Area subArea in topicsArea.Areas){	if(subArea.Title == "Customers")	{		rootArea = subArea;	}}

The above code uses the Customers area, which is under the main Topics area, as the base root area. Manually create a hidden area in it called Customer Template Area, and create the structure tree underneath as depicted in Figure 1.

Next, find the hidden area that you’ll be using as a template and replicate its structure:

foreach(Area subArea in rootArea.Areas){	if(subArea.Title == "Customer Template Area")		return subArea;}

The above code enumerates all the subareas under the Customer area, which is the root Area, finds the area called the “Customer Template Area” and returns a handle. Use this to read the area tree structure, and replicate the area tree structure under each customer’s area.

Now that you’re ready to replicate the root area and the template area for all customers, you need a list of customers. This list can be read from a database, XML file, text file, or any other data source. For this example, just populate an Arraylist manually and use it as the list of customers:

newAreas.Add("Customer A");newAreas.Add("Customer B");newAreas.Add("Customer C");

Now, create an area for each customer in your list and recursively create all the subareas under the customer areas:

private void CreateArea(Area SourceArea, Area TargetArea, string title){	Area newArea = TargetArea.Areas.AddArea(title,TargetArea.Web.Name,SourceArea.AreaTemplate.ToString(),TargetArea.Web.Site);		foreach(Area subArea in SourceArea.Areas)	{		CreateArea(subArea,newArea,subArea.Title);	}}

You’ve just successfully replicated the template area structure for each and every customer in your customer list. The full code is displayed in Listing 1.

Further Extensions
This utility can be further extended in numerous ways. For starters, you can hook the code up with some document library handling to automatically replicate your current Windows folder structure, as well as upload the documents in the Windows folders to your SharePoint document library are area listings for each subarea.

You can use it to recursively enumerate through the entire area structure and create hierarchical navigation for your portal. Or use it to compare the existing areas to a template structure and update/delete the subareas, thus synchronizing them to the template structure. You can also use it to delete all the area structures or selectively delete particular areas.

There are endless possibilities on how you can modify this code provided in Listing 1, to suit your needs and get your work done exactly the way you want it.