Sacrificing performance

It is ridiculous, but sometimes it is required to sacrifice performance in order to get stability, let’s elaborate.

About year ago we decided to stop assigning multiple performers for single workflow activity, i.e. when a couple of users are supposed to do the same task in parallel (approval workflow is a good example of such activities) – instead of assigning multiple performers for single workflow activity now we spawn individual workflow for each performer:

and manage child workflows using following pattern:

such approach has a couple of advantages over default BPM capabilities and the most important is: we get some flexibility in workflow routing – standard Documentum options are: “wait until every performer makes a decision” or “complete activity after first reject”, now we are able to make routing decision relying on various factors like the position of performer in organisational chart, percent of performers who made negative decision, etc. So, if everything is perfect what is the stability problem I’m talking about? This short workflow:

is a time bomb. The problem is following: when Content Server starts workflow (or completes workflow task) it automatically creates the first (next) workflow task. What does happen if workflow task being created is a manual task? Performer receives e-mail notification, i.e. Content Server notifies performer by e-mail. Now, let’s check how Content Server sends e-mail notifications:

API> retrieve,c,dm_method where object_name='dm_event_sender'
API> get,c,l,launch_async

So, launch_async is set to true, and this means Content Server doesn’t wait when method gets completed, i.e. if your code looks like:

for (int i=0; i<zillion; i++) {
  launch new workflow

or like:

for (int i=0; i<zillion; i++) {
  queue notification

you are risking to down either JMS or operating system where Content Server resides – the result depends on how you send e-mail notifications. The general idea to solve such problem is to always add automatic activity before manual activity in workflow and avoid using com.documentum.fc.client.IDfSysObject#queue method.

One thought on “Sacrificing performance

  1. Pingback: Workflow throughput | Documentum in a (nuts)HELL

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s