Creating workflow via DFC in job method fails to instantiate process variables

steve.savini
edited November 21, 2011 in Documentum #1

Really struggling with some development on 6.5 SP2 with Workflow Template created in Process Builder with Process variables defined.

I am attempting to create a job/method that looks for past due documents and then kicks off the workflow template for each one. I have a method class developed that has DFC code to kick off the workflow similar to the following:

dfProc = (IDfProcess)session.getObjectByQualification("dm_process where object_name = '<name>'");
IDfWorkflowBuilder wfBuilder = session.newWorkflowBuilder(dfProc.getObjectId());
wfBuilder.initWorkflow();
wfBuilder.runWorkflow();

etc.

When I run this within my eclipse IDE from my client (via main method for testing), it works great. However, when I deploy the class and kick it off from dm_job and it runs under JMS, I get errors for each process variable:

[DM_WORKFLOW_E_NO_SD_ELEMENT_INSTANCE]error: "The instance of the Structured Data Element, status_off, does not exist for the workflow, 4d00b23880000d47."; ERRORCODE: 100; NEXT: DfException:: THREAD: http-0.0.0.0-9080-2;

Saw another posting that indicated the code is not invoking the DfWorkflowEx class provided with BP when run under JMS.

https://community.emc.com/message/92111

It suggested it was a classpath issue. I have tried to update the classpath environment varable; the JMS classpath config; and have copied bmp_infra.jar in every path referenced by classpath on the content server where JMS is running. Very frustrating. Any help greatly appreciated.

Another issue: when I run from client and it does succesfully create the workflow, the activity name does not reflect the dynamic activity name as configured via process builder (I have tacked on component name); it only has the static portion of the name for the activity and is ignoring the dynamic part.

Thanks,

ss

Tagged:

Comments

  • xchen
    edited December 3, 2009 #2

    Instead of modifying the classpath, or moving different jar files, one workaround will be :

    1. Create a process which does not have SDT variables, which has an "Invoke Process" activity to run the real process.

    2. Call this process in the job instead of the real one.

    Best Regards,

  • CláudioGil
    edited December 3, 2009 #3

    That was exactly the solution we used for a similar problem. The Document Export module from InputAccel also misses the bpm_infra.jar so it can't start processes with variables (nor with two packages but that's another problem ).

    Regarding the activity name issue, I always get confused with the sintax and the varialbes that represent certain dynamic parts. Check if you are using the right element and try the setting "Store document name to the package at runtime" in the process properties.

  • tusharinamdar
    edited December 3, 2009 #4

    Please inclue bpm_infra.jar in your classpath. Do let us know if that fixes your issue.

    Missed the part that you have tried that already.

  • steve.savini
    edited December 6, 2009 #5

    Update: Still have not sorted out the classpath issue, and I have given up on that. I created a one-step workflow stub without any process variables that uses the BP activity template to call my existing workflow as a sub process. I am now launching this workflow stub via DFC and that did the trick. This also cured my problem with the dynamic task naming; the tasks now show the dynamically generated name in the inbox.

    Still interested in the classpath issue resolution if anyone has figured it out.

  • tusharinamdar
    edited December 7, 2009 #6

    Hi Steve,

    Is your method a workflow method ? If not, can you try extending from WorkflowMethod instead of implementing IDfMethod ?

    Executing the following worked for me in Java Method Server:

    public class MyWorkflowMethod extends WorkflowMethod {    @Override
        protected int doTask(IDfWorkitem workitem, IDfProperties activityParameters, PrintWriter printWriter) throws Exception {
            IDfSession session = getSession(); // Implement getSession() to get your session
            IDfProcess dfProc = (IDfProcess) session.getObjectByQualification("dm_process where object_name = 'MyProcess'");
            IDfWorkflowBuilder wfBuilder = session.newWorkflowBuilder(dfProc.getObjectId());
            wfBuilder.initWorkflow();
            wfBuilder.runWorkflow();
            IDfWorkflow wfObj = wfBuilder.getWorkflow();
            return 0;
        }}

    I tried invoking this method and it worked fine.

    Do let me know if this works for you.

    Tushar.

  • shailshah
    edited December 7, 2009 #7
    Not sure if you resolved this issue. If you put bpm_infra.jar in the classpath of the JBOSS method server, it will solve your problem. When you run standalone, DFC uses IDfProcessEx and IDfWorkflowEx interfaces which support SDTs, but when ran as job/method, DFC uses IDfProcess and IDfWorkflow interfaces which causes the error. Once you put bpm_infra.jar as the first one in the classpath for JBOSS JMS, it fixes the problem.
  • YSokolov
    edited June 9, 2010 #8

    Hi,

    we've just solved the problem. When installing your method definition you should mark a checkbox 'Use as workflow method'. This mark not only allows to use the method in auto-activity, but shifts the method's execution onto different agent (bpm).

    No extra bpm_infra.jar is needed.

  • chiranjeevi
    edited November 20, 2011 #9

    Thanks for the solution..It worked...I wasted almost a week to resolve it..finally your solution was break through...

  • JorgKrause
    edited November 21, 2011 #10

    Hi,

    even if this is an old post, and the solution is given, here's a workaround for this scenario, which also gives you the possibility to actually initialize some of your SDT objects

    The code does evaluate the process template through a query, stores SDT information, and creates the SDT objects as well. I guess pretty much the same as it's done inside bpm

    private static String QRY_PROCESS = "select pr.r_object_id,pr.object_name,pr.sd_element_type,pr.sd_element_name,pr.i_folder_id,ti.element_type_name "
    + "from dm_process pr,dmc_wfsd_type_info ti "
    + "where pr.r_object_id = '%%ID%%' "
    + "and ti.r_object_id=pr.sd_element_type "
    + "ENABLE (ROW_BASED)";


    IDfId processId = null;
    String processName = null;
    String folderId = null;
    List<String> sdtName = new ArrayList<String>();
    List<IDfId> sdtTypeId = new ArrayList<IDfId>();
    List<String> sdtTypeName = new ArrayList<String>();

    IDfQuery oQry = new DfQuery();
    oQry.setDQL(QRY_PROCESS.replace("%%ID%%", m_processId));
    coll = oQry.execute(m_session, IDfQuery.DF_READ_QUERY);
    while (coll.next()) {
    if (processId == null)
      processId = coll.getId("r_object_id");
    if (processName == null)
      processName = coll.getString("object_name");
      if (folderId == null && coll.getString("i_folder_id").length() == 16)
       folderId = coll.getString("i_folder_id");
      sdtName.add(coll.getString("sd_element_name"));
      sdtTypeId.add(coll.getId("sd_element_type"));
      sdtTypeName.add(coll.getString("element_type_name"));
    }
    if (processId == null)
    throw new Exception("Process not found");
    coll.close();

    IDfWorkflowBuilder oWFBuilder = m_session.newWorkflowBuilder(processId);
    IDfWorkflow oWF = oWFBuilder.getWorkflow();
    oWF.setObjectName(processName + " for testing sdt instantiation");
    oWFBuilder.initWorkflow();for (int i = 0; i < sdtTypeName.size(); i++) {
    IDfSysObject oSDT = (IDfSysObject) m_session.newObject(sdtTypeName.get(i));
    oSDT.setObjectName(sdtName.get(i));
    oSDT.setId("sd_type_info_id", sdtTypeId.get(i));
    oSDT.setId("workflow_id", oWF.getObjectId());
    oSDT.setId("process_id", processId);
    oSDT.link(folderId);
    oSDT.saveLock();
    DfLogger.debug(this, "Created sdt object " + oSDT.getObjectName() + " of type " + oSDT.getTypeName() + " with id "
       + oSDT.getObjectId().getId(), null, null);
    }oWFBuilder.runWorkflow();

    Regards

    Jørg

  • Bibhu
    edited November 21, 2011 #11

    When installing Java Method definition we should mark a checkbox 'Use as workflow method' or we have to set the a_special_app='Workflow' for Java Methods.

    This, not only allows to use the method in auto-activity, but shifts the method's execution onto different agent (bpm). In case of dm_method the method execution is under "ServerApp.ear" deployment. Only moving the method execution environment will fix the issue.