There is Always a User

Recently I posted about approving SDL Tridion community winners. One of the points that came up was what counts as Tridion today?

Rise of the Connectors

SDL Tridion works with any system that has an API or at least an identifier for its items. A basic approach when integrating Tridion with "external" software is to store such identifiers in a Tridion field and add or "template" the surrounding markup or Web application tag or control to the rendered presentation.

<namespace:tagname id="identifier" /> or

<namespace:controlname id="identifier"

runat="server" />

This works for Analytics, references to external videos (YouTube, Vimeo, etc.), job postings, Linked-In profiles, and more. 

But when the quantity of external items makes this approach tedious and/or when there's software better-suited for certain tasks, it helps to have a more formal (seamless, automated, and preferably with an API) approach.

This is where SDL Tridion leverages its own framework and APIs to connect with systems such as targeting, managed translation, and media management. If familiar with SDL software, you might recognize specific products such as SDL Fredhopper, TMS, WorldServer, SDL Language Cloud, SDL Media Manager, and Campaigns. I've joked that if Publishing was built today, SDL might call it Distribution Manager.

The biggest catches for any such integration include:

• Resolving
• Authorization
• DTAP (I won't write about it here, but keep in mind any integration should confirm its assumptions across CMS, not just delivery, environements)

SDL Tridion now ships with many of these (potential) features out of the box in the form of modules such as (Tridion) Outbound Email, Translation Manager, User Generated Content, and External Content Libraries. To be clear, these connectors are part of Tridion but may come with their own databases, APIs, and user or system accounts. You still need to configure and implement these to meet your project's needs.

SmartTarget is not Fredhopper, but rather the GUI elements, delployer features, and delivery-side code to make Fredhopper work with Content Manager Explorer and Content Delivery.

Translation Manager is not TMS, WorldServer, or Language Cloud. It's the piece that stores, displays, and moves translation jobs between the Content Manager and the translation system. It's managed translation because it tracks the progress of the jobs, automates the process back-and-forth, and lets users search and pick items for translation.

ECL or even the Media Manager Connector is not Media Manager, per se, but the integration between Tridion and Media Manager.

The term "orchestration" is more than (just) a marketing buzzword. It really does fit how SDL Tridion tries to plays nice and coordinate with different users and different systems in one interface (at least until there's a new term).

Even publishing is separate from CM or CD. The Content Manager Explorer interface uses the Core Service except item publish status, which is updated by the publisher.

Connectors Have Users

When I first read the Tridion documentation (back when it was PDF'd and in folders by phases) I didn't understand all the need for user accounts for various services.

The server-side user accounts included tcmsystem, tcmworkflow, tcmsearch, and more. I have since realized that the granularity is important to security (or at least those that care about security). For example the user for Content Managent search probably shouldn't do much more than index the search collection and deliver results.

Tridion's authorization model (as complicated as it seems--Dominic Cronin has pointed out it was built the way awhile back to accommodate certain legacy setups) follows some familiar conventions (groups, rights, and permissions), but it doesn't exactly match other systems. When connecting with Media Manager, Fredhopper, managed translation (TMS, WorldServer, or Language Cloud), or even when publishing or doing workflow, Tridion uses a particular user.

Though you might want finer control, I've seen a few things:

• In many implementations I've seen, the customer will ask to elevate access to make a user be able to do things he or she normally can't. They want more access and an easier integration, rather than more authorization settings.
• The roles allowed to "do" publishing, send translations, pick media, or configure targeting typically own or are trusted with the other system. These tend to be the web publisher, language expert, media owner, or marketer (or marketing SME) that pretty much have full access to the other system.
• If most of my projects have authorization as one of the last things on the list (with good reason, it's hard to know what people will break or get stuck on without using it, also you need to set up sites before restricting what users can access), then finer-grained permissions for these connectors would be "phase 3" projects

The wife, a proposal writer familiar with sales and marketing software, even confirmed with, "Who cares about the types of permission being granted if the main part of the build isn't done?"

Thinking in terms of users explains other scenarios such as:

• In terms of authorization this means users that can see the external items can typically use them, publish them, or send them for translation.
• Rollback acts as the user and requires delete permissions, because a rollback could delete versions of items. The user matters.
• Translation just needs scope on the targets, not sources. You can create a job for any items you can see and you can send a job with items you may not have access to.

Resolutions

Resolving is probably the hardest Tridion functional topic. Add it to your New Year resolutions if you haven't already. Each setup might have a different preference, but Tridion's resolving rules are designed to "make it work." Once you have such a default, you get disagreements with the assumptions. Though I don't always see people wonder why those defaults are there in the first place.

In publishing the basic idea is items that use!your item are republished.

• Why? Because those other items might render your item.
• Why not? A more static content model that explicitly places content on lots of pages means a single item queues lots of other items.

In linking the basic idea is that the link resolves to the closest component presentation.

• Why? Content and pages can be separated and links will just work regardless of where content lives.
• Why not? When content = pages = URLs, which is less of a reality today.

With translation, the owning item (nearest local or localized parent) is resolved except for items not-yet-translated. Duplicates are also removed so the translation job just includes the source items it needs for translators. Not yet translated means items under version 2.0.

• Why? Reduce duplicate translations and avoid translating items not yet translated.
• Why not? See below, but sometimes it's tempting to shortcut a BluePrint design and skip translation Publications. It's also hard to realize there's a difference for a given setup.

The (Can Only Translate) Version 2.0 Myth

I admit that I missed some of these resolving rules. I thought "link propagation" worked the other way around (it doesn't, that's because of our templates might publish linked items). Some might miss the proximity rules in dynamic linking. And for awhile there seemed to be a myth that you can only translate version 2.0 items or that workflow can't send minor versions.

The 2.0 only applies for localized items. Managed translation should have a BluePrint of source and target publications where managed translation "owns" (manages) the translations between sources on targets, which is the typical setup. 

So if you want multiple source publications, then you need matching target publication sets (times the number of languages), otherwise the "Version 2.0 myth" applies. Either way, make this easier by limiting sources, hiding Publications, or using the Publication filters.

Two Users

Users in Tridion that own a minor (temporary) change are the only ones that can see those changes or publish them. To get minor versions to translation in workflow, the translation and workflow users must match. My colleague Eric Huiza pointed this out to me, which helped inspire this post (thank the Huizard).

Update and implementation warning (March 4, 2015): matching identities will let you send translation, but be careful with new items, especially in a reserved state (which are forced to wait for Bundle workflow) since their child items cannot accept the translations until they are unlocked. One approach to avoid dealing with issues with receiving such translations is to automatically increment to a major version for new items.

Which brings us back to the point of this post--there is always a user. If you understand how users are related to authorization, versions, workflow, publishing, and any "new" Tridion connectors, then you've solved the second-most-important question: who.

The first important question is why, but as I've noted, we may not always agree or even consider with the why.

For more technical details on the user and system accounts for the modules and extensions mentioned, see this Tridion Stack Exchange Q&A on user accounts. I'd also love to hear your favorite (or worse) "gotchas" when it comes to authorization, users/user accounts, or extensions/connectors.

Let CRUD Guide your Tridion Integration

Bart Koopman describes ways to tackle SDL Tridion integrations in this SDL Tridion World article and a follow-up podcast with Robert Curlette on TridionTalk.

So now you know the how and where, but let's look at the why, when, and which to choose.

Let's revisit some terminology you might have heard: Baking versus Frying.

• Baking is the idea of placing data, content, or multimedia into a system for retrieval "as is" at a later time. You can bake in the CMS or during publish. These items may be managed but the individual details, are stored in the format they're requested.
• Frying is the idea of retrieving, querying, or assembling these in content delivery

We apply these approaches generally in three spots:

• Content Manager
• Publish
• Delivery

But how do you know what to choose since any approach would work (the first time)? Whether you put an image in SDL Tridion, add it in publishing, retrieve it from your content delivery network, or add it with some client-side script, you can add an image to a page.

So let's look at some older lingo you should have heard: (S)CRUD, the basic "functions of persistent storage:"

• Search
• Create
• Read
• Update
• Delete

Add the fact that someone, it might not be authors, has to manage your integration then you have your answer on where and how to do the integration especially since an information system includes people, process, and technology.

Search

How many items are you connecting to SDL Tridion? Would authors know how to identify these from memory or is there a list of items? Can you automate an association to the things you're integrating with?

A few items imply your integration might be in "key-value" configuration components or Application Data (hidden fields or data for items). Make links or paths to Tridion items and add an external identifier.

A few dozen items might require placing components nested in folders or as keywords optionally in a taxonomy tree. Authors would be able to find, select, and then update these "external" items easily. Each component has a field that represents the external item.

Thousands of items in a product catalog or digital system suggest searching in the Content Manager isn't as easy as looking at a list. Consider placing the items outside of Tridion, but not necessarily outside the interface.

SDL Tridion's External Content Library (ECL) is a good fit for multimedia integration. If you're considering options for multimedia (along with translations, analytics, encoding, and more), consider SDL Media Manager which comes with its own ECL Connector to SDL Tridion.

Create

Where does the data, content, or multimedia live? Will authors create this in SDL Tridion or is there a better tool or system? Even if SDL Tridion might be "better," is there an existing tool or system that's not ready to be changed or needed for other things? Look for a best fit, but take your time confirming any changes (mind the people in the process).

From an authoring side you can extend SDL Tridion to show some of these creation options in the Content Manager, even though the items still live in another system.

Read

When do authors need to make the association and when does the data need to be read? This will help confirm whether to bake or fry.

Knowing the content or data model, especially in terms of cardinality, will help here. Do you have a one-to-one (1:1) relationship? A one-to-many? Or many-to-many? In content management terms we refer to direct and indirect relationships, which roughly translate to links/embedded items and taxonomy, respectively.

A one-to-one relationship might mean page metadata or components.

A one-to-many or many-to-many need, where one external item is used in multiple place in Tridion could mean a keyword or component that acts as the external item.

Update

Where and how often do updates happen? Will it happen as part of the publishing process, or should it happen automatically without publishing (update externally, but retrieve presentation or even client-side?).

Will the approach change often? Is the configuration something that should be in Tridion? Do parameters change frequently?

Will data in the external system be accurate? Do authors need to change it and if so, should the changes be reflected back in the other system?

Delete

Finally, how often do you need to delete or remove something?

This can be overlooked, but is important because SDL Tridion can easily unpublish items, but it will restrict you from deleting things without first removing the dependencies.