如何改变工作流程?
例如,系统通过检查身份
来处理客户订单-> 验证订单上下文
-> 下订单
。但系统管理员可以在运行时更改流程,管理员可以跳过“验证订单上下文
”。
我的问题是,如果系统正在处理并发订单请求,系统应何时应用流程更改?
a):应用更改直到下一个新订单请求。
b):无论正在处理任何请求,都立即应用更改。听起来太死板了。
c):应用更改直到某个时间,例如,任何更改都将在 00:00:00 应用。我认为这不是一个好的策略。
针对这种情况的最佳做法是什么? 如果我使用jBMP框架来控制工作流程,在这种情况下可以使用什么策略? 谢谢!
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!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您的所有三个选项均有效。正确的选择取决于您要解决的问题。以下是一些示例:
All three of your options are valid. The correct choice will depend on the problem you are solving. Here are some examples:
从并发的角度来看,应用于下一个工作流程(即订单)的第一个选项是最安全的。 这就是我要做的,因为您不会干扰有状态的对象,并且观察者非常清楚发生了什么。
第二个选项需要锁定现有工作流程,以确保没有一个工作流程处于验证订单上下文状态。并且,如果有的话,编写一个算法来解决将其正确移出该状态的问题。
最后,您的最后一个选择实际上只是围绕前两个进行安排。因此,它可以合并到任何一个中,并且应该由业务规则(即需求)驱动。
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).