[rules-users] WorkItemNodeInstance and the on exit action

Chris Raschl c.raschl-mailinglists at dyless.com
Mon Jul 12 05:31:11 EDT 2010


Hi Salaboy,
thanks for your response. Summing up I can say it was mostly lack
of understanding on my side... Kris's fix just made it visible. Please
let me know if I'm on the right track, my comments are inline.


Am 09.07.2010 16:56, schrieb Salaboy:
> Hi man, 
> Did you recognize this error after update?

Yes, we decided to use the latest snapshots until the next
stable release is reached.

> Why are you doing that if you have the human tasks Apis to complete a task that automatically set the result values.
>
> I would like to take a look at your issue, can you provide me more info about it?

We wanted to remove mina, since it added unnecessary complexity
to our case. To create human tasks we implemented our own human task
handler, based on the CommandBasedWSHumanTaskHandler and its ResponseHandlers,
but we've injected (we're using seam) a TaskServiceSession directly.
Additionally we added some logic to persist sessionId, processId, workItemId
and taskId when a task is created to load the session correctly when the task
is finished. That worked fine so far until the upgrade, caused by the
patch by kris.

I digged into the code again, there are three places I found related to passing
data from the human task to the process.

1.) GetResultContentResponseHandler, which finishes the work item and passes
entered data to the WorkItemManager. If a map is given it's contents are also
added to the result.

2.) The JPAWorkItemManager itself which sets the results into the workItem using
workItem.setResults(results) and then signals completion.

3.) Then triggerCompleted is called on the work Item and out-mappings are processed.

Knowing this i tried some mappings:

1.) Map the whole result and process it later in the on exit action or a seperated
action node.

<mapping type="out" from="Result" to="latestHumanTaskResult" />

2.) Or map the required variable, either from the result map or directly.

<mapping type="out" from="Result['key']" to="processVariable" />
<mapping type="out" from="key" to="processVariable" />

Both work like a charm. From this point of view I don't know why we used the
WorkItemNodeInstance and WorkItem in our exit action, there is no need to.
Further it adds an unnecessary dependency to the process definition.

Problem solved.

Thanks,
chris



> On Jul 9, 2010, at 11:22, Chris Raschl <c.raschl-mailinglists at dyless.com> wrote:
> 
>> Hi Kris,
>> we experienced some troubles with our drools flow integration today
>> (we upgraded to the lastest snapshot) and I found out that is has to
>> do with a fix (see [1]) you commited some time ago.
>>
>> Our problem is, that we access the data submitted by the user to
>> finish a human task in the on exit action of the human task node
>> like this:
>>
>> WorkItemNodeInstance wini = (WorkItemNodeInstance)context.getNodeInstance();
>> Map<String, Object> result = (Map<String, Object>)wini.getWorkItem().getResult("Result");
>>
>> This results in a NPE because the workItemId is set to -1 in the WorkItemNodeInstance
>> before getWorkItem() is called. So getWorkItem() returns null.
>>
>> Is there a better (recommended) way to work with human task data? Maybe using an
>> out-mapping?
>>
>> Thanks,
>> chris
>>
>> [1] http://fisheye.jboss.org/browse/JBossRules/trunk/drools-core/src/main/java/org/drools/workflow/instance/node/WorkItemNodeInstance.java?r1=32801&r2=
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
> 
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
> 
> 




More information about the rules-users mailing list