[scxml] Questions about error events and setting workflow state

[Dario D <da...@gmail.com>]

We're developing an application which will use SCXML for its workflow and I
would ask you for advice on a couple of topics:

1) All workflows will have a single state which is called "error". Whenever
a custom action catches an error, it will fire a derived event and this will
cause the workflow go to the "error" state. Is it possible to expand this
functionality to other execution errors? For example when an assignment is
made to an undefined variable, or when an expression error happens, to fire
an error event. I've tried making transitions that listen to "error.*" (
http://www.w3.org/TR/scxml/#ErrorEvents) but they are not being used. I was
also hoping to raise this event from ErrorReporter but we don't have a
mechanism to raise events from there.

2) One requirement for the application is to allow setting an arbitrary
state in a workflow. For example, if we have the following workflow:

A->B->C->D->E

and the workflow is currently in state D, a user should be able to move the
workflow back to state B (or any other state). We were considering to use
the following way (from the mailing list archives):

public void setState(String state) {
    Set states = getCurrentStatus().getStates();
    TransitionTarget tt = getStateMachine().getTargets().get(state);
    states.clear();
    states.add(tt);
}

Would you recommend doing it this way and how would this affect on any
context which was previously set?

Re: [scxml] Questions about error events and setting workflow state

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

On Fri, May 13, 2011 at 4:07 AM, Dario D <da...@gmail.com> wrote:
> 2011/5/12 Rahul Akolkar <ra...@gmail.com>
>
>> On Thu, May 12, 2011 at 6:56 AM, Dario D <da...@gmail.com> wrote:
>> > 2) One requirement for the application is to allow setting an arbitrary
>> > state in a workflow. For example, if we have the following workflow:
>> >
>> > A->B->C->D->E
>> >
>> > and the workflow is currently in state D, a user should be able to move
>> the
>> > workflow back to state B (or any other state). We were considering to use
>> > the following way (from the mailing list archives):
>> >
>> > public void setState(String state) {
>> >    Set states = getCurrentStatus().getStates();
>> >    TransitionTarget tt = getStateMachine().getTargets().get(state);
>> >    states.clear();
>> >    states.add(tt);
>> > }
>> >
>> > Would you recommend doing it this way and how would this affect on any
>> > context which was previously set?
>> <snap/>
>>
>> It'd likely be OK with the drawback that it hides these transitions
>> from the SCXML document (so anyone staring at the document doesn't see
>> the whole picture). The above doesn't have any effect on the set
>> context(s).
>>
>
> Thank you for your feedback, as always. In regards to the question and the
> workflow example, let's suppose that a user has set the current state to B
> after being in state D. Any local context which may have been created in
> states C and D will remain associated to those states, until it gets
> overwritten when the workflow transitions again to C and D, am I right?
>
<snip/>

Yes, you can verify with tests for your likely scenarios. Note that
when the current state is changed procedurally as above, the
corresponding onexit (state D) and onentry (state B) handlers will not
be executed which is different from an in-document <transition>.


> To continue on the same workflow example, let's supposed that the worklow is
> in state B. A bug in the workflow has been found at some later stage (states
> C, D, E) and the user would like to correct this bug before continuing
> execution of the workflow. Restarting the workflow is not a good idea
> because actions executed in states A and B are too expensive to be repeated.
> He corrects this bug and creates a new version of the worfklow model. The
> application will then call the following method on the existing executor:
>
> exec.setStateMachine(newWorkflowModel);
>
> This effectively means that the above method would would've been called
> twice on the executor (when the executor was first created before exec.go(),
> and after the workflow has been corrected). Is this the right thing to do
> and again, how would it affect the context which was made during
> initialization of the worklow and in states A and B? If this is not a good
> idea, can you suggest any alternatives?
>
<snap/>

SCXML is not really designed for dynamic workflows and thereby,
neither is Commons SCXML. The model / state machine is assumed to be
immutable once the executor is set in motion. Having said that, doing
something like the above is possible with a good understanding of the
internals of Commons SCXML. I'd start by augmenting the existing state
machine (SCXML class instance) rather than creating a new one since
the references to states are maintained in internal book-keeping for
contexts etc. and passing an altogether new object once the executor
is in motion (like "newWorkflowModel" above) would disrupt all that.
Something like:

  SCXML machine = exec.getStateMachine();
  // manipulate machine, read SCXMLParser and ModelUpdater classes
  // in scxml.io package to understand all necessary changes

To sum it up -- above be dragons.

As an alternative, I'd suggest the following:
(1) Use a flat context for entire state machine (use custom evaluator,
override newContext() in existing evaluator impl always return same
context instance, set same as root context) -- flat is actually what
the spec recommends now
(2) When the workflow needs to be remedied, create a brand new
executor with remedied workflow/machine and set it in motion
(3) Update the current state programmatically as code snippet in your
note above to current state of old exec
(4) Transfer root context from old exec to new and use same evaluator
instance as before
(5) Optionally, old exec instance may now be destroyed

-Rahul

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

Re: [scxml] Questions about error events and setting workflow state

[Dario D <da...@gmail.com>]

2011/5/12 Rahul Akolkar <ra...@gmail.com>

> On Thu, May 12, 2011 at 6:56 AM, Dario D <da...@gmail.com> wrote:
> > 2) One requirement for the application is to allow setting an arbitrary
> > state in a workflow. For example, if we have the following workflow:
> >
> > A->B->C->D->E
> >
> > and the workflow is currently in state D, a user should be able to move
> the
> > workflow back to state B (or any other state). We were considering to use
> > the following way (from the mailing list archives):
> >
> > public void setState(String state) {
> >    Set states = getCurrentStatus().getStates();
> >    TransitionTarget tt = getStateMachine().getTargets().get(state);
> >    states.clear();
> >    states.add(tt);
> > }
> >
> > Would you recommend doing it this way and how would this affect on any
> > context which was previously set?
> <snap/>
>
> It'd likely be OK with the drawback that it hides these transitions
> from the SCXML document (so anyone staring at the document doesn't see
> the whole picture). The above doesn't have any effect on the set
> context(s).
>

Thank you for your feedback, as always. In regards to the question and the
workflow example, let's suppose that a user has set the current state to B
after being in state D. Any local context which may have been created in
states C and D will remain associated to those states, until it gets
overwritten when the workflow transitions again to C and D, am I right?

To continue on the same workflow example, let's supposed that the worklow is
in state B. A bug in the workflow has been found at some later stage (states
C, D, E) and the user would like to correct this bug before continuing
execution of the workflow. Restarting the workflow is not a good idea
because actions executed in states A and B are too expensive to be repeated.
He corrects this bug and creates a new version of the worfklow model. The
application will then call the following method on the existing executor:

exec.setStateMachine(newWorkflowModel);

This effectively means that the above method would would've been called
twice on the executor (when the executor was first created before exec.go(),
and after the workflow has been corrected). Is this the right thing to do
and again, how would it affect the context which was made during
initialization of the worklow and in states A and B? If this is not a good
idea, can you suggest any alternatives?

Re: [scxml] Questions about error events and setting workflow state

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

On Thu, May 12, 2011 at 6:56 AM, Dario D <da...@gmail.com> wrote:
> We're developing an application which will use SCXML for its workflow and I
> would ask you for advice on a couple of topics:
>
> 1) All workflows will have a single state which is called "error". Whenever
> a custom action catches an error, it will fire a derived event and this will
> cause the workflow go to the "error" state. Is it possible to expand this
> functionality to other execution errors? For example when an assignment is
> made to an undefined variable, or when an expression error happens, to fire
> an error event. I've tried making transitions that listen to "error.*" (
> http://www.w3.org/TR/scxml/#ErrorEvents) but they are not being used. I was
> also hoping to raise this event from ErrorReporter but we don't have a
> mechanism to raise events from there.
>
<snip/>

Your observations are correct, Commons SCXML v0.9 is not upto date
with respect to the latest spec changes. You may open an issue for
this, a patch will ensure its attended to sooner if you're so inclined
-- need to add the error event to the set of derived ones on catching
ExpressionException in SCXMLSemanticsImpl.

WRT approaches:
 * An ErrorReporter implementation could be used, one that maintains a
reference to the SCXMLExecutor instance its attached to and fires
events asynchronously after a short delay
 * Better yet, one could maintain an external event queue where
various components can add events (ErrorReporter being one) and these
get triggered in the order added
 * Best fix is the semantics impl change along above lines


> 2) One requirement for the application is to allow setting an arbitrary
> state in a workflow. For example, if we have the following workflow:
>
> A->B->C->D->E
>
> and the workflow is currently in state D, a user should be able to move the
> workflow back to state B (or any other state). We were considering to use
> the following way (from the mailing list archives):
>
> public void setState(String state) {
>    Set states = getCurrentStatus().getStates();
>    TransitionTarget tt = getStateMachine().getTargets().get(state);
>    states.clear();
>    states.add(tt);
> }
>
> Would you recommend doing it this way and how would this affect on any
> context which was previously set?
<snap/>

It'd likely be OK with the drawback that it hides these transitions
from the SCXML document (so anyone staring at the document doesn't see
the whole picture). The above doesn't have any effect on the set
context(s).

-Rahul

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