Endless state workflow, performance problem, Very common problem in real system

We use state WF to handle our order processing. Usually an order has 5 states:

(1)Script (2)Approved (3)shipping (4)Closed (5)Canceled

The following actions move the state transforming between the above states.

Approve (1)a(2); undo approve (2)a(1);Cancel (1),(2)a(5); close (2),(3)aclosed; undo close (4)a(3)

Let’s have a look at action “undo close”. It exists in a real world system. Because user some time still need undo-close an closed order to ship again. (Maybe because he just regret).

My question is: which one is completed state of this workflow (4) Closed or (5) Canceled It seems there are no completed state of this workflow. If so ,when can I delete the persistence state

If I set closed-state(4) as completed state, we cannot handle undo close action.

If I add canceled(5) as complete state, then most instance will be accumulated in instancestate table(suppose I use Sql-Server persistence services). There will be a performance problem.

I think this is a very common problem in a real system How did you deal with it

Note: We have hundred thousands of various bills in our system.




Answer this question

Endless state workflow, performance problem, Very common problem in real system

  • petersoftware

    We have a similar problem - an extended (8 years) period where things can still happen to the workflow.

    The approach we're taking at the moment is to terminate the workflow 'early', and if any of these edge-case events occur, 'resurrect' a workflow instance (create new instance + use SetState()) and use that for further processing.

    Maurice is right that the alternative is to handle this as as second workflow, but in our case once reactivated the states might regress substantially back into the original process, so it really has to be one big flow.

    What's important to realize here is that using SetState() isn't entirely without it's side effects: the state initialization handler for the new state, and the state termination handler for the current state both still fire, so you have to be careful about what you put in them (especially for the initial state, 'cause thats where you'd be in this scenario). It's only the activies on defined state transition paths (EventDrivenActivity) that won't fire (because that event's not been received). Just a design issue that needs some attention in these scenarios.

    Resurrection like this is also one way (the sledgehammer approach) of achieving migration between one workflow version and another - which is the subject of your other post.

  • Kweri

    Hi James,

    If you are using state workflows that is possible using the SetStateQueue and the SetStateEventArgs indicating the state. An alternative would be to use a parameter to have the workflow figure this out itself. Either way you will need to set all instance data required.

    That said it would not be my first choice. I would be more inclined to create a new workflow for an item returned and start that in turn. One of its actions might be to start a new copy of the original workflow with a parameter to indicate that this is a replacement or something like that. This way you would keep the workflow of a normal item sale and the sale of a defective, or whatever the reason for the return is, item separate. And I hope the normal flow is that items are not returned :-)

    Maurice


  • yabansu

    Thanks for your answer.

    It is pretty well to deal mis-action. But some time customer may return the product a year later, and we still need find the order and set the state. Can we just create an other new WF instance and directly assign its current state to shipping(3) without trigger other action



  • babucherayath

    I would add an extra Final state.

    The basic rationale is that there is a given time the user cab unclose an order. For example a week later is possible but a year later is not. So in the Closed and Canceled state I would add a DelayActivity that wait for a specific period, lets say a week, and if the order state is still unchanged it finalizes the order and terminate the workflow.

    Maurice

  • DrDeath

    Thanks all for your helpful reply.
    As I think a WF instance should only persistence data changed by instance, never persistence definition data (defaultly at least ) . So this will be tolerant to load different version of workflow.  please see my other post here



  • Endless state workflow, performance problem, Very common problem in real system