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: Yes, we decided to use the latest snapshots until the next stable release is reached. 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

Chris, Yes, we can only assure you the work item exists between it is triggered and completed (or aborted). So if you want to access any data related to it in an on-exit action or any further part of the process, it's probably best to simply map that data to a process variable. This will make you action code a lot simpler as well. Kris Quoting Chris Raschl <c.raschl-mailinglists(a)dyless.com&gt;: http://fisheye.jboss.org/browse/JBossRules/trunk/drools-core/src/main/jav... Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm