Content types are probably some of the most important things you need to master for literally any SharePoint project. They let you attach so much manageability with your data that you cannot really even think of managing your data in SharePoint without leveraging content types.
As awesome as content types are, historically speaking, using them consistently across your entire farm has been very troublesome. Not just using them, but also updating them, and synchronizing them all across your farm has been nothing but a pain in the neck!
Historically, smart developers have found out ways to push down content type updates using carefully crafted solution packages (or should I say craftily careful solution packages?). Traditionally, out of the box, the boundary for a content type has been the site collection! How limiting, really!
Enterprise Content Types in SharePoint 2010
Starting with SharePoint 2010, this is changing! Content types are now free to break the boundaries of the site collection and can freely roam around the farm. Also, the way it is implemented is quite easy to manage! It is built on top of the managed metadata service and a hub and spoke model! The idea is that you the architect can decide which site collection gets to be the hub (i.e., the boss of content types) that every other participating site collection listens to. Then from this site collection, you can choose to publish content types and decide which content types get published! Other "spoke" site collections will simply reflect the updates to their content types as they were published from the hub. And in the background, this synchronization of content types occurs with the help of SharePoint jobs.
Using External Content Types
Let’s see how to use External Content Types with an example. In the example, I will set up the site collection at root as the hub and another site collection at /sites/receiver as one of the spokes. Then I will create a content type in the hub (i.e., the root site collection), and you will see the process of the content type being made available in the spoke (i.e., in the /sites/receiver site collection). Thus, start by ensuring that you have two site collections: one at root and the other at /sites/receiver. Then, in the root site collection, activate the Content Type Syndication Hub feature. And in the spoke (i.e., receiver/listener) site collection, activate the following feature:
stsadm -o activatefeature -url http://sp2010/sites/receiver
-id 73EF14B1-13A9-416b-A9B5-ECECA2B0604C
Then visit central administration, under the managed services area. You can create many instances of the managed metadata service, but create a new instance by the name of Winsmarts. It is in a managed metadata service instance that you would specify which site collection gets to be the hub of the content type synch. Choose the Winsmarts instance, and select Properties from the ribbon. In the ensuing dialog box, point this service to use the root site collection as the Content Type hub, as can be seen in Figure 1.
Next, right below the instance of the Winsmarts managed metadata service, click the proxy/connection of the Winsmarts managed metadata instance, and select the check box next to “Consumes content types from the Content Type Gallery at http://sp2010,” as shown in Figure 2.
Next, go ahead and create a content type in the hub/root site collection. I am going to create a content type called Winsmarts Document that inherits from Document. You can play with a number of settings in the content type, such as the document template, associated workflows, columns, and do on. But as a general rule, as a content type gets synched over to the spoke site collections, you will see that while the content type and all its reusable settings do get synched, the actual supporting artifacts do not. In other words, let’s say you have a content type with a workflow associated. The content type along with the workflow associations will get synched, but the workflow itself will have to be deployed and activated on the target site collections.
Now, once you have created the Winsmarts Document content type, visit the content type settings page and look for the Manage Publishing for this content type link. Clicking that link will take you to a page that shows you the various publishing options associated with this content type, and the previous publishing history. The various publishing options are as follows:
Publish: As the name suggests, this option will make the content type available for publishing. If this content type has never been published before, it will be the only option enabled. Do note that published content types in target/spoke site collections are available as read-only/sealed.
Unpublish: Unpublishing a content type as the name suggests will stop publishing further changes to this content type. Note that I said “further” changes?the changes done so far will remain in the target/spoke site collections, and going forward the content types in the target/spoke site collections will become unsealed, and thus available for changes. But future changes will not be applied.
Republish: If for any reason the target/spoke site collections are showing you incorrect content types, you can choose to republish them and thus push the content types afresh!
Now, as I mentioned, the only option available to you at this time will be Publish because this content type has never been published. Thus go ahead and publish this content type. Immediately after you publish this content type, visit the /sites/receiver site collection’s Content Type Gallery. What do you see? Unless you are really lucky, you shouldn’t see the Winsmarts Document content type synched down just yet because this synch runs as a job that is set to run every 15 minutes. To run this job immediately, visit the Job Definitions page in central administration\monitoring, and look for the Content Type hub job definition. Clicking that job definition will show you that this job is set to run every 15 minutes. Also, you will see a Run Now button as shown in Figure 3.
Go ahead and click the Run Now button to run the job immediately. Now, visit the Winsmarts Document publishing settings, and under publishing history, you should hopefully see Last successful published at ... This can be seen in Figure 4.
Now check in the spoke site collection at /sites/receiver. You still wouldn’t see the newly created content type propagated here. What you need to do is go back into the jobs area in central administration, and run the Content Type Subscriber job. Now, in the receiver/spoke site collection, under site settings, visit the content type publishing hubs link. Here you should see all the subscribed content types. You should also see the Winsmarts Document content type show up here now. Visit the Content Type Gallery of the receiver/spoke site collection. You should see the Winsmarts Document content type available here. Now click this content type in the receiver site collection. You will note that this content type is read-only. This makes sense because the content type is being published from the root/hub site collection, so any changes being done to this content type must be done in the root/hub?not in the listener/spoke site collection.
Now I’d like you to try out a few experiments on your own! I’d like you to try out the process of unpublishing the content type from root. The content type will become unsealed, but it will not be deleted from the spoke. Also, before you unpublish it, make some further changes to the content type and see its effect on the subscribing/spoke site collections. You will see that subsequent changes are also pushed down to the site collections.
Summary
I cannot think of a SharePoint project I’ve done in which I didn’t have to consider content types. Every computer is an information management machine, and every software differentiates itself from another in its ability to manage information. Content types are central to SharePoint’s management of information. Learn it, Love it, Master it.
Until next time, Happy SharePointing.
