Hi,

I am adding the ability to execute WorkItems as function calls in Actions defined in Drools Guvnor.

The intent is not to duplicate the invocation of Rules and WorkItems from within a process using Task nodes, but a simple means for non-jBPM users to call functions defined as WorkItems from rules.

At present, my prototype adds DRL to the RHS of a rule along these lines:-

...
when
WorkItemManager wim = drools.getWorkingMemory().getWorkItemManager();
SessionConfiguration sessionConfiguration = (SessionConfiguration) kcontext.getKnowledgeRuntime().getSessionConfiguration();
Map handlers = sessionConfiguration.getWorkItemHandlers();

WorkItemHandler wihMyStringTask = handlers.get( "MyStringTask" );
if( wihMyStringTask != null ) {
    WorkItemImpl wiMyStringTask = new WorkItemImpl();
    wiMyStringTask.getParameters().put( "Param1-string", "hello" );
    wihMyStringTask.executeWorkItem( wiMyStringTask, wim );
}

Parameters are defined as literals or bound to facts\fields in the UI.

I'm not convinced of the value of Result parameters for this use-case, as execution of the Work Item has no context, however it is possible they will end up in Working Memory and can be re-bound for use in other rules.

My concerns are that the WorkItem does not have an ID, a State or a ProcessInstanceID and I am concerned WorkItem implementations may break when signalling back to the ProcessManager (or other internal jBPM plumbing I've not come to yet). Can anybody with a greater insight of jBPM's internals comment (or am I heading towards a train wreck of biblical proportions)?

Cheers,

Mike