FYI: Error found in BPS 6.5 SP1 WorkitemExAdapter

Chris_Campbell

I've been working on this for two days trying to find this problem and I finally tracked it down.  I'm posting it here for other developers to be aware of since it's highly unlikely that this will make it into SP2.  (Note: SP2 as far as I know was finalized ~ June 1st and should be appearing any day now.)  I'll be submitting a formal bug report as soon as I'm done posting here.  It just so happened my browser was already opened here.

Quick Note: If it wasn't for the new superfabulous debug process mode in Process Builder, I wouldn't have found this bug.  How did I ever get by without this feature?!?

Problem: Source code for WorkitemExAdapter.class incorrectly creates IDfList objects in the getNextActivityNames(), getPreviousActivityNames(), and getActivitiesBasedOnType() methods.

Impact:Any custom methods or workflow methods that inherit com.documentum.bpm.engine.adapters.WorkitemExAdapter will return a [DM_DFC_E_TYPE_MISMATCH_ADD]error:  "Type mismatch. Expected type ""; got type "String"."; ERRORCODE: 221; NEXT: null

at com.documentum.fc.common.DfList.set(DfList.java:795)
at com.documentum.fc.common.DfList.set(DfList.java:783)

Unknown if any other methods are impacted.  A reallyquick check of the processengine.jar didn't reveal anything.

Cause: The methods above incorrectly create a new DfList object in the following manner...

      DfList localDfList = new DfList(localList.size());

This makes a call to DfList(int) which creates an object list of type (size).  So if my list was 15 items large, the list type would be 15 which doesn't exist.  (See the Javadocs for the constants for com.documentum.fc.common.IDfList.)  This causes the code to fail later when setting anything to the localDfList object.

Fix: The code should read something along the lines of...

     DfList localDfList = new DfList(DF_OBJECT, localList.size());

... which would create the default list object type with the proper size.

Workaround: Haven't gotten that far.  I'll update this thread as I get more details.

Update 1 (6/18/2009): So far I've been unable to find any "stock" activities that use the affected code.  I've emailed a few people I know at EMC to see what the best way to get this fixed for everyone.  In the meantime, it looks like I'll be having to code around this - essentially rewriting huge sections of EMC code to fix it.