Check if a workflow is already running

All,

I'm writing a basic workflow, on instantiation I'm going to run a script to determine if there are any other instances of the workflow running. I am only allowing one. If there are, I'll set a required variable to false, preventing the workflow from starting.

Thoughts on this? Has anyone faced such a requirement? How have they dealt with it?

Another option I'm thinking of playing with having an initial external task to check if another instance of the workflow is running and to basically put the workflow into a wait/queue. But this could get troublesome if we start to queue up the workflow.

Thanks for any advice.

Pat

Find more posts tagged with

Comments

nipper

Hey Pat

I have worked this from the other end, checking to see if a file being submitted is currently in a WF. That can be changed to your req without too much trouble.

First Q is, is this WFT or WFM ?

nipper

In either case, run a script (in the template_script or as a call server or even an inline call) to run iwqueryjobs or iwgetwfobj to get a list of active jobs.

iwqueryjobs has the potential to be the fastest, but you would be well advised to benchmark this a number of times. You may be able to use TeamSite::WFSystem::GetActiveWorkflows() and avoid the system calls.

Once you know that, make a required (and hidden) field so the WF cannot be instantiated.

HTH

me

patrickm

Yep, it's WFT. I'm coding it up in TeamSite::WFSystem::GetActiveWorkflows() in the template_script area, but yes, it's slow. I haven't tried iwqueryjobs. Will try that now.

nipper

Yep, it's WFT. I'm coding it up in TeamSite::WFSystem::GetActiveWorkflows() in the template_script area, but yes, it's slow. I haven't tried iwqueryjobs. Will try that now.

I would do this outside the WF for now, just write a script to so some of the tasks.

There is a really good benchmarking PM in Perl, you would be best to write 3 different ways of doing things and see how each performs.

I am surprised that GetActiveWF is slow, I would have thought that would be fast, but it is possible the PM execs some processes.

Here is a good WP that shows how the benchmarking works (thanks to ghoti):

http://dl.dropbox.com/u/1833595/Perl_Efficiency.pdf

Adam Stoller

...
I am surprised that GetActiveWF is slow, I would have thought that would be fast, but it is possible the PM execs some processes.
...

Considering that most of the Perl "API" for workflows ends up being wrappers around system calls to the CLTs, I wouldn't be that surprised at the speed if there are a significant amount of active jobs in the system.

iwqueryjobs has some potential for being faster, as I believe it can actually perform the query / filtering internally and the negate much of the overhead there - unfortunately (if the manual is correct) you can only query on job owner, activationtime, and whether or not it is active -- you don't seem to be able to query against the workflow name.

So, that takes you back to doing something like TeamSite::WFsystem and TeamSite::WFworkflow. First get a list of the active jobs, then loop through them to find any which have the same name as the current job (if you're doing this post-instantiation, make sure you don't count the current job when looking for pre-existing jobs of the same workflow - i.e., examine job name first, then jobid when job name matches)

You could also code this up in Java with CSSDK, which should be faster than the above approach even if the algorithm is identical.