Workflow Timer only executes one document in the queue and stops

[Jim_Wysocki]

We have a timer that is configured to run for All document types at 4:00am, every day of the week.  Unfortunately it only processes one document in the queue and stops.   The First Document Only checkbox is not checked.

We are using the Timer Service to execute our timers, and other timers that are configured to run every 5 minutes work fine, meaning they process all the documents in the queue.  If I run this particular timer from the Timer Service Administrator, it also just processes one document instead of all documents in the queue.  However if I execute the timer manually from my workstation using the Classic user interface of my client, it will process all the documents in the queue, not just the first one.  If I change my workstation to the Default (core-based) interface, it will only process one document when running just like the Timer Service.

Any ideas as to why this is happening?  I'd prefer not to manually execute the timer every day.

Thanks

[Paul_Lloyd]

I suspect that there is something in the timer work of your problem timer that is specific to classic thick client workflow, that is causing core workflow to fail.

Without more details of your particular workflow it's difficult to be more specific, but I can give a scenario that will cause the behavior you are seeing.

Say your timer work task includes a 'SYS - Run Script' Action which runs a script that is for thick client only, so it will fail if executed in the core. 

Say this  'SYS - Run Script' Action is followed by a 'SYS - Check Last Execution Result' Rule that checks for Desired Result = 'True (S_OK)'

And say that the 'On False' branch of the 'SYS - Check Last Execution Result' Rule includes a 'SYS - Break Processing'  Action with 'Break Workflow Timer Execution' selected.

So the Timer Work looks like this:

Now, execute the timer work task in core-based workflow. The  'SYS - Run Script' Action executes on the first document. The script fails, so  the 'On False' branch of the 'SYS - Check Last Execution Result' Rule will be followed. So the  'SYS - Break Processing'  Action is executed, causing the Timer Execution to be aborted. So the timer work executes only on the first document.

As I noted before, this is an example scenario, but hopefully it may have similarities to yours.  For your particular problem, you should be able to get more information by activating workflow tracing in the diagnostics console.

[Jim_Wysocki]

Paul,

Thanks for your response.  Unfortunately the situation that you describe does not exist in our timer workflow.  The workflow for this timer is fairly simple.  We want the timer to fire once a day and remove any documents of a particular document type or if the Date of Service keyword has no value or is older than 60 days from the life cycle.  

In our test environment, we have 4 documents in the queue.  When I turned on the trace, everything looked good for the first document, but it never processed the 3 other documents in the queue.  The first document that was processed followed the path to the empty On False task list that is highlighted in the picture below which leaves it in the queue as it should.   In the trace, after it finished the first document, there is a message saying that it processed one document and then another message saying that the Timer completed.  I don't see any errors or anything unexpected in the trace.

I'm fairly new to workflow, but this seems like such a trivial task and I'm surprised that I'm having so many issues.

[Robert_Angus]

This might be a dumb question, but it's always good to check the obvious things... have you checked to see if the other documents are locked in any way?

In the thick client, you can check this by going to Admin > Utilities > Process Lock Administration and also check Admin > Utilities > Document Lock Administration. If the documents are locked, the timer would likely just skip right over them.

[Paul_Lloyd]

You're right, it looks a straightforward task. There's nothing I can see from your diagram that could cause the problem, but I still think the answer lies with some classic-only functionality that is causing problems when run in the core (because even when you execute the timer work manually in core-based workflow you get the problem). But I could be wrong...

I think the best way forward is for you to contact your first line of support, and report the problem. They'll be able to drill down into your configuration in more detail, and set up additional logging/tracing if necessary. It's an intriguing problem, and well worth a followup post when we get the solution (which hopefully won't take too long)