I have been working on an integration that needs to read terms from SharePoint’s Managed Metadata service, for a particular field, and then populate that field with those values. All this has to be done via SharePoint’s web services – so the relevant ones here are the TaxonomyClientService, and Lists web service.
This has proved particularly bloody hard.
To start with, let’s look at what fields I needed to deal with. When you add a Taxonomy column to a list, it actually adds two columns.
The first is your ‘display’ column, and this can actually be one of two types – TaxonomyFieldType or TaxonomyFieldTypeMulti. As the name suggests, these are for single select and multi-select respectively.
The second column is a hidden field of the ‘Notes’ type. This stores your actual data, it appears, though quite why still mystifies me a bit (more on that later).
Anyway, there are two columns. As you can see from the screenshots above, the Taxonomy column contains an array of customisation properties.
So, how are these two fields related? Well, not using the ‘RelatedField’ attribute (too obvious), and when I did a bit of a search I kept finding blog posts saying that I would have one field with the name I gave it, and another field with the same number but ending with an additional “TaxHTField0” text. This was not the behaviour that I saw; it might have changed in a service pack.
On my system, the second (Notes) field seemed to have a GUID-like name. It looked mostly hexidecimal, but was often prefixed by a couple of non-hex characters. At first I thought that this might be the reference between the two fields.
However, the relationship is in fact one of the array of properties on the field:
The TextField property contains the ID of the Notes Field. Great, that’s nice and simple.
So, in summary, the relationship between the TaxonomyField and Notes field is held in the TextField property in the array of properties of the TaxonomyField. The value is the ID of the Notes field. You can get this information a variety of ways, but I used the GetListContentType method of the Lists web service.
In Part 2 we’ll look at getting and interpreting the TermSet for our field.
6 thoughts on “Working with the TaxonomyClientService: Part 1 – What fields are there?”
How did you generate the TaxonomyField definition in CAML?
I think I used SPManager and browsed to the TaxonomyField. It can show the schema.
How do you find the guide of the Term-store?
I will work with a MMS on 365 and have no acces to the admin console
Hmm. I think having access to the admin area of Office 365 will make the term store stuff a bit easier to administer. That said, if using SharePoint 2013 on Office 365, I think there is a feature where term sets can be local to (and therefore administered from) a particular Site Collection.
Hi Andy! I am developping a client/server application that would need to have access to the term set of a metadata field, but I have also read that TaxonomyClientService.dll is on the server where you installed SharePoint, so I’m wondering if it’s actually possible to have that DLL in an application that is not on the SharePoint server.
No, you have to keep that on the SharePoint server – but you can use the client side object model to access the service from elsewhere.