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