I have a number of external systems I would like to integrate my Tridion Published website with. I need my editors to be able to tag Components (or maybe Pages) with an ID of an item stored in another system. These IDs would then be used to bring in data from that system into the Page via some custom code on the Content Delivery side.

The other system has a database with a unique identifier and a name, plus other information.

I don't really want my editors to have to look up IDs manually from the external system. My thinking is to write a console application which connects to the external system and uses the Core Service to sync a list of the ID's from the database along with a user friendly name to a Category with a Keyword for each external "item" and then add a field to the Component's Schema's Metadata that allows the editor to relate a piece of content to the external system items.

Is this a valid approach? Has anyone seen any blog posts or tutorials about something similar?

5 Answers 5


That is a valid approach although it may work better with a shorter list of external items then it would with a long list of such items as performance of the UI tends to start getting wonky if you have 1000's of keywords in a category.

Another way to handle it is to build a GUI extension that directly queries the external data source to present your editors with a list of items to select from. There multiple ways to handle this:

  1. You could write an extension invoked using a custom url for the field the relationship will be stored in. The custom url could present a list of external data items, pulled directly from the external data source, for the user to select and then pass the value the user selects back to the field. This might work better in situations where you require some sort of advanced search capability to make it easy for the user to find the item they want in the external system.
  2. You could you write an extension that just overrode the default control inserted by the GUI for a specific field. For instance, instead of a select list pulling from a category you could define the field as a generic text field and have a GUI extension insert itself in place of the text field for that specific schema and have that extension present a select list pulling from your external source.

One way we handled this in a situation where we wanted to related components with external data elements represented by distinct pages on one of our websites was to have the user paste the URL of the external item into the field in the Tridion component. This worked for us because:

  1. The url contains the ID of the underlying object in our external system (in this case a ravendb respository)
  2. The editors were discovering the content they wanted to relate to the tridion components by browsing the website with the external items anyway so, although the process was 'manual', they didn't have to actually look up any ids or take extra steps for the process to work for us.
  • I really like the simplicity in that second approach - that might work for our situation. I guess the assumption is that the format of the URL is known and doesn't change? I've taken a similar approach to embedding Youtube and Vimeo videos and had a problem with vimeo embedding because there's different URLs for videos and the URLs can change so we had to make the CD side aware of these different URLs (could be done in TBBs). Thanks for your answer. Commented Feb 21, 2013 at 14:13
  • In our case the assumption was the URL was known and wouldn't change but the only reason we could make that assumption was because, in this case, we controlled the website which the urls of the external items they were linking too are located on. Commented Feb 21, 2013 at 14:18
  • 1
    +1, also consider if you'll need features like Where Used (suggesting storing items as keywords or ECL component in Tridion 2013). If using keywords, you could map the external value to the key field since this isn't localizable and roughly represents an identifier. No need for keyword metadata in that case. Commented Feb 22, 2013 at 19:25

Julian wrote a very interesting article on integrating with a PIM (Product information management) system a while ago. Although specifically for PIM, it covers some of the implementation issues/decisions that you may face:


  • 1
    +1, he outlines 3 approaches that really help clarify where to integrate: data in the CMS, data added at publish time, and data retrieved at request. Commented Feb 22, 2013 at 19:20

The problem with importing data through the Core Service with the intent of it creating a reference to an external system is that you will run into troubles when trying to remove an item (a Keyword in your example).

If the Keyword in question is used, you cannot delete it through the Core Service (unless you start removing its usage and making the process a lot more complex).

With the upcoming 2013 release we will get ECL (External Content Library) as a possible option for this use case. It handles your external content purely as files (that could be considered something as simple as a logo) but allows for external metadata, which seems to be just what you require. The items themselves are not actually created in Tridion (they stay external), but a stub reference is created once it is being used. Now granted this still doesn't directly solve the process of what should happen when an item in the external system is deleted, but it does make the options on how to handle it more clear (it requires two way communication so that the external system does not allow deletion of an item when it is used in Tridion).

Downside is of course that it is not available yet, so unless you can wait, then I think Glenn's suggested approach might have to be the way forward for now.


I don't think for me using any cms as a app store is a good idea and tightly binding the cms to an app makes it difficult to separate the 2

Why not use WCF service that responds with some json and paste the URL into a schema field

At least then the json can be used elsewhere if needed The content editor only need know the URL of the json service And the template need only contain a tiny piece of jquery

  • Good point about being careful with tightly binding the cms to an external app. Lose bindings are definetly better for this in MOST cases. Commented Feb 25, 2013 at 4:34

Keep in mind, one of the reasons we used stubs is that we then get the full power of the CM with regard to knowing where we are referring to an external asset. Imagine how quickly this will get out of control - if the references are not known and managed by the CM itself - with BluePrinting and reuse of content you could end up with multiple locations (literally hundreds) in which the external content is referenced. This also makes the system much more controlled for business users. We keep it as loosely coupled as we can without affecting the integrity of the content management process.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.