3

In our Tridion 2013 SP1 environment, we have an extensive blueprint structure. Often, we publish from a high blueprint level down to all its children. However, only the items in the lowest level actually need to be published to the websites.

For that purpose, we have implemented a custom resolver, that removes resolvedItems if they do not come from the lowest publication.

However, publishing from a high level to all its children now results in a lot of empty publish transactions in the queue. How can I prevent that or get rid of them? I've seen an example where the publish state of such transactions is set to "Warning", however I really find these transactions useless and want them gone. Any ideas?

Improve this question
2
  • The title says "prevent having empty publish transactions". The verb "prevent" implies restriction, i.e. an exception inside your Custom Resolver being thrown would satisfy the requirement. This could be easily achieved by throwing an exception if resolvedItems.Count==0. However, you may be implying that you don't want to show any transaction in the queue at all, rather than preventing. Can you update the question with this clarification please?
    – Nickoli Roussakov
    Aug 29, 2014 at 14:59
  • @NickoliRoussakov: obviously, resolving and publishing the correct items is the main goal. Throwing an exception would not help to achieve that.
    – Jippe
    Sep 2, 2014 at 6:12

2 Answers 2

Reset to default
2

Alvin basically gave you all the needed info for acomplete answer already, but let me elaborate a bit with my own information.

So a while ago I started with a Child Publications Only Resolver created as a comment on Alvins article. This is most likely close to what you have implemented in your custom resolver. But I wonder if what you are doing is exactly the same and if it is entirely correct, since you say that you end up with a lot of empty Publish Transactions in the queue. When using my solution, you would end up with just 1 empty Publish Transaction (something which I wouldn't think to be in the way as such) and a lot of full transactions for each child Publication.

But lets say you are bothered by those empty Publish Transactions, and certainly because they have a status of success. That is where my next tool came in, using an Event Handler to change the status of an empty Publish Transaction to Warning. Yeah nice I heared you say, but I want to get rid of them. Well that is when I invite you to look at the code of the event handler, and start to work with it (I wrote that code as an example, not just as a solution).

So what it currently does is change the state:

if (subject.PublishContexts[0].ProcessedItems.Count == 0 &&
    subject.State.Equals(PublishTransactionState.Success))
{
    XmlDocument delta = new XmlDocument();
    delta.LoadXml(string.Format(DeltaXml, 
                                Constants.TcmR6Namespace, 
                                subject.Id, 
                                "This Publish Transaction contains 0 (zero) items.", 
                                PublishTransactionState.Warning));
    subject.Update(delta.DocumentElement);
}

But perhaps more importantly, it does this by subscribing to the following event:

EventSystem.Subscribe<PublishTransaction, SaveEventArgs>(PublishTransactionSaveAction,
                                                         EventPhases.Initiated);

So it is using the event phase Initiated, and what you want to do is delete the transaction all together. To be able to do that, you cannot do so while still in transaction, so you need to look at the event phase TransactionCommitted. Now with this knowledge, you could adjust my event system and call subject.Delete() (when you have located an empty transaction, and it is in its final state change, so that would be Success or Warning depending on what you all did before).

This is basically what Will did in his event handler: https://gist.github.com/willprice76/9639405

Improve this answer
4
  • Basically what we're doing in our resolver is to clear the list of resolvedItems. Then we use the default Tridion component resolver to resolve a list of components. We iterate over this list and add only the relevant items. Not sure where all the empty transactions come from, but it seems like there is one for every publication. Deleting them at TransactionCommitted did the trick. Thanks!
    – Jippe
    Sep 2, 2014 at 6:09
  • Would it also be possible to prevent them from being added to the queue altogether, instead of deleting them afterwards?
    – Jippe
    Sep 2, 2014 at 6:10
  • I'll try your resolver implementation as well, and see if that yields different results.
    – Jippe
    Sep 2, 2014 at 6:23
  • @Jippe using a resolver it is impossible to prevent something from being added to the queue, since the resolver logic kicks in after it has been added to the queue. If you want to remove something, you need an event handler on a transaction committed phase (since that is when the transaction is done and the item could be deleted, please note the state of the transaction aswell as Will mentoned in his example).
    – Bart Koopman
    Sep 2, 2014 at 7:52
4

After sharing a tip to publish from parent publications (that I learned from Kelly Thompson), Bart Koopman and Will Price added two parts to the publish-from-parent scenario:

  1. You already did the custom resolver part to remove the queue parent items (as Bart suggested).
  2. See Will Price's additional step to remove the empty Publish transactions:

See the comments to my post. Will also warns you'll want a check to be sure a publish transaction is successful before deleting it.

Improve this answer

Your Answer

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

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