Reviewing or Logging Publish Transaction Failures

Question

In the CME, failed publishing requests are replaced by newer publishing requests that succeed.

Can we somehow see the failure details later?

I agree with JanH's point that the queue isn't a logging mechanism. So I’m thinking we should check logs depending on where the transport package failed, review the troubleshooting list in the documentation, and maybe log some details with the event system.

Support directed me to the list on SDL Live Content summarizing failed transactions (requires login). In summary, we can know the following based on statuses in the publishing queue.

• No item in the queue means nothing was submitted.
• Success but not on website suggests wrong item or wrong place.
• Success but stale content on website might be workflow, caching, or multiple Content Deployers.
• Stuck in Scheduled for Publish may simply be a scheduled item.
• Waiting for Publish should go away normally, but consider what's causing load.
• Stuck In Progress means Publisher Service. It's either load or code.
• Waiting for Deployment simply means the item is in queue. (Keep pressing that refresh icon). :-)
• Throttled means Transport Service is sending more Transport Packages than the Content Deployer can handle. Wait up to 20 minutes or so and then check configuration.
• Warning means the user chose to ignore render errors, but render errors occured. Not a problem if expected.
• Failure means an error occured in the publishing pipeline that prevented the item from being published. Double-click the item in the Publishing Queue to learn more.

When describing a logging approach, I think we'd use the Event System to subscribe to the PublishTransaction (on TransactionCommitted?). Anyone have an example of what we'd need in the handler? I'm sure we need to handle publishing and unpublishing, anything else and where would you save this information?

Answer 1

You can use the Event System and Subscribe to the PublishTransaction SaveEvent and then add a handler to check the State. Here's an example code below:

// Ties into the PublishTransaction for save event
private void InitializeEvent()
{
    EventSystem.Subscribe<PublishTransaction, SaveEventArgs>(HandlerForTransactionSaved,
        EventPhases.TransactionCommitted);
}


// This is the method
private void HandlerForTransactionSaved(PublishTransaction transaction, SaveEventArgs args, EventPhases phase)
{
    // Do nothing on Unpublish
    if (transaction.Instruction.ResolveInstruction.Purpose == ResolvePurpose.UnPublish)
    {
        return;
    }
    // Check for Success, Failed, etc.
    if (transaction.State == PublishTransactionState.Success)
    {
        foreach (IdentifiableObject obj in transaction.Items)
        {
            if (obj is Page)
            {
                Page page = obj as Page;
                // DO SOMETHING HERE
            }
        }
    }
}

Normally I like to create a log in the Windows Event Viewer

Answer 2

In Addition to the Event System, If your CM and CD are on the same server or the server on which you want to log for failure is not restricted to the CM server only, you may think of doing this in Storage Extension as well.

Below is the sample code of Storage Extension that you may want to write something line this for Dynamic CP:

public void create(ComponentPresentation itemToCreate, 
                  ComponentPresentationTypeEnum componentPresentationType)
                   throws StorageException
    {
       try
       {        
         super.create(itemToCreate);
       }
       catch (Exception ex)
       { 
          //Log for failure in File System, Event Log etc.
       }
     }

Similarly, you may want to write for Pages.

The biggest advantage I can see of this approach is in the performance.