Improvements to Taxonomy Connections
In Part 1, we explored the process for creating custom metadata fields before continuing on to configuring taxonomy connections in Part 2. Out-of-the-box and custom solutions use the Sites Core Service internally to retrieve keywords from Sites. We saw that a custom metadata binder can be used in place of the Taxonomy Connector. This allows for more flexibility, including the ability to connect to other, non-RWS taxonomy systems, such as PoolParty. In this third and final installment of the Tridion DX Unified Taxonomy series, we’ll discuss suggestions to enrich your unified taxonomies.
Making Connected Taxonomies Work with DTAP
As previously mentioned, one of the major disadvantages of the out-of-the-box Taxonomy Connector is that it operates on TCM IDs. You can see this by inspecting the HTML of the Docs CMS web client:
Notice the id=”node-1435” – here the “1435” comes from the TCM ID of a keyword in Sites (e.g. tcm:143-1435-512). Attempting to perform a content migration in this case will result in inconsistent TCM IDs across Docs DTAP environments, causing invalid errors in your metadata fields. In many scenarios, Sites overcomes similar issues by using WebDAV URLs to map items across environments.
One solution is to use a custom metadata binder. IDs can be controlled in your custom metadata binder by appropriately setting them in your code:
Here, instead of marking items with TCM IDs, associate them with the corresponding WebDAV URLs from Sites. This can be done using the Tridion Sites Core Service to make a connection and read keywords from Sites in your custom metadata binder code. The result is similar as before, only a WebDAV URL is used in place of the “1435” ID:
This helps to ensure consistency both vertically and horizontally, between Sites and Docs CMSs and also across DTAP environments.
Concerns with WebDAV URLs
One concern about this approach is that your Docs web client HTML may now contain certain characters that would be considered unusual in HTML attributes (% and /, for instance). With HTML5, this should not be a problem. Another concern I’ve heard about WebDAVs is – what happens if we move things around in the Sites CMS? Again, this should not be an issue, since, WebDAV URLs for keywords actually have a flat structure, so there are no concerns with moving keywords to different levels of a keyword tree.
Using Keywords as Identifiers
One slight improvement could be to use the keyword value from Sites as the ID in Docs, since keyword values are unique and mandatory (as opposed to the keyword keys, which are unique but not mandatory). The big advantage here is that it would allow changing taxonomy connections to point to different publications in the BluePrint without issue (this would not be possible with WebDAV URLs, since they contain a Sites publication name). This also has the benefit that it allows us to avoid special characters if we so choose(such as the ones mentioned above that commonly appear in WebDAV URLs), by adopting a naming convention for keywords. Finally, this would remove any complexities or confusion that may arise from the BluePrint (i.e. some keywords defined in a parent publication while others defined in a child publication).
The only concern here would be to watch out for spaces in the keyword values, since spaces are not valid in HTML attributes, even for HTML5. These may require some additional code to process.
Protecting Sensitive Information in Configuration
As we saw in Part 2 of this series, the Extension XML settings may contain naked values for sensitive fields, such as the username and password for the Sites Core Service endpoint or a token endpoint, for instance:
You could encrypt some of these sensitive values. But even better might be to retrieve these values in your custom metadata binder code, perhaps using environment variables or maybe references to values in Azure Key Vault.
For more information on creating and deploying a custom metadata binder, see this great post from fellow Content Bloomer Manish Mehmood.
