-
-
2. Re: complex process definition
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 state. 'error' are forked aswell, and looped back to the wait state. The loop is due to that I dont know how requests will be received from the external system at runtime (is this the correct way to do it?)
The 'expire' transition will go directly to the end-state.
Thinking about it, another question pops up in my head:
If one receipt comes in and go down the 'receipt' transition and during that execution a concurrent 'expire' request comes in to the wait state and put the processinstance in the end state. What will happen to the fork (or the token that is handled by the fork)?
thanks,
-Kristoffer -
3. Re: complex process definition
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... but you do know how long? and an expire is also external??? do you need bpm in this case at all? -
4. Re: complex process definition
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/documentation/documents/BPM-06-22.pdf), and it seems to me like im trying to implement "Pattern WCP-21 (Structured Loop)"
Im not sure if this is a valid case for BPM, if not, why?
Thanks for your comment :-)
-Kristoffer -
5. Re: complex process definition
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 that is why there is no example of this (yet) and the numbers have changed, so we should do something with that in the testcases.
From what I read, it is not just a structured loop for what you want. Triggers, cancellations, deferred choice etc.. that is what makes it, like you said in the subject ;-) a complex process. Not to complex, but not straightforward certainly not if there is some kind of nesting.
My remark 'do you need bpm at all' was wrong, I should have said do you want to do ALL of this IN bpm. Sometimes using just java for some parts, an esb for others and bpm at a third level is better (although not always easier to maintain in a combination)
One of the most important question is what triggers the one-of-three transitions. And What if no trigger comes in. The second one is why multiple messages could come in and what should happen then (also with the already triggered flow)? And the answer should not be how you think to model it, just in functional terms -
6. Re: complex process definition
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 case, its more of a technical matter:
1. How does concurrently (and persisted) active sub-tokens react when the root token and its process instance reach end state?
2. How does concurrently (and persisted) active sub-tokens react when the root token and its process instance are removed?
Cheers! -
7. Re: complex process definition
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 process instance is removed, the child/sub-tokens also are (btw, what is a sub-token for you, one of a sub-process or just a child-token?)
The pattterns themselves are implemented fairly simple, but combining them makes things difficult... there are some testcases for the old (2002) patterns, not for the recent 2006 updates (I'd love to do that if someone pays me to ;-))
