[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-user
Subject:    Re: [scxml] Questions about error events and setting workflow state
From:       Rahul Akolkar <rahul.akolkar () gmail ! com>
Date:       2011-05-13 13:24:32
Message-ID: BANLkTikqCAk4d4pEEq0YtmD+sRo4YiQWFw () mail ! gmail ! com
[Download RAW message or body]

On Fri, May 13, 2011 at 4:07 AM, Dario D <darac1111@gmail.com> wrote:
> 2011/5/12 Rahul Akolkar <rahul.akolkar@gmail.com>
>
>> On Thu, May 12, 2011 at 6:56 AM, Dario D <darac1111@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


[prev in list] [next in list] [prev in thread] [next in thread]