This is a topic that is raised with me from time to time, mostly because of my connection with a large product company that I work with on a daily basis. A colleague prompted me to write this down properly, so how do you integrate a Product Information Management system, or PIM, with SDL Tridion.
It is fair to say that SDL Tridion, like most CMS systems, is not a PIM and should not be used as one. It is a Web Content Management System and as such its purpose is to allow any organization to create, manage and publish marketing content. PIMs hold a specific type of content which is product data, they vary in what they store but almost certainly the minimum that a PIM stores is product combination or SKU. The number of SKUs an organization has will depend on the amount and type of products. Simple products, e.g. cups tend to have fewer SKUs that say laptops; but in both cases it could amount to many thousands or many millions of possible product combinations. Add to this, SKUs change over time as products are updated or changed as manufacturing parts change or just new products are added.
When looking at integrating a PIM you need to have a careful look at the content stored and how that should be used. Additional content that could be stored in the PIM could be things like product description and this content will need to be looked at in detail. Is it needed on the website? I it translated? Is it localized? On your website you will want to present a combination of this product content and your marketing content; in different places on your website this content will vary in what the mixture is. But, overall you will want to show a uniform brand and content experience.
How you integrate this content together should be a matter of careful decisions and I will run through three simple scenarios and some basic pros and cons that will help guide that choice.
Importing Product Data into Tridion
Importing product data into Tridion should be seen as the bottom rung of choices for an integration. We assume that the PIM is the master of the product content, if we import this content there will be two copies of the same content so in this scenario we should really decide if we are going to do something with this imported content (e.g. Translation). If we are, this scenario might make sense but, if importing this PIM content into Tridion it only really makes sense if the number of products is low and the number of updates (the delta) is also low.
Pros
- Localization and translation of product content possible from within the CMS
- Marketing has complete control over the content presented on the environment (from a single system)
Cons
- Content import could be complex to implement
- Updates need to be published
Integration at publish time
Rather than importing content, we can consider the approach of merging the product content with our marketing content when it is published. For this our marketing content must be tagged or reference in some way to related it to which product it belongs. The templates then render the combination of marketing content and product content together as the pages are published to the website. To relate content to product there are two choices; 1) a product taxonomy in Tridion either created by hand or imported from the PIM or 2) a manual entry of the product ID in the content metadata either completely by hand or helped along with a lookup calling out to the PIM. I personally prefer the taxonomy approach but the automated import of a complex hierarchy will have to be thought out well in advance.
Pros
- Great for static content websites
- Good for when a PIM is not available directly to the websites
- Marketing content is easily kept in sync with product content (on publish)
Cons
- Updates to product content require a republish of both sets of content
Integration at runtime
The last major choice would be to integrate the marketing and product content at runtime. This requires use to have some application logic on our website and we’ll still need a way of linking the content we are looking at to the product; we could still use our product taxonomy idea but we could also use other ways such as URL. In essence, we do the same level of integration as we did at publish time only one stage later.
Pros
- Possible to implement more complex website functionality (e.g. product compare)
Cons
- Product content can get out of sync with marketing content (e.g. available colours)
- Requires a PIM or a sub section of it, to be available directly to the website
Did I miss some pros or cons or another scenario completely? Let me know in the space below!
Hi Jules,
We are on the verge of making a decision just like this for an European(global) company with more than 30 country websites.
I must say that it is very tempting to use Tridion for all the good reasons of blueprinting and TMS, but it could easily run into the 100.000 of products and variations. With countless of combinations and exceptions.
Somewhere my gut feeling thinks it can become too much of a burden on Tridion, and become too difficult to manage.
I am probably more inclined to create an external application with a connection to TMS (since this is not just limited to Tridion) and copy the blueprint structure and probably depend on the same Taxonomies used in Tridion.
So that would be the integrate at runtime, but backend integration with Tridion, but not in Tridion.
@Hendrik, that is the lure, it is too tempting to use something for what is might not be designed for because of the perceived benefits.
Great post! I think this is a very interesting topic and more when nowadays WCMs are getting more mixed up with eCommerce.
Integration at publish time
– Pros
* More intuitive for editors.
– Cons
* Content can easily go out of sync, although something could built to avoid this. However it adds complexity.
* Products need to be maintained in two places. Even though you would not change the product in Tridion, products would need to be sync with the PIM either manually or automatically.
Integration at publish time
– Pros
* Latest products are always shown on the website without need to republish.
– Cons
* Potentially it could make the website slow, because the product details are retrieved at runtime.
Some great additions to the pros/cons Asier! Making things easier for the editor is a much overlook aspect of any implementation. we as implementators/developers often solve problems with the technical solution that works best (however you define your criteria to judge that). We should never lose focus that some solutions are painful to develop but might work better for operational productivity! It is still not enough to support importing the content though 🙂
I think before you decide on one of these three options, you have to answer the question: what do you want to do with the product data on your site?
If you only want to offer a catalog of the different products, with a link to – say – a web shop, you are really only interested in the static part of the product information managed in the PIM. In that case, importing this into Tridion might be an option. Also, often product companies use SKUs on different levels: a general SKU describing a product in marketing terms (‘iPhone 4s’) and more specific ones, that take packaging, localization, region etc into account. When you’re integrating on that generic level, the number of products will be much lower and easily manageable in Tridion (with all the associated benefits).
If, on the other hand, you want to display all these ‘product variations’ on your site, or if you want to show things like stock information, country-specific pricing, etc, you really need a dynamic integration on the web site.
Personally, I’m not a great fan of option 2 because it has the downside of being a publishing bottle-neck, without any real upside imo.
For the history buffs, perhaps it’s interesting to mention that although Tridion is plainly far better at being a WCMS than anything else, the advanced taxonomy support in the product today can trace its roots to a research project back in the 5.2 era. This was an investigation into the possibility of creating a product catalogue implementation that would be built on parts of the Tridion core. Research projects like that never really go to waste, do they?
@HENDRIK BEENKER – So which approach did you followed at last and what were the pros and cons? I am also working on same kind of scenario.