Hi Kris
Setting the ksession when creating the handler worked fine as long as I had a work item handler instance per request (i.e. different instances of the same handler are required to keep the ksession created per business process invocation). But then I faced problems when resuming a persisted business process: When an external event (like a userTask completion) reclaimed the persisted business process, it resumes the execution on a new work item handler instance that doesn’t know the original ksession. So I had to retrieved the persisted ksession from the DB inside the work item; but the retrieved one was not the same that the one that resumed the business process. I could have done something wrong at that time, but all the custom code could be avoided if you expose the ksession wrapped inside the WorkItemManager. Thus, work items handler would have access to the ksession that created them, and having the ksession means work items could access facts (objects) , globals, etc stored inside the ksession!
Looking forward to hearing your thoughts.
John