【spring statemachine】Using Actions

Reference documentation link

Using Actions

From a user perspective, actions are one of the most useful components that can interact and collaborate with state machines. Actions can be performed at different places in a state machine and its state lifecycle, such as entering or exiting states or during transitions.

@Override
public void configure(StateMachineStateConfigurer<States, Events> states)
        throws Exception {
    states
        .withStates()
            .initial(States.SI)
            .state(States.S1, action1(), action2())
            .state(States.S2, action1(), action2())
            .state(States.S3, action1(), action3());
}

The above action1and action2beans are attached to the entry and exit of the state respectively.

@Bean
public Action<States, Events> action1() {
    return new Action<States, Events>() {

        @Override
        public void execute(StateContext<States, Events> context) {
        }
    };
}
@Bean
public BaseAction action2() {
    return new BaseAction();
}

@Bean
public SpelAction action3() {
    ExpressionParser parser = new SpelExpressionParser();
    return new SpelAction(
            parser.parseExpression(
                    "stateMachine.sendEvent(T(org.springframework.statemachine.docs.Events).E1)"));
}

public class BaseAction implements Action<States, Events> {

    @Override
    public void execute(StateContext<States, Events> context) {
    }
}

public class SpelAction extends SpelExpressionAction<States, Events> {

    public SpelAction(Expression expression) {
        super(expression);
    }
}

You can implement Action directly as an anonymous function, or create your own implementation and define the corresponding implementation as a bean. In action3, the SpEL expression is used to send the event Events.E1 to the state machine.

Using StateContext

StateContext is one of the most important objects when dealing with state machines, as it is passed into various methods and callbacks to give the current state of the state machine and what might happen to it. If simplified a bit, it can be thought of as a snapshot of the current state machine phase passed by the StateContext.

** _ In Spring Statemachine 1.0.xStateContext, it's simpler to use, in terms of how to use it as a simple POJO. _**

** It's role has been greatly improved from the beginning to make it a first class citizen in a state machine. Spring Statemachine 1.1.x**

Available in the overall StateContext.

• Access the latest Message, Event or their MessageHeaders if known.
• Access the state machine Extended State.
• Visit StateMachine yourself.
• Access possible state machine errors.
• Transition, if applicable, access the latest version.
• Access the source and target states from which the state machine may enter and go.
• Stage access current.

The StateContext is passed into the various components Guard that interact with the user likeAction and.

_ Stage is a representation of the stage state machine is currently interacting with the user. The current stages are EVENT_NOT_ACCEPTED, EXTENDED_STATE_CHANGED, STATE_CHANGED, STATE_ENTRY, STATE_EXIT, STATEMACHINE_ERROR, STATEMACHINE_START, STATEMACHINE_STOP, TRANSITION, TRANSITION_START and TRANSITION_END It looks like those matches are very familiar with how the user can interact with the listener described in, there are some use cases just wondering about the state machine what happened, react to something or just log for debugging purposes. SSM provides an interface for adding listeners, and then provides options to get callbacks when various state changes, actions, etc. occur.

You basically have two options, either listen to Spring application context events or attach the listener directly to the state machine. These will basically all provide the same information, one generates events as event classes and the other generates callbacks via the listener interface. Both have advantages and disadvantages, which will be discussed later. _