Customizing states and Transitions

The default state transitions are implemented in the Litium.Studio.Plugins.ECommerce.StateTransitionPlugin assembly. Source code is available with the release package in "Plugin Source" directory.

Customizing State Transitions Plugin

To change state transitions, implement the interface IStateTransitionBuilder or extend the StateTransitionBuilderBase class in your own class and place assmebly (.dll file) which contain that class into wwwroot\bin folder. More instructions on extending a plugin interface are here.

Do not change order during entry/exit actions or transition conditions

State transitions entry/exit actions should be used to invoke changes external to the order object. The concept is, the state of the order is used to modify the state of an entity or a system external to the order.

You should NOT modify the order object itself, during the entry/exit actions or transition conditions.

The reason is, the order itself is the source data of the actions we perform, and more than one interconnected systems depends on the state of the order, (and therefore its data too). Therefor a order modification at this point will violate the consistency and integrity of the system. If you modify the order, you may get concurrency exceptions during run time in code that may not be related at all to the customization you have done. Also, even if you may not get concurrency exceptions, some other state transition conditions which looks at the order data may fail or may not work properly.

States are immutable

Once a state is added to a state machine, it will be reused in all subsequent calls to that state. Even if you try to add a new instance of the same state again, the instance that was added earlier will be reused, instead of using the one you tried to add later.

Bear in mind this important difference when you add the states. For example, in following code example, the Confirmed state is not added twice, simply the instance added first in transition from Init to Confirmed is re-used when the transition from Confirmed to Processing is added.

            

//Confirmed state
            Sts.Action<OrderCarrier> confirmOrderEntryAction = new Sts.Action<OrderCarrier>(OnOrderConfirmation);
            State<OrderCarrier> confirmedState = new State<OrderCarrier>((short)OrderState.Confirmed, OrderState.Confirmed.ToString(), confirmOrderEntryAction, null);

            //add transition Init to Confirmed
            stateMachine.AddStateTransition(
                new State<OrderCarrier>((short)OrderState.Init, OrderState.Init.ToString()),
                confirmedState,
                new TransitionCondition<OrderCarrier>(CanOrderMoveToConfirmedState),true);

            //add transition Confirmed to Processing
            stateMachine.AddStateTransition(
                new State<OrderCarrier>((short)OrderState.Confirmed, OrderState.Confirmed.ToString()),
                new State<OrderCarrier>((short)OrderState.Processing, OrderState.Processing.ToString()),
                new TransitionCondition<OrderCarrier>(CanOrderMoveToProcessingState),true);

Creating enums for Order and Delivery states

Its a better idea to create enums for order states and delivery states. The code will look cleaner and bug free than using magic text. For the examples under this section following enums will be used.

    /// <summary>
    /// Sample order states.
    /// </summary>
    public enum SmplOrderState
    {
        Init = 0,
        Confirmed = 1,
        Completed = 2,
        Returned = 3,
        Cancelled = 4
    }

    /// <summary>
    /// Sample delivery states.
    /// </summary>
    public enum SmplDeliveryState
    {
        Init = 0,
        Delivered = 1,
        Failed = 2,
        Returned = 3,
        Cancelled = 4
    }