How can I best use Tridion Broker as a single content source for multiple websites?

Question

I am working on an implementation of Tridion, which has many different websites, but some materials (such as news) are shared using the basic principle of Tridion for planning. All sites are in the same language, so we are dealing only with differences in branding.

Current situation: There is a publication Global content in which this global content is created. There are some flags in the diagram where a child publication should be selected, which this content should display. When a component is saved, the event system launches and creates pages with components on it, publishes it, etc. Component removal does not occur, only a reset with all the checkboxes checked will ultimately delete pages through the batch process.

Broker situation: I would like to start using a broker. Moreover, since in the future situation, the website will also begin to distribute more content to external websites, which I intend to do through RSS feeds or the basic API that works best with content from the Broker.

Scenarios:

• Allow publishing of global content to publish dynamic content, and on other sites display this content directly from the broker (using the identifier for publishing global content?)
• Make a fake empty target in global content so that they can say "publish / publish publications for all child publications". (You can still use the checkboxes to allow publication in certain publications).
• Use a global content website to publish dynamic content and create API / RSS feeds for use on internal and external websites?
• Something else?

My initial thought goes to the first scenario, but I see the main drawback that it will be more difficult to mix local news items and global news.

The second scenario seems like the second best chance. Does anyone have experience implementing this?

Answer 1

During the implementation that I am currently working on, we use something like a second solution. I have added the main publication of the website (in which we create all pages) to the publication goal that we use for all websites so that we can use the publication for all child publications. If it fits in your model, I would prefer this option, as it continues to give you control over objects by localization in child publications.

Since we didn’t want the content to be published in the publication on the main website (since it will not go anywhere and it will be just a waste of time for my publisher, and then also the loss of the brokerage repository when it is deployed), we created a ChildOnlyPublicationResolver ( SDL Tridion 2011). In this resolver, we iterate over all the allowed elements, and if the element comes from the main publication of the website, we remove it from the list.

As a result, you will see that the publication of the main site appears in the publication queue, but it will be successful almost instantly, since there is nothing in it. Thus, it does not accept any results from the publisher and is not deployed, but you retain the benefits of your child publications and have an easy way to publish them at a time.

If this is interesting, here is a sample recognizer code:

using System.Collections.Generic; using Tridion.ContentManager; using Tridion.ContentManager.Publishing; using Tridion.ContentManager.Publishing.Resolving; namespace SDL.Example.Resolvers { public class ChildOnlyPublicationResolver : IResolver { /// <summary> /// Master Publication TCMURI /// </summary> private const string MasterPublicationTcmUri = "tcm:0-2-1"; /// <summary> /// For publish and unpublish, remove all items from the master publication from the list. /// </summary> /// <param name="item">Item to be resolved (eg a page, structure group, template)</param> /// <param name="instruction">Resolve instruction</param> /// <param name="context">Publish context</param> /// <param name="resolvedItems">List of items that are currently to be rendered and published (added by previous resolvers in the chain)</param> public void Resolve(IdentifiableObject item, ResolveInstruction instruction, PublishContext context, Tridion.Collections.ISet<ResolvedItem> resolvedItems) { List<ResolvedItem> itemsToRemove = new List<ResolvedItem>(); TcmUri masterPublicationUri = new TcmUri(MasterPublicationTcmUri); // check for items from master publication (these do not need to be published or unpublished) foreach (ResolvedItem resolvedItem in resolvedItems) { // mark all items from website structure publication for removal if (resolvedItem.Item.Id.PublicationId == masterPublicationUri.ItemId) { itemsToRemove.Add(resolvedItem); } } // remove all items that we need to discard foreach (ResolvedItem itemToRemove in itemsToRemove) { resolvedItems.Remove(itemToRemove); } } } } 

Answer 2

In traditional Tridion architecture, inheritance through BluePrint could be the best option. This would mean the presence of content in all brokers in all publications and the determination of which elements to display from the metadata.

As Bart suggested, there are some wasteful aspects to this project, so you might think that global content is “merging” from one website. The web content delivery service is for this purpose intended. If you are at Tridion 2011, you can effectively choose your option 3, but with more support because of the box than ever to be present, so you won’t need to create an API, just use it.