Token.signal() ---> 2 tokens?| JBoss.org Content Archive (Read Only)

15. Re: Token.signal() ---> 2 tokens?

kukeltje Feb 21, 2008 2:02 PM (in response to qpool.char)

Good catch Martin.... so there was something 'strange' in the code, I just missed it... shame one me.

A full client based assignment is (afaik) seldomly fount. In most of the situations the states (not to be confused with the state nodes) are either signalled by a human, or async after the execution of some action. When using async nodes, the token is 'known' to the code that signals the node again. That way it does not have to have knowledge about the processdefinition but just the one token that needs to be signalled. Kind of what happens with tasknodes where the tokens are 'known' in a task list and can be signalled without knowing the processdefinition

Regarding the unit test, they avoid dealing with it....

Btw, Client based assignment only shows up on google for the jbpm 2.0 docs. Is that where you read it? (I cannot check the 3.x docs since I have no full access to the source here)

16. Re: Token.signal() ---> 2 tokens?

pojomonkey Feb 22, 2008 4:38 AM (in response to qpool.char)

"kukeltje" wrote:
In most of the situations the states (not to be confused with the state nodes) are either signalled by a human, or async after the execution of some action.

Please, can you clarify what the difference is between 'the states' and 'the state nodes'? I am taking a token being at a state node to present a given process state, and then the node-enter events can indicate the transition into a state.

"kukeltje" wrote:
When using async nodes, the token is 'known' to the code that signals the node again. That way it does not have to have knowledge about the processdefinition but just the one token that needs to be signalled.

Hmm, I think I follow that - will have to let that stew with the rest of my understanding of jBPM so far and see if some epiphany results.

"kukeltje" wrote:

Btw, Client based assignment only shows up on google for the jbpm 2.0 docs. Is that where you read it?

Yes. I wouldn't have expected that capability to have been 'lost'. If jBPM is no longer capable/suitable, then I need to find that out pretty soon!

Based on the various comments and reading that I've done, I've now tried pushing the tokens through the flow by only signalling a token when it has no active children, and if it has to signal the children (unless they have active children etc.) - that seems to 'work' insofar that the root token ends up in the terminal state.

Like this:

 private boolean signalTokens(Token token)
 {
 if (token.hasEnded())
 return true;

 Map children = token.getActiveChildren();

 if (children.size() == 0)
 {
 token.signal();
 }
 else
 {
 Collection ct = children.values();
 Iterator it = ct.iterator();

 while (it.hasNext())
 {
 Token child = (Token)it.next();
 while (!signalTokens(child))
 ;
 }
 }

 return false;
 }

17. Re: Token.signal() ---> 2 tokens?

kukeltje Feb 22, 2008 10:14 AM (in response to qpool.char)

Please, can you clarify what the difference is between 'the states' and 'the state nodes'?

I probably should have said 'wait-states' and state-nodes. task-nodes are generally also wait-states, and the generic 'node' can be made into a wait state or auto-transitioning node by adding java code to it

If jBPM is no longer capable/suitable, then I need to find that out pretty soon!

No, not much has changed. Maybe the behaviour around this signalling of the root-token (or any subtoken that arrives at a fork) has.

Your 'solution' seems ok, but I wonder what the advantage is in doing it this way. You can use 'node' instead of 'state' which can auto-transition if finished. No need to signal at all then. Might have some disadvantages also, but probably less if you use them where applicable and async states where possible.

18. Re: Token.signal() ---> 2 tokens?

pojomonkey Feb 22, 2008 10:41 AM (in response to qpool.char)

"kukeltje" wrote:
I probably should have said 'wait-states' and state-nodes.

OK - I understand all that :)

"kukeltje" wrote:
Your 'solution' seems ok, but I wonder what the advantage is in doing it this way.

My 'solution' is just an illustration that shows how to signal the tokens and how to determine when not to signal parent tokens.

Main advantage to me was that it illustrates the whole issue much better than anything I'd seen.

"kukeltje" wrote:
You can use 'node' instead of 'state' which can auto-transition if finished.

Indeed, but I specifically do NOT want an auto-finishing state, but one that continues the execution path following an 'external' event. Granted - the sample code doesn't show that, but has helped me to see the way forward.

Is there any way to attach a (zip) file to a post here? When I get a working example I'd be happy to share the code.

19. Re: Token.signal() ---> 2 tokens?

kukeltje Feb 22, 2008 10:59 AM (in response to qpool.char)

Is there any way to attach a (zip) file to a post here? When I get a working example I'd be happy to share the code.

Sorry, no... but you can post it on the wiki and put the link here. Just make sure you give the page a meaningful name.

20. Re: Token.signal() ---> 2 tokens?

pojomonkey Feb 25, 2008 12:20 PM (in response to qpool.char)

"kukeltje" wrote:
Is there any way to attach a (zip) file to a post here? When I get a working example I'd be happy to share the code.

Sorry, no... but you can post it on the wiki and put the link here. Just make sure you give the page a meaningful name.

I added an entry to the JbpmExampleApplications page - seemed a good place:

http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmExampleApplications

I hope it helps others to figure out how to use jBPM.