I’m working with Tridion 2011 SP1 and building a workflow that goes like this: start → create → review → publish → stop.
I’ve set up a class library and registered it. Now I’m trying to call a C# method from VBScript in the workflow script editor. Here’s what I wrote:
Option Explicit
Dim processHandler
Set processHandler = CreateObject("PublishingWorkflow.ProcessHandler")
If Not processHandler Is Nothing Then
Call processHandler.ProcessItem(Cstr(CurrentWorkItem.ID))
FinishActivity "Item processed successfully"
End If
Set processHandler = Nothing
I can create the object fine with this line:
Set processHandler = CreateObject("PublishingWorkflow.ProcessHandler")
When I test this code directly on the server with a hardcoded item ID, everything works perfectly. But when I use the same code in the VBScript editor with CurrentWorkItem.ID, the item doesn’t get processed.
CurrentWorkItem.ID should work fine in VBScript, but there’s a workflow context issue that’s probably causing your problem. When workflows run through the Tridion engine vs direct testing, COM object instantiation acts differently because of security context changes. Your C# library might be running under a different user account when the workflow calls it - this causes silent failures even though the object creates successfully. I’d add error handling around your ProcessItem call and check the Windows Event Log for COM exceptions. Also make sure your registered assembly has the right permissions for the workflow service account. When hardcoded testing works but workflow execution doesn’t, it’s usually security context or threading issues, not the CurrentWorkItem.ID reference.
This is probably a workflow context issue with how CurrentWorkItem gets handled during execution. I’ve seen this before - VBScript in Tridion workflows doesn’t always expose CurrentWorkItem properties properly at runtime, even when they work fine during testing. Try getting the item through the Activity object instead. Use Activity.Data or pull it directly from the workflow engine’s context to get the item ID. CurrentWorkItem can be flaky depending on which workflow step you’re running. Also possible your C# method is getting called but failing silently due to permissions or COM registration problems when triggered from the workflow versus running directly on the server. Add some logging to your ProcessItem method to confirm it’s actually getting hit when the workflow calls it.
Been there with Tridion workflows. The issue is probably that CurrentWorkItem.ID is returning the workflow item ID, not the actual content item ID you want to process.
In most workflow scenarios, you need to get the subject ID instead. Try this:
Dim itemId
itemId = Cstr(CurrentWorkItem.Subject.ID)
Call processHandler.ProcessItem(itemId)
I ran into this exact problem when building approval workflows. The CurrentWorkItem object represents the workflow instance itself, while CurrentWorkItem.Subject points to the actual content item being worked on.
Also throw in some basic error handling to catch when the Subject property is null. That usually happens if the workflow step doesn’t have a content item associated with it.
yeah, i faced this issue with tridion before. try wrapping your CurrentWorkItem.ID in a check to see if it exists first. sometimes the object isn’t there depending on your workflow step. make sure you’re in the right context too, CurrentWorkItem might not be what you need.
This sounds like a timing issue with when CurrentWorkItem.ID gets evaluated in your workflow. I hit the same problem with Tridion workflows - the timing matters a lot.
First, add some debug logging to see what CurrentWorkItem.ID actually returns. You might find it’s null or something unexpected. I’ve seen cases where the CurrentWorkItem object isn’t fully loaded when your script runs.
What worked for me was validating the CurrentWorkItem.ID before passing it to the C# method. Just add a quick check to make sure you’re getting a valid ID. If it’s coming back empty or null, you’ll need to move your script to a different point in the workflow lifecycle.