1

I'm struggling for 4 days now.

There's this C# Process Engine API: https://www.ibm.com/support/knowledgecenter/en/SSNW2F_5.2.1/com.ibm.p8.pe.dev.doc/web_services/ws_reference.htm

What I need to do is to retrieve the WorkflowNumber when launching the workflow, so later I can find that process in the system.

The issue here is that when you launch it - it returns the LaunchStep (the first step in the workflow) which doesn't have that ID assigned yet - it's null. The only thing available is the LaunchStep's WOBNumber.

In order to assign the Workflow ID to the step, you need to dispatch the step, so I do that:

UpdateStepRequest request = new UpdateStepRequest();
UpdateFlagEnum flag = UpdateFlagEnum.UPDATE_DISPATCH; 

request.updateFlag = flag;
request.stepElement = element; // add the launch step

session.Client.updateStep(request);

And here the funny part happens. From this point, there is complately no option to retrieve that, because StepElements are stateless, updateStep() returns nothing and the best part - the LaunchStep is now destroyed in the system, because it's a LaunchStep - it just gets destroyed after the launch.

Any tips would be appreciated!

  • From what I remember, the launch step WOB is the exact same as the workflow number. – Christopher Powell Sep 23 '17 at 14:35
  • Thanks for your response! I checked that yesterday and unfortunately it isn't. After the dispatch, I store the Launch's WOBNum. Then, I just retrieve all the steps from the roster and check if one of them has it's WorkflowNumber equal to the stored one. It doesn't :( It's really strange to me, because no matter what I do, no matter at which step I look at the Administrative Console, WobNumber is always the same as WorkflowNumber. It looks like WorkflowNumber is changing O.o Is there any chance you could help me on chat? –  Sep 23 '17 at 15:01
  • Once the item is dispatched, are you able to find that work items using Process Administrator? Possibility is that, if you have not set some mandetory property or provided some invalid input, the work item might have got terminated. Can you check the history and see what happened with the work item? – A N Sep 25 '17 at 21:27
  • The answer is .NET Process Engine API is broken since 2011. Don't use it, never, ever. Java API works fine. –  Sep 25 '17 at 21:30
  • Glad you could solve it. Since from 10 yrs working in FileNet, I always believed that, f_wobnum=f_workflownumber. Am I wrong? – bajji Sep 25 '17 at 21:44
  • You are correct, technically, at 50%. There are cases, where they aren't equal, especially, when you launch the workflow through a .net api. When a workflow 'splits' - whatever it means (I read that on ECM forums), it creates additional workobjects and gives them new WobNumbers - and this is the case, where WobNum != Workflownum. To be super clear. WorkflowNumber is a unique ID, by which you can find workflows/processes. WobNum is just a Step ID. They can be, equal, but in larger workflows - they're not. –  Sep 25 '17 at 21:50
  • Spilt is 2 new branches (parallel) forming off of one step. The new branch gets a new wob. So if you needed 2 different things happening at the same time, you would create two branches instead of one. Fields start to act wierd here (you could have different values for the same field on the different branches) and you need to have a collector step to bring both branches back to one branch. – Christopher Powell Sep 26 '17 at 11:51

0 Answers0