To ensure they publish simultaneously, is it possible to publish pages and components in one transaction using core services?

Question

We have an ‘article’ schema and for each component created using this schema there are two dynamic component presentations used by various queries on our websites and we also generate a static ‘article’ page.

We have some applications to automate different content creation and publishing tasks such as a wordpress to Tridion content importer/publisher. Currently these applications publish articles by submitting two publishing jobs to the queue. The first contains the page and the second contains the component.

Prior to our Tridion 2011 upgrade, the publishing related services performed so poorly (relatively speaking) that submitting the page and component as separate publishing jobs worked ok for us. Our publishing systems were only capable of processing 1 or 2 items at a time and the page and components took about the same amount of time to render so usually they showed on the websites at the same time.

Since the Tridion 2011 upgrade, publishing performance has improved so much this approach is causing issues. Our publishing systems are processing many more items concurrently (12 I think) and the speed of component publishing has increased dramatically. Now the components for an article may publish 60+ seconds faster than the corresponding article page.

This results in articles showing up in the various query lists on our sites prior to their article page page being available on the site which causes our editors (rightly) to freak out.

So far we’ve tried a number of ways to prevent this. Our currently approach is to publish the page first and submit the article component as a scheduled publishing job for 60 seconds after the page is published. This however has still not completely resolved the issue and seems like a complete hack.

What I was wondering is, if we submit both the page and the component in the same publishing transaction like so:

string[] componentIds = new string[] { "page tcm", "article tcm" };
client.Publish(componentIds, pubData, pubTargetIds, PublishPriority.Low, null);

Will the resulting publishing task show up as one publishing job where both will make it through the publishing/deployment process at the same time? Or will these show up as two separate items in the queue?

I suspect the later as the page uses one storage type and the component presentations another although, with that said, publishing of binaries components in the same transaction doesn’t result in separate publishing tasks in the queue. If it did work this way, it would completely solve our issue and also provide a resolution to a related issue (what happens when the component publishes but the page fails or vice versa.)

Or (setting asside trying to figure out why page publishing is taking so long) are there alternative approaches to a problem such as this we should be looking into?

Answer 1

Another way of doing this would be to check if a link to the static article page is available on the front end. If you are already using the front end APIs to retrieve lists of articles from the Broker, you could test against the Linking API whether a link to the static page is available.

This will some some more overhead on the front end (but marginally if object caching is used), but it will also be a sure way to prevent having dead links on your site.

Answer 2

It sounds like you want to use a Custom Resolver to add the Components (DCPs) to the package when you publish the Page. Alternativley if you are willing to allowWriteOperationsInTemplates , you could call the publish action directly from your Page Template code for the DCPs.

Answer 3

If you 'know' which Component to publish from within the Page publish action then its as simple as calling RenderComponentPresentation from within a TBB in your PT/CT (and throwing away the returned output). For unpublish you would probably need the Event system.

Answer 4

You have mentioned that your current approach is to use scheduled publishing for the component. I think you should also consider separating the publication phases. So render everything in one publish action, and schedule everything to be deployed at some future moment when you expect all the rendering and transport will be complete. (I'm sure this isn't perfect either, but definitely worth looking into.)