[SCXML] Complex workflow design

[Från Claes <ti...@hotmail.com>]

Hi, I'm a bit unsure on how to proceed with SCXML to add workflow 
functionality to my rather complex chart. The chart can be seen at:

http://flickr.com/photo_zoom.gne?id=234772443&size=o

Sorry that it is in Swedish, but my problem can be visualized anyhow. 
Proceeding to "Vänta på klartecken" is straighforward, I then decided I 
needed four parallell states to handle the continuation. The problem occurs 
when these four parallell tracks depend on each other. Do you have any 
guidelines on how to handle these dependencies SCXML-wise?

The meaning of two arrows going to the same box is that both predecessors 
must be fulfilled to enter the box. Never mind the J and N arrows for now 
since they somewhat contradicts the rule I just mentioned.

Should I somehow handle dependencies with more parallell tracks, event 
conditions, joins or a combination of everything? I'm at lost here and a bit 
short of time.

Thanks,
Claes



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [SCXML] Complex workflow design

[Rahul Akolkar <ra...@gmail.com>]

On 9/5/06, Från Claes <ti...@hotmail.com> wrote:
> Hi, I'm a bit unsure on how to proceed with SCXML to add workflow
> functionality to my rather complex chart. The chart can be seen at:
>
> http://flickr.com/photo_zoom.gne?id=234772443&size=o
>
> Sorry that it is in Swedish, but my problem can be visualized anyhow.
> Proceeding to "Vänta på klartecken" is straighforward, I then decided I
> needed four parallell states to handle the continuation. The problem occurs
> when these four parallell tracks depend on each other.
<snip/>

SCXML does not permit transitions that cross into another region (such
as the chart above), since it defeats the semantics of parallelism.
However ...


> Do you have any
> guidelines on how to handle these dependencies SCXML-wise?
>
> The meaning of two arrows going to the same box is that both predecessors
> must be fulfilled to enter the box. Never mind the J and N arrows for now
> since they somewhat contradicts the rule I just mentioned.
>
> Should I somehow handle dependencies with more parallell tracks, event
> conditions, joins or a combination of everything? I'm at lost here and a bit
> short of time.
>
<snap/>

There are atleast a couple of ways to do this:

 * You may wait for a ".done" event of a sibling region, which
indicates when that sibling has reached a final state.

 * If you're waiting for something other than the final state, you may
trigger an event (name of your choice) on the parent state machine
from executable content within one region, to further the progress in
another region (which waits for that event). To do this, you must use
the <send> element, provide no target attribute and either skip the
targettype attribute or set it to "scxml" (which is the default, hence
skipping it works).

 * If you're worried about race conditions in the regions (usually
true), you can write to a progress indicator / flag in the parent
state's datamodel and author conditionals that consult it (since
events don't "persist").

-Rahul



> Thanks,
> Claes
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org