Ban BOF2 deployment

Two weeks ago I tried to run Webtop 6.7SP1 against Content Server 7.2 (yeap, I do know that such configuration is considered as “unsupported”, but my opinion is EMC is just not familiar with product they are trying to developkill) and got an exception when I was trying to launch workflow:

java.lang.IllegalAccessError: tried to access method 
     com.documentum.fc.client.DfWorkitem.checkComponentTypes(
           Lcom/documentum/fc/client/IDfSession;
           Ljava/lang/String;
           Lcom/documentum/fc/common/IDfList;)V 
     from class com.documentum.fc.client.DfWorkflow
at com.documentum.fc.client.DfWorkflow.addPackageInternal(DfWorkflow.java:240)
at com.documentum.fc.client.DfWorkflow.addPackage(DfWorkflow.java:137)
at com.documentum.bpm.impl.DfWorkflowEx___PROXY.addPackage(DfWorkflowEx___PROXY.java)
at com.documentum.fc.client.DfWorkflowBuilder.addPackage(DfWorkflowBuilder.java:107)

For every java developer this error looks weird because DfWorkitem#checkComponentTypes method has a package access level and both DfWorkflow and DfWorkitem classes reside in the same package. However, I do know that when DFC loads BOF2 modules (both dm_workflow and dmi_workitem are now deployed as BOF2) it performs some manipulations with bytecode and classloader and these manipulations break a lot of things, so the rule of thumb when developing TBO is never ever use static methods inside TBO classes – if you need static method put it into utility class, unfortunately, EMC coders do not know about this rule, so we are doomed to investigate stupid exceptions.

How to fix my error? After a little deliberation I decided that the best option is to somehow hide these modules (dm_worklow and dmi_workitem) from DFC 6.7SP1. Initially I thought that min_dfc_version attribute in dmc_module is exactly what I was need:

though description of this attribute is very obscure:

my understanding was: “if certain module is not designed for specific DFC version, DFC must not load it at all” – it is quite logical, isn’t it? Nothing like this! EMC coders are adepts of special kind of logic which is incomprehensible for other humans – changing value of min_dfc_version does not affect DFC behavior. What is next? Is it possible to create a multiple modules and allow DFC to “pick up” the correct one? Actually, I was need that DFC do not pick up any, because in that case it should switch to dbor.properties or IntrinsicModuleRegistry – seems not to be logical, but I did comprehend incomprehensible logic of EMC developers 🙂 Let’s try:

API> create,c,dm_folder
...
0b024be980034908
API> set,c,l,object_name
SET> 1
...
OK
API> link,c,l,/System/Modules/TBO
...
OK
API> save,c,l
API> create,c,dmc_module
...
0b024be98003490a
API> set,c,l,object_name
SET> dm_workflow
...
OK
API> set,c,l,a_module_type
SET> TBO
...
OK
API> link,c,l,/System/Modules/TBO/1
...
OK
API> save,c,l
...
[DFC_BOF_MUST_HAVE_UNIQUE_NAMES] Each business object must have a unique name. 
   Name "dm_workflow" already exists.

Damn! Where is my RPC trace?

API> apply,c,,LOG_ON,DETAIL,B,T
...
q0
API> retrieve,c,dm_workflow
...
4d024be980000101

....

Object Id: 0000000000000000
Argument Object:
2
OBJ NULL 0 0 0 0
5
QUERY STRING S 0
A 169 select r_object_id from dmc_module where a_module_type='TBO'  
   and (object_name='dm_workflow' or object_name like 'dm_workflow..%' ) 
   and folder('/System/Modules',descend)
FOR_UPDATE BOOL S 0
F
BATCH_HINT INT S 0
50
BOF_DQL BOOL S 0
T
FLUSH_BATCH INT S 0
-1
"

Aha, DFC tries to find not only modules with the same name as type name but also modules with name starting with ‘type_name..’, interesting … Complete solution:

API> retrieve,c,dmc_module where object_name='dm_workflow'
...
0b024be9800016ac
API> set,c,l,min_dfc_version
SET> 7.1.0000.0000
...
OK
API> save,c,l
...
OK
API> create,c,dmc_module
...
0b024be980034915
API> set,c,l,object_name
SET> dm_workflow..neverload
...
OK
--- I believe that DFC will never
--- get 9.9 version
API> set,c,l,min_dfc_version
SET> 9.9.0000.0000
...
OK
API> set,c,l,a_module_type
SET> TBO
...
OK
API> link,c,l,/System/Modules/TBO
...
OK
API> save,c,l
...
OK

voilĂ !

3 thoughts on “Ban BOF2 deployment

  1. I’m a bit confused. Earlier you mentioned that changing min_dfc_version did not help at all, then I see in your final solution that changing the same attribute worked when you have multiple modules?
    So am I correct in understanding that setting min_dfc_version to any value above the client dfc version will prevent the module from executing?

    Like

  2. Earlier you mentioned that changing min_dfc_version did not help at all, then I see in your final solution that changing the same attribute worked when you have multiple modules?

    DFC honours min_dfc_version attribute only when it has to make a choice, in order to provide such choice to DFC you need to create multiple modules with the same name prefix, DFC may pick up one module or none depending on the value of min_dfc_version.

    So am I correct in understanding that setting min_dfc_version to any value above the client dfc version will prevent the module from executing?

    Only if you have multiple modules with the same name prefix, in my case:

    dm_workflow, min_dfc_version=7.1
    dm_workflow..neverload, min_dfc_version=9.9

    DFC gets “confused” and picks un nothing.

    Like

  3. Thanks for clarifying Andrey. Nice trick ! will definitely be useful.
    Also, enjoy reading your articles a lot. Keep ’em coming!

    Like

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