jBPM Java implementation; what does the ExecutionContext do?

[hazica]

Hi everyone,

I have spent the last couple of days trying to figure out how jBPM works. This http://docs.jboss.com/jbpm/v3/userguide/index.html has been extremely useful.

There is however one question I can't seem to find an answer to: what is the ExecutionContext good for?

Intuitively I'd say that it probably stores information that's relevant for the entire runtime of the process instance. Having the file ExecutionContext.java in front of me as I write this, I am still clueless as to how its fields are initialised with useful information.

So, what would I like to know?

When does the ExecutionContext of a ProcessInstance get initialised? But probably more important than that, is it ProcessInstance specific? Or rather just Token-specific?

I'd really appreciate any constructive input. (Feel free to get technical on my ass!)

Thanks!

[estaub]

ExecutionContext is used to provide context for ActionHandlers. It is best not to think of it as a long-lived object - more as a "face" that JBPM exposes to ActionHandlers and other bits of client code that it calls into.

It is at least token-specific - I don't THINK more than one can exist for a given token at one time, but I'm not sure - there might be weird cases (say, when doing a join) where there might be.

Does that help?

-Ed Staub

[hazica]

Thank you for your quick reply, Ed.

Even though "at least token-specific" doesn't rule out "at most ProcessInstance-specific", I tend to concur with you on this one. What you are saying makes sense, especially when one analyses the fields of ExecutionContext: Token, Event, Action, Node, Transition, etc. Also, one of the two constructors only takes a Token as a parameter.

That being said, I think I can now manage to ask a more concrete question:

In one of the tutorials, the one with the task assignment, the task node is defined like this:

[...]
<task-node name='t'>
 <task name='change nappy'>
 <assignment class='[...].NappyAssignmentHandler'>
 </task>
</task-node>
[...]

Then, the token starts moving through the workflow, arrives at our task node t. Then, a TaskInstance object is created and... _then something magic happens_ ... and the actor we specified in the implementation of NappyAssignmentHandler appears to be a field of our TaskInstance (actorId), even though the only thing we did in NappyAssignmentHandler was this:

public void assign(Assignable assignable, ExecutionContext executionContext){
assignable.setActorId("papa");
}

I don't see any direct assignment of "papa" to TaskInstance.actorId happening anywhere. Nor do I see any indirect, multi-stage version of this assignment. And anyway, how the hell did the executionContext or the assignable Parameters get their values? Was this done by the XML Parser? Is the ExecutionContext relevant for the values of TaskInstance fields? Or am I on the completely wrong path here?

I'd really appreciate it if someone would explain to me how these "magic tricks" are performed.

Thanks for reading!

[estaub]

I don't do tasks, so I can't help much with specifics.
But the engine is supposed to set up the ExecutionContext so that everything is correct for the given ActionHandler context - so this is expected.

As for HOW - I don't know - I'd have to research it. You're probably just missing something. It sounds like you're into the engine source code - just keep breakpointing, "divide and conquer" till you see where it's happening... or just be happy that it does! ;-)

[hazica]

Indeed, breakpointing might help me figure out how this thing works. I'm on it.