Application Instance Resolution
Due to security and scale constraints, information in SharePoint is often logically partitioned between site collections. However often a set of site collections logically makes up a single logical group. Application instance resolution is a pattern for correctly
identifying the location of information within a logical grouping.
For example, assume that a company maintains extranet workspaces for its partners. The company decides to partition the partners' workspaces into separate site collections. This allows the company to easily maintain security permissions and to distinguish
the content intended for one partner from the content intended for another partner.
But when information is partitioned logically in such a way, a way for resolving where the appropriate information is located becomes critical. For example, let's continue with the scenario regarding the resolving a business event. One of the key aspects
of the solution described in the
Event-driven Site Creation
topic is the concept of knowing where a site should be created. When an incident is reported, it is associated with a specific partner. When creating the sub site for managing that particular incident, the sub site creation process
must be able to properly identify the site collection of that partner. Requiring a user to intervene and provide a URL for the site collection where the sub site should be created can cause delays in the sub site creation process. It is also more susceptible
to human errors. By placing a mechanism for resolving a partner's site collection, the integration between the CRM system and the Partner Portal is streamlined and less error prone.
We can also take a look at another example in the form of the partner redirect page. When creating site collections for partners, Contoso uses managed paths in the address of each of their partners' site collections. For instance, Fabrikam, partner of Contoso,
will use the URL of "http://extranet.contoso.com/partners/Fabrikam
". Users from Fabrikam will need to remember the full URL every time they want to visit their collaboration portal. With
a redirect logic in place, partners can remember a shorter address such as "http://extranet.contoso.com
" and be redirected to their collaboration portal.
To implement an application instance resolution pattern, you can create a mapping that relates an entity with an URL. In our example, a partner is the entity that defines the site collection partitions. The mapping can be implemented as a SharePoint list. Minimally
this list should contain a field for the entity that maps to a site collection, and a field for the URL of a particular site collection.
Additionally, developers can use the Site Directory feature of Microsoft Office SharePoint Server 2007. The Site Directory is a Site Definition that is provided by MOSS. It maintains a central location for URLs of SharePoint sites and external links. The Site
Directory is essentially made up of a list of URLs along with the related metadata such as categories. It also provides a set of tabbed pages for displaying the URLs in different views. The Site Directory can be customized to include custom fields in the sites
list and custom tabbed pages. For example a custom field for the Partner identifier can be added to the "Sites" list in the Site Directory. By adding metadata in the form of fields to the sites list, you can turn a Site Directory into a mapping list
for resolving sites.
Once a list is defined for the mapping, business logic must be in place for querying that mapping. The query logic can be as simple as returning a item that matches the entity identifier to something that is more complex.
The following figure illustrates the Partner Portal implementation of the site resolution pattern.
Partner redirect example using the application instance resolution pattern
Cannot resolve image macro, invalid image name or id.
In the Partner Portal, the business logic for resolving the correct site collection is very simple. It simple queries for the list item in the "Sites" list for a given Partner Id. But other businesses may require more complex business logic. Accommodating
complex business logic through configuration using a list may prove to be a difficult challenge.
Security concerns should also be considered. One of the challenges of using lists for a mapping store is that users will need access to it. The site collection mapping list should be considered sensitive information, and permissions should be restricted to
administrators and other users that require access. There will be cases when the mapping list must be accessed during the context of an underprivileged user. For instance, in the partner redirect page, the business logic must query the "Sites" list
to retrieve the site collection of the currently logged in user. In this case the business logic must run with elevated privileges, or a service must be created to retrieve this information on behalf of the user.
To give feedback.
Copyright (c) 2007 by Microsoft Corporation. All rights reserved.