Dynamic creation of Sharepoint WSS Sites
Getting the most out of a Sharepoint project depends heavily on the degree of usage of the Sharepoint Portal Site and Windows Sharepoint Services architecture.
One of many cool ways to go is to define main business entities and create teamsites to support collaboration among information workers that interact with this entity. In technical terms this usually means getting information from a backend system (ERP, CRM, custom databases and so forth) and populating a teamsite with custom and standard webparts on-the-fly. This provides easier access to backend information plus the value added by the collaboration features in Sharepoint.
We have implemented a Sharepoint Solution integrated with Navision Axapta for several lawfirms lately. The main business entity in question in our domain is the Case.
So the question is; How to support creation of WSS sites for existing and new cases in the ERP system with no user or administrator interaction. We came up with the following solution.
The ERP system is defined as the canonical data source, and search is performed directly against Axapta through a custom integration and service layer. The actual site creation logic could not be done on case creation in the portal, because cases can also be created in the ERP system. We defined a single point of entry to case sites from the main axapta search form in a portal area. We set the links for the returned cases to redirect via a SiteGenerator/Redirector page that performs purely Sharepoint logic to see whether the site already exists, and if not creates it. The creation is done based on a pre-defined stp template containing all custom and standard webparts needed. Webpart properties are set for the custom webparts to make them show the proper data from the service layer->integration layer->ERP.
But you have to watch out. Sharepoint is said to support ~10k subsites per site (anyone tested this?), but a little bird also told us to avoid exceeding ~2k sites. So we decided that there should be no more than a thousand subsites for any sites. Because the site URL pattern (the generated URL to each case-site) is important to the customer we needed to take their needs in consideration.
We decided to use the id (primary key) for each entity as a token. Doing an analysis of the business domain, and the format of the id's used we decided on the following pattern to avoid breaking the 1000 site limit:
http://portal/rootForGeneratedSites/bucket1/bucket2/token
We needed to generate buckets that would not likely ever exceed ~1k sites. The id generation in the ERP system allowed us to set bucket1 = token.SubString(0,2) and bucket2 = token.SubString(0,5). Exemplified when using a regular case id like "99555-754" as a token:
http://portal/rootForGeneratedSites/99/99555/99555-754/
Furthermore we didn't actually want to use the buckets for anything useful, but they still need to be sites (to allow navigation in Office). Because of this we implemented a custom template both for the bucket "sites" and the actual case sites with content. The bucket sites are created with the portal admin as site admin, in contrary to the case sites which uses the case responsible fetched from the ERP system.
A quirk I'd like to get rid of is the fact that the "rootForGeneratedSites" folder is actually no site at the moment. It's a Sharepoint included path like the "sites" and "personal". Is feels uncomfortable because there is no top-level root. The customer objects to another level in the url pattern so we'll stick to it, but why, I ask, why have this void in the structure.
This issue is vital for this solutions ability to scale with the amount of business entities in the ERP system and still maintains a usable URL patterns for the end-users. The morale is; watch out when auto-generating sites.