With all the anticipation and excitement of the new 2013 Bundle Workflow coming out, I thought I’d dig into my notes about the regular ol’ single item workflow for those still on pre-2013 systems.  In this post I discuss some lessons learnt about debugging workflow.  Note, this is when I was working with Tridion 2009 SP1, but the same should apply all the way up to Tridion 2011 SP1 HR1.

There are a few methods available for troubleshooting your workflow code.  There is no way to use a real debugger on the Workflow VB script since there is no way to set breakpoints in the Visio Automatic Activity Script editor.  You can instead keep your VB code as light as possible and keep your workflow logic in C#.  

Attach to Process and Set Breakpoints/Debug Normally

To do this, your code must be outside of VBScript editor in a C# Class Library DLL as mentioned above.

One approach to this is to write a stand-alone executable that you call via the workflow VBScript.  This stand-alone exe would need to impersonate a user on the CM server, but then can do anything you want.  And since this is a stand-alone program running from some directory on the server you can deploy it with a PDB file and attach to its process.

Another common practice of writing workflow code is to write a DLL then register it as a COM+ object or drop it into the GAC.  Note that with the GAC approach you can’t easily put the PDB into the GAC with it (at least for the x86 architecture; for x64 there is a folder deeply nested somewhere in Windows where you’ll see your DLL,so you can put your PDB next to it). Then we simply use Process Explorer (http://technet.microsoft.com/en-ca/sysinternals/bb896653.aspx) to find the process using your DLL and attach to it.

Print Logging Statements

If you have some logistical challenges with being able to attach to a process, then we need a way to print debug output statements somewhere – the old fashion way of debugging.  This “somewhere” can be two places:

1. CM Server’s Event Viewer.
2. The finish message.  However there is a character limit on how big this can be, and your code may never reach the finish statement.

Using Tridion’s Logger to Print Debug Output

This is the sure way of logging your debug output.

If you’ve moved your workflow code away from VBScript into a C# DLL, then:

Logging logger =  TDSE.GetLogging();
logger.LogEvent("my debug output", EnumSeverity.severityError, EnumEventCategory.EVENT_CATEGORY_WORKFLOW);

You can do the same thing right from the workflow VB script:

Dim logger
Set logger = TDSE.GetLogging()
Call logger.LogEvent("my debug output", 1, 22)

The log messages will appear in the CM server’s Event Viewer log.

If you don’t have sufficient access to the CM server, then you can use the method listed below.  However, in order to effectively develop Workflow you need to get that server access and the ability to freely see the CM’s Event Viewer.  So convince your PM or IT people to grant you that access or you’ll be burning a lot of rubber spinning wheels rather than getting traction.

Using the Finish Message to Print Debug Output

This is a really cheeky approach to debugging.  Do it as a very last resort or while waiting for IT requests to get processed instead of twiddling your thumbs.

Start with one line of code which is:

Call FinishActivity("my debug output", "Next Activity’s Title or TcmId")

Add some code before this line.  Any output you want to see should go in “my message” parameter of FinishActivity.

Note: there is a character limit to how large the finish message can be.  This is driven by the database column size.  So if you try and spit out too much debug output you’ll get an error.

So be warned.  This is a way to do some quick one off printouts, but don’t rely on this as the main way to debug your code (Although back in the day I’ve gotten through coding a massive workflow with this approach before I realized TOM provided a logger, duh!)

Again, a much better way to log debug output is to use the Logger that comes with TOM.

Some Workflow Errors and Things to Watch Out For

Position in the Workflow

CurrentWorkItem.ActivityInstance.Position

This one was fun to debug…  Actually if you carefully read the TOM API, which I did not, it provides an example of how to find out how many more activities are left in the flow.  There actually is a comment in the sample code that mentions that this works only if there are no loopbacks.  Be warned!  If you have a case where you need to find out what the previous activity was or what the next activity is, you can’t rely on the position that Tridion gives you because if you have a rejection of content that takes you back a few steps, the position still gets incremented.

Object reference not set to an instance of an object

An error occurred while executing the Workflow script.

The Script Engine returned the following information:

SOURCE:

  Line = 41

  Column = 0

  Number = -2147467261

  Source = ContentBloom.Tridion.Workflow

  Description = Object reference not set to an instance of an object.

  HelpContext = 0

caused by: ContentBloom.Tridion.Workflow

and description: Object reference not set to an instance of an object.

Source:

LogScriptError

This isn’t the VB dying; it’s a null reference exception somewhere in your C# code.  Unfortunately the error doesn’t tell us where – well it tell us which function is being called by VB and its line number – so throw in a bunch of logging statements into that C# code and see where it bugs out.

Application uses a value of the wrong type for the current operation.

Unable to finish the Workflow Activity (tcm:12-671-131104)
Application uses a value of the wrong type for the current operation.

The CM server’s event viewer may show a few errors with some being a blob of XML.  If you look closely you’ll see this message.  What it means is that the size of the FinishMessage is too big.  The database column for this field has reached its limit.