问您如何知道什么时候需要BPM解决方案？

EN

我写了一个工作流引擎，因为我的雇主想要拥有这个以jBPM为模型的IP。现在，您使用这种工具而不是创建您自己的有限状态机的原因是，在不改变持久化和支持工作流过程的边缘情况的情况下适应变化，我将解释这一点。

在不改变持久性的情况下适应变化

通常，或者更好地称之为“朴素”的有限状态机实现具有一组与所管理的数据紧密耦合的数据库表以及它所通过的流程。也许有一种方法可以保持过去的版本，并跟踪谁在这个过程中采取了什么行动。在遇到问题的地方，数据和进程结构会发生变化。然后，这些紧密耦合的表需要修改以反映新结构，并且可能与旧表不向后兼容。

工作流引擎通过两种方式克服了这一挑战，方法是使用序列化来表示数据和流程，以及抽象集成点，特别是安全性。序列化方面意味着数据和进程可以通过系统一起移动。这允许相同类型的数据实例遵循完全不同的进程，直到进程在运行时可以更改，例如添加一个新的状态。所有这些都不需要更改底层存储。

集成点是向流程中注入算法的方法，并与身份验证存储(即必须采取行动的用户)联系在一起。注入算法可能包括是否完成状态的确定，而身份验证存储示例是LDAP。

现在的权衡是很难找到的。例如，由于数据是序列化的，所以通常不可能查询历史信息--除了检索记录、反序列化和使用代码进行分析之外。

边缘情况

工作流工具的另一个方面是嵌入到其设计和功能中的体验，您可能不会考虑滚动自己的工具，并且在需要时可能会后悔。在我看来，这两种情况是定时任务和并行执行路径。

定时任务是在某一持续时间过后为数据指定参与者责任。例如，说一份新闻稿是令状，提交批准，然后不加审查地坐一周。您可能希望您的系统做的是确定该挥之不去的文档，并提请适当的各方注意。

在我的经验(内容管理系统)中，并行执行路径并不常见，但仍然是经常出现的情况。它的思想是，一个给定的数据被发送到两种不同的审查或处理路径，只是在稍后的某个点重新组合。这种类型的问题需要有有用的合并算法和同时表示数据乘的能力。在这个事实之后，将其编织到一个家庭版解决方案中要比看起来复杂得多，特别是如果您想要跟踪历史数据的话。

结论

如果您的系统不可能改变，滚动您自己的可能是一个更容易的解决方案，特别是如果更改可能破坏旧的信息。但是，如果您怀疑您需要这种持久性，或者会遇到这些不常见但棘手的场景，工作流工具提供了更多的灵活性和安全性，您不会随着数据和业务流程的变化而将自己推入一个角落。

BPM酸测试(来自迈克尔·哈维的基本业务流程建模，由O‘’Reilly出版)。

...BPM只适用于具有基本状态或进程感的应用程序，即面向流程的应用程序。一个应用程序通过了BPM酸测试，如果它是合法的面向过程的。例如，旅行社应用程序通过了测试，因为它最好是从行程的状态来理解，并且在任何时候都是根据行程得到的距离来定义的。面向流程的应用程序的其他典型特征包括：

• 长跑-

从开始到结束，这个过程跨越了几个小时、几天、几周、几个月或更长的时间。

• 持久化状态-

由于该进程的生存期很长，因此它的状态将持久化到数据库中，使其比承载它的服务器持续时间更长。

• 暴躁，大部分时间都在睡觉--

该流程大部分时间都处于休眠状态，等待下一个触发事件发生，此时它会醒来并执行一系列活动。

系统或人类通信的

• Orchestration -

这一进程负责管理和协调各种系统或人的行为者之间的沟通。

..。例如，在自动柜员机中，用户可以查询自己的账户余额、提取现金、存款支票和现金，并支付账单--任何流程感都是短暂和不必要的；自动取款机是在线事务处理器，而不是面向进程的应用程序。

也许问几个问题会有帮助。

过程会改变吗？一个较旧版本的流程会继续存在，而新版本的流程会出现吗？应该测量进程(和每一步)的运行时间吗？

是关于业务流程(编排多个资源的状态)还是资源生命周期(仅涉及单个文档/资源的状态)？

抱歉，如果答案不多的话。