Karine Bosch’s Blog

On SharePoint

Part 7: SharePoint classes that use built-in caching techniques


There are a number of SharePoint classes that have a built-in caching functionality:

  • PortalSiteMapProvider
  • CrossListQueryCache

PortalSiteMapProvider

The PortalSiteMapProvider is a part of the SharePoint Publishing API and is typically used by navigation controls. All results returned by methods of the PortalSiteMapProvider are automatically stored in the object cache.

The SiteMapProviders for SharePoint are defined in the web.config and some of the attributes can be configured, for example the IncludePages attribute. By default it is set to false but setting it to true will allow the SiteMapProvider to return not only web nodes with but also the published pages in the Pages library.

In the OnInit method you can define which SiteMapProvider to use. But you can also use the current SiteMapProvider.

SiteMapProvider siteMapProvider = SiteMap.Providers[siteMapProviderName];

Or

PortalSiteMapProvider portalProvider = PortalSiteMapProvider.CurrentNavSiteMapProvider;

You can also modify a number of properties of the SiteMapProvider within the OnInit method.

portalSiteMapProvider = siteMapProvider as PortalSiteMapProvider;                 
portalSiteMapProvider.DynamicChildLimit = 0;                 
portalSiteMapProvider.EncodeOutput = true;                 
portalSiteMapProvider.IncludePages = PortalSiteMapProvider.IncludeOption.Always;                 
portalSiteMapProvider.IncludeSubSites = PortalSiteMapProvider.IncludeOption.Never;

The construction of the navigation control is done in the CreateChildControls method. The following code snippet retrieves all pages with content type “Brewery Page” from the SiteMapProvider. By using the GetCachedListItemsByQuery method you specify that you want to use the built-in cache.

PortalWebSiteMapNode pagesNode =  portalSiteMapProvider.CurrentNode as PortalWebSiteMapNode;
// get all the brewery pages
SPQuery query = new SPQuery();
query.Query = "<Where><Eq><FieldRef Name=\"ContentType\" />”
       +  “<Value>Brewery Page</Value></Eq></Where>";              
SiteMapNodeCollection pageNodes =  portalSiteMapProvider.GetCachedListItemsByQuery(
    pagesNode, "Pages", query, SPContext.Current.Web);

All nodes returned by the provider are of type PortalSiteMapNode and may be safely cast to this type. The class exposes a number of properties, some of which are related to navigation specifically, but also properties like Title, Description and UniqueId. The Type property provides information about the node’s internal type, and may be used to determine if casting to a more specific type of PortalSiteMapNode is possible. Each specific type has its own additional properties.

In this code sample the GetCachedListItemsByQuery method specifically requires the pageNode to be of type PortalWebSiteMapNode, and that’s why it is casted to this specific type.

2 Comments »

  1. Hi, I have a question about caching. I have a client running SharePoint 2010 Enterprise that uses a lot of custom XSLT views. Every few weeks, the users start seeing random “webpart cannot be displayed” errors on these web parts. I have adjusted caching several times. Each time, the problem appears to be corrected, only to reappear a week or so later. My question is — How do you determine what is the ideal caching value?

    Comment by Kim | March 7, 2014 | Reply

    • Hi Kim, it really depends on how fresh your data must be: this can be an hour, but it can also be a day or a week. The webpart error can be everything. Are you sure it has to do with the caching? If so, which method do you use to retrieve data from cache? If the cache is empty, do you also fill it with data? If you have a correlation ID, you can look into the ULS logs and try to find more details about your error.
      Karine

      Comment by Karine Bosch | March 10, 2014 | Reply


Leave a comment