Content Type Syndication (Publishing)

 In my previous post, I have discussed the Managed Metadata Service, or MMS. The service can be used to centralize and manage metadata that is used throughout an organization. In that article, I also mentioned that SharePoint 2010 introduced a new special column called the Managed Metadata column that can utilize terms from the Terms Store in the MMS. This post continues on that road and explores some of the concepts of centralizing another aspect of SharePoint, Content Types.

Sharing

To be honest, content types are not the only entities you can share using the MMS across multiple site collections. In fact, associated concepts can also be shared. These are:

• Content Types
• Policies
• Document Set Content Type
• Workflow associations

The latter is a special one. You can share the associations, but not the workflows themselves. You just need to ensure that the workflows are available where the associated content types are used. If not, the content type will work, but will not kick-off any workflows obviously.

Site Collection Hub

The MMS will consume and syndicate these items from a central store. This is called the Hub and each MMS can have only one Hub associated with it. This also means that if you would like to have separate Hubs, you need to create multiple instances of a MMS. This highly depends on the architectural decisions and landscape. For small organizations though, one hub will suffice. The Hub can be any site collection in your Farm, as long as the owner of the MMS service can access that site. I also noticed that once we have set a hub for a Managed Metadata service, it cannot be changed anymore. To change it, you would need to create a new Metadata Service, transfer the groups and terms and delete the old one. Quite a strange design choice.

All content types and associated policies and workflow associations created in the Hub can be published and made available through the hub and the service to other site collections.

Example

To demonstrate the use of the hub, as well as demonstrating the classes in the Microsoft.SharePoint.Taxonomy.ContentTypeSync namespace, I will provide an example where I will configure the Hub, assign it to a metadata service, create a content type that uses the Term Sets in the metadata service, create and publish this content type through code, consume the content type in a separate site collection and expand it there, update the content type in the hub through the UI, republish the content type and show the effects when it is pushed to the site collection again.

To start off, I will assume you have a Managed Metadata Service set up and running. In there, at least one Term Set should be present, containing several terms. If you are not clear on how to achieve this, take a look at my previous post regarding the Managed Metadata Service. I have mine steup like below:

Create two site collections, one will be the Hub, the other will be the consuming site. For the purpose of this post, I have a site at http://sp2010 which is my consumer site and a site at http://sp2010/sites/hub which is my Hub.

The second thing we need to do upfront is enabling the Taxonomy feature. Unfortunately, for reasons that are yet beyond me, this feature is hidden and not enabled, which is needed to use the Managed Metadata column type. Fortunately, this is a Farm feature so we need to enable it only once. But it would be better if this feature was just enabled by default. Run the following command using stsadm:

STSADM -o activatefeature -id 73EF14B1-13A9-416b-A9B5-ECECA2B0604C -url http://<server&gt; -force

Associating the Managed Metadata Service with the Hub site

So, now that we have the basic setup complete and prepared the environment, we need to connect the Managed Metadata Service to the Hub site collection. Within Central Administration, navigate to Manage Service Applications under Application Management. Select the Managed Metadata Service you wish to connect to the hub (to top row, not the connection below) and select Properties from the ribbon. On the bottom of the properties page, you can enter the url of the Site Collection hub. In my case, this is http://sp2010/sites/hub. Click OK to confirm.

The service is now connected to the Hub. In the Hub site collection, this has caused the activation of the Content Type Syndication Hub feature.

Creating the content type

Creating the content type can be done in two ways. Either through the user interface or through the object model. Personally, I prefer the latter, or rather, the hybrid approach, because it will more closely resemble our day to day life. We are not going to manually deploy content types right?

Create a new Visual Studio solution and add a Content Type element. Add another xml file to the content type element. Call it Fields.xml and set the deployment type to ElementManifest. In this file, we will define our managed metadata column. The actual wiring to the managed metadata store however must be done in code. Add the following xml to the file:

<?xml version=“1.0” encoding=“utf-8“ ?>
<Elements xmlns=“http://schemas.microsoft.com/sharepoint/“>
   <Field ID=“{A559CE6A-F2A5-4db9-BDC5-E6B84E1DF3A3}”
      Type=“TaxonomyFieldType”
      DisplayName=“Department“
      ShowField=“Term1033”
      Required=“FALSE“
      EnforceUniqueValues=“FALSE“
      Group=“Managed Fields”
      StaticName=“MyDepartment“
      Name=“MyDepartment” />
</Elements>

In here, you can see that the type of our field is the TaxonomyFieldType. The ShowField attribute indicates the language identifier, in this case English (1033). Add the field to our content type defined in the Elements.xml file.

<?xml version=“1.0” encoding=“utf-8“?>
<Elements xmlns=“http://schemas.microsoft.com/sharepoint/“>
   <!– Parent ContentType: Document (0x0101) –>
   <ContentType ID=“0x0101004a7f92eb8a7e40dbaa3fd17dbfaf751f”
      Name=“Boom.Taxonomy.Syndication – ManagedContentType”
      Group=“Published Content Types”
      Description=“My Managed Content Type”
      Inherits=“TRUE”
      Version=“0“>
      <FieldRefs>
         <FieldRef ID=“{A559CE6A-F2A5-4db9-BDC5-E6B84E1DF3A3}” Name=“MyDepartment“/>
      </FieldRefs>
   </ContentType>
</Elements>

We now need to wire the field to our metadata service, indicating the TermSet to use for the field. Add an event handler to the feature (ensure the feature scope is set to Site) and implement the FeatureActivated method as follows:

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
   // Connect to the site and use it to set up the TaxonomySession
   SPSite site = properties.Feature.Parent as SPSite;
   // Field ID
   Guid fieldId = new Guid(“{A559CE6A-F2A5-4db9-BDC5-E6B84E1DF3A3}”);
   if (site.RootWeb.Fields.Contains(fieldId))
   {
      // Set up the session again
      TaxonomySession session = new TaxonomySession(site);
      // Check for Term Stores.
      if (session.TermStores.Count != 0)
      {
         // Get the Term Store
         TermStore termStore = session.TermStores[“MyMMS”];
         // Get the group
         Group group = termStore.Groups[“ContentTypeSync”];
         // Get the Term Set
         TermSet termSet = group.TermSets[“Departments”];
         // Get the field using the ID
         TaxonomyField taxField = site.RootWeb.Fields[fieldId] as TaxonomyField;
         // Wire the properties to the managed metadata service.
         taxField.SspId = termSet.TermStore.Id;
         taxField.TermSetId = termSet.Id;
         taxField.TargetTemplate = string.Empty;
         taxField.AnchorId = Guid.Empty;
         taxField.Update();// Prepare publishing
         if (ContentTypePublisher.IsContentTypeSharingEnabled(site))
         {
            // Publishing allowed.
            ContentTypePublisher publisher = new ContentTypePublisher(site);
            // Publish the content type
            SPContentType cType = site.RootWeb.ContentTypes[new SPContentTypeId(“0x0101004a7f92eb8a7e40dbaa3fd17dbfaf751f”)];
            publisher.Publish(cType);

            if (!publisher.IsPublished(cType))
            {
               EventLog.WriteEntry(“Boom.Taxonomy.Syndication”, “Not published”);
            }
         }
      }
   }
}

Now, some of the classes we have already seen in the previous post. We connect to a TaxonomySession, grab the TermStore, Group and TermSet and use the objects to wire the TaxonomyField we created.

Publishing the content type

Once the wiring is complete, we use the ContentTypePublisher class to detect whether or not this site is a Content Type Syndication Hub. If so, we get an instance of the publisher and pass the content type to the Publish method. Finally, we check if the type was published properly.

Build and deploy the solution. If you activate the feature on the Hub site collection, you should see your newly created type in the Site Content Types list.

To check whether or not the content type works, you can create a document library and add the content type to the library. Then create a new document based on the type, which should start Word with a new document. In the server properties you should see your Managed Metadata field. If all works well suggestions will pop up as soon as you start typing. You can also click the search button, which shows your Term Set in a popup window, like below:

So, we now know that the field works. Now let us see how we can consume the type. Before we get to that point, thing to note here is that the publishing of the types is done through a Timer Job. Usually runs each hour, but can also be called manually. The job is called Content Type Subscriber. Be prepared to run it manually, or you will have to wait for an hour 😉

To import the published content type in our site collection, we navigate to Site Settings and find the Content type publishing option in the Site Collection Administration menu.

Open it and at the top, you will find an option to refresh all published content types during the next update.

Check the checkbox and click OK. Now to avoid waiting for the timer job to run, we will run it manually. Navigate to Central Administration, go to Job Definitions in the System Settings menu and click the Content Type Subscriber job. Click the Run Now button to run the job manually. Once done, navigate back to your site.

When you now go to your Site Content Types gallery in your subscriber site, you should see the published content type listed.

So, create a document library and add the content type to this library. Upload a document using this type and fill out the properties.

Notice that when you go to the list settings and navigate to the list content type, you cannot change it here. The only available option is Advanced Settings, which allows you to set a different template or make the type writable. (not read-only). Obviously, for published types, you should not do this. Remember that just like in SP 2007, content types in list are not references, but a local copy of the site collection content type. In SP 2007, making changes on the list level caused a ghosting (disconnect) of the content type for the site collection level, which made it very hard to manage. In SP 2010, this has improved a lot, as the connection remains and changes to the site collection type are merged with local changes.

To demonstrate, set the content type Read-Only property to No and add a field to the type, called Actual Work. After that, go to the Hub and apply a change to the Content Type by adding a field called Publisher. Once done, click the Manage publishing for this content type link and republish the type. Run the timer job and go back to your list in your subscriber site. Go to list settings and click the published content type.

As you can see, both the changes I made to the list content type, as well as the changes done in the content type in the Hub have been pushed down and merged. Cool isn’t it?

Conclusion

I hope above example showed you that indeed a lot of things have improved in SP 2010. The central management of content types and metadata has taken a huge step forward, taking us a step closer to consistency, ease of management and centralization. Hope you can use this to your advantage! You can download the example Visual Studio 2010 solution here.

Cu.

The Managed Metadata Service (MMS)

One of the biggest drawbacks of SharePoint 2007 was the management of content types, or rather, the lack of management of content types. Ensuring consistent content types across an enterprise sometimes drove me nuts, as well as the process to update and maintain them. Same goes for managing metadata.

For example, say I had a document content type called Contract that had a field called ContractType, I had several column types to choose from. I could use the lookup value from a list, which would give me flexibility in the contents, but required me to provision a list that is limited by the site collection boundary. If I would choose Choice, I would not have to provision a list, but my values in the column would be fixed and difficult to change across many sites.

Either way, adding, changing or removing metadata and their content types across several thousands of site collections was a big pain in the ****.

Well, Microsoft listened to these complaints and introduced the long awaited and personally my most favorite part in SharePoint 2010, the managed metadata service and content type syndication. The content type syndication will be part of the next article. In this article, we will focus on the managed metadata service and how we could use the API to control it.

 Managed Metadata Service (MMS)

Well, the word says it all. It is a service to centrally manage metadata (called terms) in a consistent, managed and hierarchical manner. You can have one or multiple services of this type, although depending on the size of your organization, it would be logical to use only one.

The managed metadata service contains a Terms Store, which holds all the terms that would have any meaning within your organization and provides ways to group them together. For example, say I have a couple of departments within my company called:

• Finance
• Sales
• Procurement
• Development
• R&D

Each of these names would be a term in the taxonomy database. Each term can then be grouped together in what we call a Term Set, in our case this could be Departments. Finally, you can group Term Sets into Groups, for example Business Entities. What kind of cool is though is that you can nest terms to form a hierarchy. So each term can have a parent term and so on. This could result in something like this:

• Business Entities (Group)
  • Departments (Term Set)
    • Finance
    • Sales
    • Procurement (Parent Term)
      • Hardware (Term)
      • Services
      • Software
    • Development
    • R&D

Each group can have a different set of people assigned as managers or contributors, so you have options to delegate the management of that group throughout your company. For each term set, you can designate stakeholders that should be informed when the content of a set changes.

It is also possible to import terms based on comma separated value (csv) files. This provides the ability to prepare term sets upfront and load them in bulk into the service.

Enterprise Keywords

Some more good news, all the terms your end-users enter with SharePoint 2010 list items (so the column values) are also gathered in the Enterprise Keywords store. This is an unmanaged store that gathers anything users upload to their sites. From this store, you can easily promote terms to managed terms in the hierarchy, providing you valuable feedback of frequently used words/phrases (terms).

Managed Metadata column

So, we now have this cool store with our hierarchy build up, but how do we actually use this? Well, SharePoint 2010 introduces a new column type, called the Managed Metadata column. In this column definition, we can specify the term set to be used for the column, so that the values selected are gathered from the managed metadata service. I a way, it is much like the Lookup field column, only instead of a list, you now target the term set as the source.

Taxonomy API

Like so many features within SharePoint, it is cool we can do it from the interface, but even better if we can do the same from the object model. The object model exposes a complete set of API’s for management of the taxonomy, divided over 4 namespaces:

• Microsoft.SharePoint.Taxonomy
• Microsoft.SharePoint.Taxonomy.ContentTypeSync
• Microsoft.SharePoint.Taxonomy.Generic
• Microsoft.SharePoint.Taxonomy.WebServices

The first namespace is the most important one. Here we find all the classes needed to manage the managed metadata model. The second namespace has classes that will allow you to manage content type syndication (sharing) between site collections. We will get to that in the next article. The Generic namespace contains the generic collections for individual classes in the top level namespace. Finally, the webservices namespace provides the classes to manage the model through the webservices provided.

Although I will not explore the entire object model in this article, I do want to highlight some simple examples on how to manipulate the terms store, especially because this is what we will use frequently with multiple projects running on the same farm. We do not want to manually manage the term store, but use the object model to automate that. In the next example, I will load a set of terms (which will become a term set in the Terms Store) from a csv file and append it to an existing group.

Creating the Terms import file

Now, the content of this csv file obviously follows a specific format. Good news here is that you can also specify a hierarchy in this file. Bad news is that it will only do so for 7 levels, including the top level. For most scenarios however, this will do. There are no tools available as far as I know in constructing this file, which is something that I would expect in a first release. External vendors will dive upon this. The structure of the file should look like below:

“Term Set Name”,”Term Set Description”,”LCID”,”Available for Tagging”,”Term Description”,”Level 1 Term”,”Level 2 Term”,”Level 3 Term”,”Level 4 Term”,”Level 5 Term”,”Level 6 Term”,”Level 7 Term”
“Departments”,”This term set contains the departments in our company”,,TRUE,,,,,,,,
,,1033,TRUE,,”Finance”,,,,,,
,,1033,TRUE,,”Sales”,,,,,,
,,1033,TRUE,,”Procurement”,,,,,,
,,1033,TRUE,,”Procurement”,”Hardware”,,,,,
,,1033,TRUE,,”Procurement”,”Software”,,,,,
,,1033,TRUE,,”Procurement”,”Services”,,,,,
,,1033,TRUE,,”Development”,,,,,,
,,1033,TRUE,,”R&D”,,,,,,

Each line has 12 fields (11 commas) and not all fields need a value. The first line has the column headers and will always be the same. The second line contains the description of the term set. Any lines following that will contain the individual terms. I added the file as Terms.csv to my empty SharePoint 2010 project, using the Empty Element item type.

Pay special attention to the Terms.csv properties. Set the target location so, that it will be added to the root of your feature definition. This will make it easier to reference in our feature receiver, like so:

Create the feature and feature receiver

Next, I have created a feature and an associated feature event handler. This is to control how and when the terms should be added to the store. In the feature receiver, we are going to implement the FeatureActivated and FeatureDeactivating methods. First open the designer of the newly added feature and click Manifest at the bottom. Add the following XML to the feature definition:

<Properties>
    <Property Key=”TermsFile” Value=”Terms.csv”/>
</Properties>

This will provide a property to our feature that we can use in the code. It should look like below image:

Also, I set the ActivateOnDefault property to False, as well as the AutoActivateInCentralAdmin. I would like to control when to activate the feature. Experience from projects also shows that especially the ActivateOnDefault property can cause serious problems when your scope is set to WebApplication. The feature will then be enabled on each new web application, even if you do not want it to.

Now we can start coding. Implement the FeatureActivated method as follows:

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
   // This feature will load the terms from a csv file and add them to the Terms Store.
   // first, initiate the session
   TaxonomySession session = new TaxonomySession(SPContext.Current.Site);
   // obtain the term store
   TermStore store = session.DefaultSiteCollectionTermStore;
   // Create group that will hold my term sets
   Group group = store.CreateGroup(“Boom-Business”);
   // get the import manager
   ImportManager manager = store.GetImportManager();
   // output variables
   bool allAdded = false;
   string errorMessage;
   // Construct the path to the source csv
   string rootFeaturePath = properties.Feature.Definition.RootDirectory;
   string file = properties.Feature.Properties[“TermsFile”].Value;
   string fileName = Path.Combine(rootFeaturePath, file);
  
   try
   {
      using (StreamReader reader = new StreamReader(fileName))
      {
         // Use the manager to import the terms
         manager.ImportTermSet(group, reader, out allAdded, out errorMessage);
         if (!allAdded)
         {
             // report failure and rollback changes
             EventLog.WriteEntry(“Boom.Taxonomy”, errorMessage, EventLogEntryType.Error, 101);
             store.RollbackAll();
         }
         else
            // Commit changes
            store.CommitAll();
      }
   }
   catch (Exception ex)
   {
      EventLog.WriteEntry(“Boom.Taxonomy”, ex.ToString(), EventLogEntryType.Error, 101);
      store.RollbackAll();
   }
}

Let us look at this more closely. First, we initiate a TaxonomySession by providing our current site as the context. We then open the TermStore that is associated to our site collection. When we have multiple services, we should use the TermStores property to get the correct store.

We now have the option to either add the term set to an existing group, or create a new one. In this case, I have created a new group, called “Boom-Business”. Next step is to get a reference to an ImportManager that will control the import process for us.

Next, construct the path to the source csv file by using the feature properties and its location on disk. When we have constructed the path, we call the ImportTermSet method of the ImportManager, passing the group to add the terms to and a TextReader (or descendant) that reads the file. The allAdded output variable should be set to true upon return, to indicate that all terms were imported successfully. Finally, we need to commit our changes to the TermsStore by calling CommitAll.

That is all there is to it. Obviously, we should also include code to remove the terms again if we deactivate the feature, which is coded in the FeatureDeactivating method.

public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
{
   // first, initiate the session
   TaxonomySession session = new TaxonomySession(SPContext.Current.Site);
   // obtain the term store
   TermStore store = session.DefaultSiteCollectionTermStore;

   try
   {
      // get the group from the store
      Group group = store.Groups[“Boom-Business”];
      // get the TermSet
      TermSet set = group.TermSets[“Departments”];
      // Delete the set
      set.Delete();
      // Delete the group
      group.Delete();
      // Commit the changes
      store.CommitAll();
   }
   catch (Exception)
   {
      store.RollbackAll();
   }
}

No rocket science here either. Again, setup a TaxonomySession, get the TermStore, get the Group and get the TermSet. We can remove the group and term set by calling their Delete methods. Finally, we commit the changes again in the store by calling the CommitAll method of the term store. In the catch section, I should have logged the exception, but I was somewhat lazy to the end 😉

Build and deploy your project. I had a strange error though during deployment from Visual Studio. It returned an error during deployment that it could not find my assembly, although it was present in the Global Assembly Cache. However, when I deployed the WSP manually though stsadm (or PowerShell now ;-)), all went well and the project deployed and worked without a problem. Just so you know…

Well, if everything went the way it supposed to, you can now add the terms by activating the feature in the Farm Features section. Obviously, the same result could be achieved by just uploading the csv file through the UI, but that is just not the way it will work in large enterprises with different teams.

Multiple Managed Metadata Services

Because the managed metadata service is a service application, you can have multiple instances. Each site collection could consume metadata from multiple instances, providing the possibility to create a service for each group of interest, skill group, operation unit that would desire their own metadata.

Considerations

So what can we conclude from above? Well, some things come to mind:

1. Adding, removing and managing the terms, term sets and groups is not so much of a problem. However, thinking about how you will construct your hierarchy and sound terms is another. This involves preparation and a lot of considerations that are more business then IT focused.
2. Setting up the management of the Term Store requires processes. You can assign different group managers to each Term Group, but you need to create the governance structure first. Then each manager can access the term store through their own Site Collection by navigating to Site Settings à Site Administration à Term Store Management. All the items are readable, but only the group(s) they are allowed to manage has write access.
3. Providing a programmatic feature that will read the term files (csv) from a central location with an approval workflow attached sounds promising. Using a timer job and approval process, selected controllers can add their terms to a document library. Then a line manager and IT support can validate and approve the file, where a timer job will then pick it up.
4. Processes, processes, processes. Doing this in a managed, standardized and governed way is the majority of the work.

In my next article, I will talk about content type syndication, or in plain English, the ability to share content types between multiple site collections using a publisher subscriber model. For those interested, I have uploaded the Visual Studio 2010 solution of the above example here. Stay tuned…