Заводим Spring StateMachine

По сути все что требуется сделать это получать каждый раз при обращении к объекту новый bean из applicationContext. Inject-ать applicationContext в бизнес-логику грех, поэтому bean statemachine должен либо реализовывать интерфейс с хотя бы одним методом, либо абстрактный метод, который при объявлении в java — конфиге будет реализован, а в реализации мы запросим у applicationContext новый bean, а иметь в config классе ссылку на applicationContext нормальная практика, и через абстрактный метод мы будет вызвать из контекста .getBean();

        states
                .withStates()
                .initial(NEW)
                .end(PURCHASE_COMPLETE)
                .state(randomAction())

он будет выполняться асинхронно, предполагается что если вы например говорите .stateEntry(), то action должен быть выполнен при входе, но если вы говорите .state() значит action() должен быть выполнен в целевом state, но не так важно когда именно.

В нашем проекте мы сконфигурировали все action() на transition конфиге, благо навешивать их можно по нескольку на один переход.

Все Action и Guard обычные bean-ы, реализующие интерфейсы Action и Guard соответственно.

Окончательная версия конфига будет выглядеть так:

@Configuration
@EnableStateMachineFactory
public class StateMachineConfig extends EnumStateMachineConfigurerAdapter<PurchaseState, PurchaseEvent> {

    @Override
    public void configure(final StateMachineConfigurationConfigurer<PurchaseState, PurchaseEvent> config) throws Exception {
        config
                .withConfiguration()
                .autoStartup(true)
                .listener(new PurchaseStateMachineApplicationListener());
    }

    @Override
    public void configure(final StateMachineStateConfigurer<PurchaseState, PurchaseEvent> states) throws Exception {
        states
                .withStates()
                .initial(NEW)
                .end(PURCHASE_COMPLETE)
                .stateEntry()
                .stateExit()
                .state()
                .states(EnumSet.allOf(PurchaseState.class));

    }

    @Override
    public void configure(final StateMachineTransitionConfigurer<PurchaseState, PurchaseEvent> transitions) throws Exception {
        transitions
                .withExternal()
                .source(NEW)
                .target(RESERVED)
                .event(RESERVE)
                .action(reservedAction(), errorAction())

                .and()
                .withExternal()
                .source(RESERVED)
                .target(CANCEL_RESERVED)
                .event(RESERVE_DECLINE)
                .action(cancelAction(), errorAction())

                .and()
                .withExternal()
                .source(RESERVED)
                .target(PURCHASE_COMPLETE)
                .event(BUY)
                .guard(hideGuard())
                .action(buyAction(), errorAction());
    }

    @Bean
    public Action<PurchaseState, PurchaseEvent> reservedAction() {
        return new ReservedAction();
    }

    @Bean
    public Action<PurchaseState, PurchaseEvent> cancelAction() {
        return new CancelAction();
    }

    @Bean
    public Action<PurchaseState, PurchaseEvent> buyAction() {
        return new BuyAction();
    }

    @Bean
    public Action<PurchaseState, PurchaseEvent> errorAction() {
        return new ErrorAction();
    }

    @Bean
    public Guard<PurchaseState, PurchaseEvent> hideGuard() {
        return new HideGuard();
    }

    @Bean
    public StateMachinePersister<PurchaseState, PurchaseEvent, String> persister() {
        return new DefaultStateMachinePersister<>(new PurchaseStateMachinePersister());
    }

Сделаем контроллер:

@RestController
@SuppressWarnings("unused")
public class PurchaseController {

    private final PurchaseService purchaseService;

    public PurchaseController(PurchaseService purchaseService) {
        this.purchaseService = purchaseService;
    }

    @RequestMapping(path = "/reserve")
    public boolean reserve(final String userId, final String productId) {
        return purchaseService.reserved(userId, productId);
    }

    @RequestMapping(path = "/cancel")
    public boolean cancelReserve(final String userId) {
        return purchaseService.cancelReserve(userId);
    }

    @RequestMapping(path = "/buy")
    public boolean buyReserve(final String userId) {
        return purchaseService.buy(userId);
    }

}

интерфейс сервиса

public interface PurchaseService {
    /**
     * Резервирование товара перед покупкой, зарезервированный товар может находиться в корзине сколько угодно долго
     *
     * @param userId    id пользователя, так как приложение простое, для того чтоб различать пользователей id будем
     *                  принимать прямо в http-запросе
     * @param productId id продукта, который начинает процедуру покупки
     * @return успешная/не успешная операция, в нашем примере операция может стать не успешной если при попытке восстановить
     * машину их импровизированного репозитория произойдет ошибка.
     */
    boolean reserved(String userId, String productId);

    /**
     * Отмена резервирования товара/удаление из пользовательской корзины
     *
     * @param userId id пользователя, так как приложение простое, для того чтоб различать пользователей id будем
     *               принимать прямо в http-запросе
     * @return успешная/не успешная операция, в нашем примере операция может стать не успешной если при попытке восстановить
     * машину их импровизированного репозитория произойдет ошибка.
     */
    boolean cancelReserve(String userId);

    /**
     * Покупка ранее зарезервированного товара
     *
     * @param userId id пользователя, так как приложение простое, для того чтоб различать пользователей id будем
     *               принимать прямо в http-запросе
     * @return успешная/не успешная операция, в нашем примере операция может стать не успешной если при попытке восстановить
     * машину их импровизированного репозитория произойдет ошибка.
     */
    boolean buy(String userId);
}

Следующий важный момент, это то как вы будете восстанавливать состояние своей машины, ведь на каждое обращение будет создан новый bean, который ничего про ваши предыдущие статусы машины не знает.

Для этих целей в spring statemachine есть механизм Persistens:

public class PurchaseStateMachinePersister implements StateMachinePersist<PurchaseState, PurchaseEvent, String> {

    private final HashMap<String, StateMachineContext<PurchaseState, PurchaseEvent>> contexts = new HashMap<>();

    @Override
    public void write(final StateMachineContext<PurchaseState, PurchaseEvent> context, String contextObj) {
        contexts.put(contextObj, context);
    }

    @Override
    public StateMachineContext<PurchaseState, PurchaseEvent> read(final String contextObj) {
        return contexts.get(contextObj);
    }
}

Для нашей наивной реализации мы используем в качестве хранилища состояний обычную Map, в не наивной реализации это будет какая то БД, обратите внимание на третий generic типа String, это ключ по которому будет сохраняться состояние вашей машины, со всеми статусами, переменными в контексте, id и тд. В своей примере я использовал id пользователя для ключа сохранения, что может быть указан совершенно любой ключ(session_id пользователя, уникальный логин и т.д.).

stateMachine
                .getStateMachineAccessor()
                .doWithAllRegions(access -> {
                    access.resetStateMachine(new DefaultStateMachineContext<>({ResetState}, null, null, null, null));
                });
stateMachine.start();
stateMachine.sendEvent({NewEventFromResetState});

Реализацию сервиса рассмотрим в каждом методе:

    @Override
    public boolean reserved(final String userId, final String productId) {
        final StateMachine<PurchaseState, PurchaseEvent> stateMachine = stateMachineFactory.getStateMachine();
        stateMachine.getExtendedState().getVariables().put("PRODUCT_ID", productId);
        stateMachine.sendEvent(RESERVE);
        try {
            persister.persist(stateMachine, userId);
        } catch (final Exception e) {
            e.printStackTrace();
            return false;
        }
        return true;
    }

Получаем из фабрики машину(фабрика за-inject-ана в класс, bean ее мы объявили и настроили в конфиге), кладем в контекст машины параметр, в нашем случае это некий productId, так как машина при старте контекста запускается автоматически и инит статус NEW, то бросаем event на резервирование товара.

Оставшиеся два метода похожи:

    @Override
    public boolean cancelReserve(final String userId) {
        final StateMachine<PurchaseState, PurchaseEvent> stateMachine = stateMachineFactory.getStateMachine();
        try {
            persister.restore(stateMachine, userId);
            stateMachine.sendEvent(RESERVE_DECLINE);
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
        return true;
    }

    @Override
    public boolean buy(final String userId) {
        final StateMachine<PurchaseState, PurchaseEvent> stateMachine = stateMachineFactory.getStateMachine();
        try {
            persister.restore(stateMachine, userId);
            stateMachine.sendEvent(BUY);
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
        return true;
    }

Здесь мы сначала восстанавливаем состояние машины для userId конкретного пользователя, а затем бросаем event, который соответствует методу api.

В качестве реализации Action мы получим id продукта из контекста машины и выведем в лог сообщение, соответствующее переходу, для примера приведу код reservedAction():

public class ReservedAction implements Action<PurchaseState, PurchaseEvent> {
    @Override
    public void execute(StateContext<PurchaseState, PurchaseEvent> context) {
        final String productId = context.getExtendedState().get("PRODUCT_ID", String.class);
        System.out.println("Товар с номером " + productId + " зарезервирован.");
    }
}

Нельзя не сказать про listener, который из коробки предлагает довольно много сценариев, на которые его можно навесить, посмотрите сами:

public class PurchaseStateMachineApplicationListener implements StateMachineListener<PurchaseState, PurchaseEvent> {
    @Override
    public void stateChanged(State<PurchaseState, PurchaseEvent> from, State<PurchaseState, PurchaseEvent> to) {
        if (from.getId() != null) {
            System.out.println("Переход из статуса " + from.getId() + " в статус " + to.getId());
        }
    }

    @Override
    public void stateEntered(State<PurchaseState, PurchaseEvent> state) {

    }

    @Override
    public void stateExited(State<PurchaseState, PurchaseEvent> state) {

    }

    @Override
    public void eventNotAccepted(Message<PurchaseEvent> event) {
        System.out.println("Евент не принят " + event);
    }

    @Override
    public void transition(Transition<PurchaseState, PurchaseEvent> transition) {

    }

    @Override
    public void transitionStarted(Transition<PurchaseState, PurchaseEvent> transition) {

    }

    @Override
    public void transitionEnded(Transition<PurchaseState, PurchaseEvent> transition) {

    }

    @Override
    public void stateMachineStarted(StateMachine<PurchaseState, PurchaseEvent> stateMachine) {
        System.out.println("Machine started");
    }

    @Override
    public void stateMachineStopped(StateMachine<PurchaseState, PurchaseEvent> stateMachine) {

    }

    @Override
    public void stateMachineError(StateMachine<PurchaseState, PurchaseEvent> stateMachine, Exception exception) {
    }

    @Override
    public void extendedStateChanged(Object key, Object value) {

    }

    @Override
    public void stateContext(StateContext<PurchaseState, PurchaseEvent> stateContext) {

    }
}

Единственная проблемка в том что это интерфейс, а значит нужно все эти методы реализовать, но так как они вряд ли понадобятся вам все, часть из них будет висеть пустыми, на что coverage скажет что методы не покрыты тестами.

Тут в lisener-е мы можем навесить совершенно любые метрики, на совершенно разные события машины.

В качестве проверки того что мы сделали выполним два кейса:

• 1. Резервирование и последующий отказ от покупки. отправим приложению запрос на URI "/reserve", с параметрами userId=007, productId=10001, а следом за ним запрос "/cancel" c параметром userId=007 вывод консоли будет следующим:

  Machine started
Товар с номером 10001 зарезервирован.
Переход из статуса NEW в статус RESERVED
Machine started
Резервирование товара 10001 отменено
Переход из статуса RESERVED в статус CANCEL_RESERVED

• 2. Резервирование и успешная покупка:

  Machine started
Товар с номером 10001 зарезервирован.
Переход из статуса NEW в статус RESERVED
Machine started
Товар с номером 10001 успешно куплен
Переход из статуса RESERVED в статус PURCHASE_COMPLETE

Заключение

В заключении приведу пример тестирования фреймфорка, думаю из кода все станет понятно, необходима лишь зависимость на тест машины, и можно проверять конфигурацию декларативно.

   @Test
    public void testWhenReservedCancel() throws Exception {
        StateMachine<PurchaseState, PurchaseEvent> machine = factory.getStateMachine();
        StateMachineTestPlan<PurchaseState, PurchaseEvent> plan =
                StateMachineTestPlanBuilder.<PurchaseState, PurchaseEvent>builder()
                        .defaultAwaitTime(2)
                        .stateMachine(machine)
                        .step()
                        .expectStates(NEW)
                        .expectStateChanged(0)
                        .and()
                        .step()
                        .sendEvent(RESERVE)
                        .expectState(RESERVED)
                        .expectStateChanged(1)
                        .and()
                        .step()
                        .sendEvent(RESERVE_DECLINE)
                        .expectState(CANCEL_RESERVED)
                        .expectStateChanged(1)
                        .and()
                        .build();
        plan.test();
    }

    @Test
    public void testWhenPurchaseComplete() throws Exception {
        StateMachine<PurchaseState, PurchaseEvent> machine = factory.getStateMachine();
        StateMachineTestPlan<PurchaseState, PurchaseEvent> plan =
                StateMachineTestPlanBuilder.<PurchaseState, PurchaseEvent>builder()
                        .defaultAwaitTime(2)
                        .stateMachine(machine)
                        .step()
                        .expectStates(NEW)
                        .expectStateChanged(0)
                        .and()
                        .step()
                        .sendEvent(RESERVE)
                        .expectState(RESERVED)
                        .expectStateChanged(1)
                        .and()
                        .step()
                        .sendEvent(BUY)
                        .expectState(PURCHASE_COMPLETE)
                        .expectStateChanged(1)
                        .and()
                        .build();
        plan.test();
    }

P.S

Нам машина зашла, работает на продуктиве, пока что никаких проблем мы не встретили, в будущем грядет фича, в которой мы сможем использовать подавляющее большинство компонентов текущей машины, при реализации новой(Guard-ы и некоторые Action-ы подходят просто идеально)

Ссылки

Дока ^[5]
Исходники ^[6]