Sunday, December 17, 2006

Notes about Workflow

Lately I had to write some workflows in visual studio for the first time. I loved the interface, and the richness of options. I cant wait until I get to work with either K2 or Captaris and see how they enrich my workflow environment, but for now the built in workflow action that come with .net3 seem very cool.

I did have some problems though. On my development machine the "delay activity" wouldn't finish.
The delay activity is a cool way to tell the workflow to stop and wait for a specific time. We used it for task reminder setting - the workflow was supposed to wait until the task was due, and then send an email to the task owners. The way to do it is simple - in the delay activity "initializeTimeOutDuration" event you check the task list item "due date" field, and then calculate the time from that date to the "now" date, and set the "TimeoutDuration" property of the activity to that timespan.
The problem was- it didn't work!
After much research I got another machine going, and deployed the workflow there. works like a charm. I noticed that on my dev machine sharepoint is out of synch with the system clock. while the system clock said it was 10am, sharepoint was claiming it was 11am. I guess that messed up the workflow timer. I still don't know how to fix this.

Another interesting thing - The delay activity seems to operate in 10 minutes time units. There is no point in setting a delay activity to 1 second as opposed to 2 seconds or 10 seconds. both will fire at the next timer event which seems to occur once every so often (10 minutes? who knows?). So don't count on the engine for realtime applications (-:

The last thing I wanted to note was that the sharepoint "logToHistoryListActivity" is a great function to use to debug your workflow without going into code, not to mention it can be used to let users know the status of the workflow and what was done. But beware - appearntly each once of these activities can only store a limited amount of characters (my guess is 256, but I didn't check). So limit your logging to a minimum, and don't expect a stack trace to be properly logged there.

4 comments:

Andy Burns said...

Seems like a number of folks have had problems with delay activities - I know I experienced the same as you, and it wasn't because the times were out of synch. I actually found that they didn't work on several of our machines...

Chris White said...

Hi,

Have you found out any more information on this as I'm experiencing the same issues with delay activities.

Thanks,
Chris

Anonymous said...

You need Windows Server 2003 R2 SP2 plus hotfix http://support.microsoft.com/?kbid=932394. Once you have those two things, you can further control the "minimum wakeup interval" via an stsadm.exe command: %stsadm% -o setproperty -pn job-workflow -propertyvalue "every 2 minutes between 0 and 59" -url http://localhost, where %stsadm% is an environment variable set to the location of your stsadm.exe.

Anonymous said...

Try these to adjust the interval:

SET stsadm="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN\stsadm.exe"

%stsadm% -o setproperty -pn job-workflow -propertyvalue "every 1 minutes between 0 and 59" -url http://localhost
%stsadm% -o getproperty -pn job-workflow -url http://localhost

%stsadm% -o setproperty -pn job-immediate-alerts -url http://localhost -pv "every 1 minutes between 0 and 59"
%stsadm% -o getproperty -pn job-immediate-alerts -url http://localhost

PAUSE