Tridion published Item state not returning properly in Event System

Question

I need to perform some action when the component is published successfully.I have used below code and writeout the logs.

EventSystem.Subscribe<PublishTransaction, SaveEventArgs>(TransactionSaved, EventPhases.TransactionCommitted);

public void TransactionSaved(PublishTransaction transaction, SaveEventArgs args, EventPhases phases)
{
    StreamWriter writer = File.AppendText(@"F:\log\Log.txt");
    if (transaction.State == PublishTransactionState.Success)
    {
        writer.WriteLine("PublishTransactionState : success");
        //Code To DO
    }
    else
    {
        writer.WriteLine("PublishTransactionState : " + transaction.State.ToString());
    }
}

But, If i publish any item and check the logs after the component success. The code part written for success didn't execute. Always my log shows "Waiting for Publish" in it.

Can anyone help me out to fix this ?

Thanks in Advance.

Answer 1

Instead of using SaveEventArgs on publish transaction, which is triggered for every state change i.e. Rendering, Resolving, Transporting, etc, use SetPublishStateEventArgs which is triggered only once when item is successfully published or unpublished. Since you are doing it on a component the best way to subscribe will be:

    public void Subscribe()
    {           
        EventSystem.Subscribe<Component, SetPublishStateEventArgs>(Handler, EventPhases.TransactionCommitted);            
    }

    private void Handler(IdentifiableObject subject, SetPublishStateEventArgs args, EventPhases phase)
    {
        File.AppendAllText("c:\\log\\log.txt", args.IsPublished.ToString() + "\r\n");
    }

Disregard the beauty of the code in the Handler, but it will basically return you True or Fasle, depending if item was published or unpublished. It will also work if component was published as a result of publishing Page, or Bundle.

From SDL Tridion 2013 on you can also subscribe to PublishTransaction SetPublishStateEventArgs to catch all of the publish actions and not only components, click here for details

Answer 2

After creating an Event Handler and registering it in the Tridion.ContentManager.config you have to make sure you restart the appropriate services to make sure your changes are picked up. This always starts with stopping the SDL Tridion Content Manager COM+ application (it automatically restarts, so a stop is enough), and restarting the Tridion Content Manager Service Host. But when you are using publishing events, you have to make sure you restart the Publisher and Transport service too.

In most cases it's better safe than to be sorry and use a restart script like this on your development environment. For the production server a reboot is always what I like to see after a deploy (but that's personal preference).

Then looking at your code sample, you are using a StreamWriter without properly closing or disposing it. This way you can never be sure when your updates will actually be written to your log file. Also when multiple threads are triggering your event, this code will probably not work well. I would recommend at least something like:

using (StreamWriter writer = File.AppendText(@"F:\log\Log.txt"))
{
    if (transaction.State == PublishTransactionState.Success)
    {
        writer.WriteLine("PublishTransactionState : success");
        //Code To DO
    }
    else
    {
        writer.WriteLine(string.Format("PublishTransactionState : {0}", transaction.State));
    }
}

But personally (although officially not supported because it is not an open API) I prefer to log to the Tridion Event Viewer Log. To do that, you can add the following using statement:

using Tridion.Logging;

Make sure you have a reference to the Tridion.Logging.dll (which you can find in your ..\Tridion\bin\client folder), and then you can use the following line of code to log your messages:

Logger.Write("my message", "MyEventHandlerName", LoggingCategory.General, TraceEventType.Information);

by selecting a different TraceEventType, you can also log critical, error, warning and verbose (debug) messages. These messages are thread safe and will always directly appear (given that you configured the correct logging level in the MMC snap-in), or simply log everything as an error while you are developing so you know that it will show up ;o).