How to change work flow?

Question

For example, the system processes a customer order by check identification -> validate order context -> make order. But the system administrator can change the flow at run time, administrator may skip the “validate order context”.

My question is if the system is processing concurrent order requests, when the system should apply the flow change?

• a): Apply the change until next new order request.

• b): Apply the change immediately, no matter any request is being processed. It sounds too rigid.

• c): Apply the change until a certain time, for instance, any change will be applied at 00:00:00. I don’t think it’s a good strategy.

What is the best practice for the situation? If I use jBMP framework to control work flow, what strategy can be used in such case? Thanks!

Answer 1

All three of your options are valid. The correct choice will depend on the problem you are solving. Here are some examples:

1. Apply the change starting with the next new order. This is a good option if you want to phase in a new work flow. You might describe this as "finish the current work with the current work flow, but all new work will use the new workflow".
2. Apply the change immediately. This is a good option if it is more important that the currect workflow (by that, I mean the new workflow) be used for all work (both current and new). One example of this might be "We removed an unnecessary step from the workflow."
3. Apply the change starting at a certin time. This is a good option in situations that can described like this: "today we are using the old workflow, but tomorrow we begin using the new workflow".

Answer 2

Your first option to apply with the next workflow (i.e. order) is the safest from a concurrency point of view. This is what I'd do because you don't interfere with stateful objects and it is very clear then to an observer what's occurred.

The second option requires locking existing workflows to ensure none are in the validate order context state. And, if any are, writing an algorithm to resolve moving it out of that state correctly.

Finally, your last option is really just scheduling around the first two. As such it could be incorporated into either and should be driven by business rules (i.e. requirements).