This depends.. and cannot be answered in a simple way. E.g. it depends on
whether there are real wait-states between the fork and the join and how soon
after one-another they reach the join (see other discussions on this)
A root token cannot be removed when there are sub-tokens (afaik) if a
Yes, I agree that what I try to describe span multiple patterns, and i think it
is important to refer to them when you model a process. As you say, it would be
a great if there were testcases that illustrate how to implement patterns :-)
I guess the use-case is not really that important in this
regarding the levels of complexity, I was referring to your first post (I was
reading that and typing a response when your second one came in.
Thanks for referring to the patterns. It can make the discussion much clearer.
Some of these patterns are new (it is a revised and better document). So t
Hi,
Im not sure what you mean by "mixing several levels of complexity and
functionality".. I tried to first describe the use-case and then how i plan to
implement it as a workflow. Does that not make sense?
I have read the white paper from van der Aalst
(http://www.workflowpatterns.com/documen
>From what I read here, you mix several levels of complexity and
>functionality... try thinking out of the box first and at a higher level. Or
>describe things in more detail for yourself first what is it exactly what
>you want
one message send, multiple receives... not knowing how many
Thanks for the reply :-)
Let me elaborate a bit:
Lets say that after sending the message to the external system, a state is
waiting for receipts. There are three possible transitions from that node:
'error', 'receipt' or 'expire'. 'receipt' is forked to some nodes and loops
back to the wait
Sounds like you wish to use a fork & join.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063486#4063486
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063486
___
jboss-user