Parallel WF Activities and the Process Engine

I learned the hard way a few weeks ago how the Process Engine handles parallel workflow activities:  it handles them in parallel!  Here’s what happened…

I was upgrading a Documentum-based solution that had a large, complex workflow with many parallel branches and activities.  This workflow was originally implemented in Documentum 5.2, and over the years has been upgraded to Documentum 6.0; now it was time to upgrade to Documentum 6.7.  The upgrade was simple, the Docbase Configuration Tool did all the work, but I quickly noticed that workflows were failing.  Upon closer examination, I found the error log full of “version mismatch” errors for the workflow template and the workflow package.

In the parallel branches of this workflow, a custom activity did two things:  1) it changed the access rights on the package by granting a calculated user/group additional privileges; 2) it changed the workflow template by assigning a performer to a future activity in the branch.  This process worked flawlessly for years prior to the 6.7 upgrade, because, even though the activities were parallel, they were executed serially by the workflow engine, so only one change to the package and template were made at a time.  In 6.7, the Process Engine sends each activity to a separate thread for execution and the activities truly are executed in parallel.  This resulted in multiple changes to the workflow template and package being made simultaneously, and ultimately to the “version mismatch” errors.

I tried to synchronize the activity code with no success.  I tried wrapping each update to the package and template with explicit check out/check in blocks with no success.  I added transaction blocks to the code where I could.  Nothing prevented multiple threads from updating the template and package simultaneously.

The solution that did work was to cripple the Process Engine.  In the dm_server_config object, I set the wf_agent_worker_threads attribute equal to 1 (the default was 3).

dm_server_config.wf_agent_worker_threads = 1

This restricted the Process Engine to one worker thread, and affectively reverted it to pre-Documentum 6.0 behavior by making it single-threaded.  Fortunately, a single thread can handle the load for my workflow and the end users won’t notice the crippled state of the Process Engine.  But what is the right solution here?  Certainly others must have parallel workflows that modify the package and/or the template, how do they handle it?  Do you have any suggestions?  Let me know! EMC tech support is taking the problem to the engineering department for suggestions.  I’ll update this post if I ever hear back from them.

UPDATE:  It’s a bug (#CS-40525) and will be fixed in D6.7 SP1 P12 due in Feb 2013.  This problem also exists in D7 and is not scheduled to be corrected until D7.1.

UPDATE:  The bug was addressed in D6.7 SP1 P12, though I have not tested it yet.  The readme indicates:

Defect ID: BPM-1168
Fix Request ID: BPM-8410
Description: The “version mismatch” error occurs when executing workflow with parallel automatic activities.

Advertisements

About Scott
I have been implementing Documentum solutions since 1997. In 2005, I published a book about developing Documentum solutions for the Documentum Desktop Client (ISBN 0595339689). In 2010, I began this blog as a record of interesting and (hopefully) helpful bits of information related to Documentum, and as a creative outlet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: