都是流程的管理，工作流引擎和状态机到底区别在哪里。

Introduction

When companies decide to implement a system that will help them manage business processes, their choice will probably lie between a workflow engine and a state machine. Though the behavior of the two systems seems to be quite similar, they both have a number of distinct features. Accordingly, it is necessary to analyze the pros and cons of both to decide which of the systems suits most company’s needs.

当公司决定实现一个系统来帮助他们管理业务流程时，他们的选择很可能位于工作流引擎和状态机之间。虽然这两个系统的行为看起来很相似，但是它们都有许多不同的特性。因此，有必要分析两者的利弊，以决定哪一个系统适合大多数公司的需要。

In general, the major difference between a workflow engine and a state machine lies in focus. In a workflow engine, transition to the next step occurs when a previous action is completed, whilst a state machine needs an external event that will cause branching to the next activity. In other words, state machine is event driven and workflow engine is not.

一般来说，工作流引擎和状态机的主要区别在于焦点。在工作流引擎中，在完成之前的操作时，就会切换到下一个步骤，而状态机需要一个外部事件，这将导致分支到下一个活动。换句话说，状态机是事件驱动的，而工作流引擎不是。

 

What to Consider When Making a Choice

When trying to figure out which of the two systems to implement, it is necessary to analyze some of their major features.

当试图找出要实现的两个系统中的哪一个时，有必要分析它们的一些主要特性。

 

Flexibility

Workflow engine supports sequential pattern when tasks are executed one after another. The next step in a workflow will not start till the previous is finished. For instance, the document will not be signed by the boss till the lawyer signs it. As a result, workflow engine seems to be rigid and deterministic in its nature. State machine, on the contrary, works asynchronously. Since the steps in the machine are triggered by certain events/actions, they shouldn't necessarily be performed in a strict order. From this point of view state machines are more flexible.

However, the situation changes once your company has new business requirements. Imagine a state machine that has the following three states: submit an application, accept an application and reject an application. At present, we can see three separate states and clear transitions to them. Later on you decide to add some new states, for example, change an application and ask for feedback. In this situation the number of states and transitions between them increases considerably. Moreover, when adding new states, you should understand that you cannot change one without breaking the rest. As a result, instead of simply adding new functionality, you find yourself building a new system from scratch. Therefore, when you understand that your business rules may change over the time (that is practically inevitable process), workflow engine is a better option.

当任务逐个执行时，工作流引擎支持顺序模式。工作流的下一个步骤将在完成之前才开始。例如，该文件将不会由老板签署，直到律师签字。因此，工作流引擎在本质上似乎具有刚性和确定性。相反，状态机的工作是异步的。由于机器中的步骤是由某些事件/动作触发的，所以不应该严格执行它们。从这个角度看，状态机更灵活。

但是，一旦公司有了新的业务需求，情况就会发生变化。假设有以下三个状态的状态机:提交应用程序、接受应用程序和拒绝应用程序。目前，我们可以看到三个独立的国家和明确的过渡。稍后，您决定添加一些新状态，例如，更改应用程序并请求反馈。在这种情况下，它们之间的状态和转换的数目会大大增加。此外，在添加新状态时，您应该了解，您不能在不破坏rest的情况下更改一个状态。结果，您发现自己从头开始构建一个新的系统，而不是简单地添加新功能。因此，当您理解您的业务规则可能在时间上发生变化(这实际上是不可避免的过程)时，工作流引擎是一个更好的选择。

 

Understandability

State machines appear to be easy in usage at first sight. The developer simply needs to review company's processes and draw a diagram on which he should depict a particular number of states and events that will trigger transitions to them. However, the main problem of a state machine is that in practice it suits only businesses with one-dimensional problems. It serves well for projects with several distinct states, but fails when there are more complex systems. A typical CRM system built as a sequence of states might cause many problems. You’ll have to think of numerous status transitions, such as the registration of a new lead, start of the project or cancellation. Moreover, each of these states could be divided into separate ones as well. For example, you might want to define a reason for cancellation or through which channel a new lead was found (an email campaign, cold calling, etc.). When trying to depict each of these states, the system soon becomes unmanageable.

状态机乍一看似乎很容易使用。开发人员只需要回顾公司的流程，并绘制一个图表，其中他应该描述特定数量的状态和事件，这些状态和事件将触发对它们的转换。然而，一个状态机的主要问题是，在实践中它只适合有一维（相对多个维度）问题的业务。它为具有几个不同状态的项目提供了良好的服务，但是当有更复杂的系统时就会失败。一个典型的由状态序列构建的CRM系统可能会导致许多问题。您将不得不考虑许多状态转换，比如注册一个新的领导，启动项目或取消。此外，每个州也可以被划分为独立的州。例如，您可能想要定义一个取消的原因，或者通过哪个通道找到新的线索(邮件活动、冷调用等等)。当试图描述这些状态时，系统很快变得难以管理。

Workflow engines seem to be quite complicated at first, since additional elements should be deployed. However, for larger systems it is the most appropriate solution. When implemented properly, benefits outweigh apparent complexity. Workflow engine seems to be a better model for business process management. It is often used for task management systems, being able to quickly allocate tasks to various executors. Moreover, workflow engines usually have solid documentations. A new developer will be able to understand it without spending hours analyzing endless lines of code.

首先，工作流引擎似乎相当复杂，因为应该部署更多的元素。然而，对于较大的系统，它是最合适的解决方案。当实现适当的时候，好处大于明显的复杂性。工作流引擎似乎是一个更好的业务流程管理模型。它通常用于任务管理系统，能够快速地分配任务给不同的执行者。此外，工作流引擎通常有可靠的文档。一个新的开发人员将能够理解它，而不用花费数小时分析无穷无尽的代码。

 

Readability

Effective collaboration between people inside and outside the company is necessary for businesses development. Therefore, a common platform, used by a company, should be clear for all the members of the staff. Managers should be able to quickly identify at which state a certain action is at any given time.

State machine often fails in terms of readability. It is capable of executing only one state at a time since it is impossible to run two in parallel. So, when you try to introduce events that might happen under certain conditions, you double the number of states. When the number of states becomes too large, readability of state machine tends to zero.

公司内部和外部人员之间有效的协作是企业发展的必要条件。因此，一个公司使用的公共平台应该对所有员工都是透明的。管理人员应该能够快速识别某个特定动作在任何给定时刻的状态。

状态机在可读性方面常常失败。它能够一次只执行一个状态，因为不可能同时运行两个状态。所以，当你试着介绍在某些情况下可能发生的事件时，你会把状态的数量翻倍。当状态数变大时，状态机的可读性趋于零。

 

Predictability

Workflow engines, in comparison to state machines, are predictable in their nature. They use conditions that are always predefined at the beginning. Let's assume that you require document approval from both direct manager and general manager. The document may be signed in any order. If you choose a workflow engine, this process will be predefined. For instance, at first the direct manager signs the document, then the general manager. Accordingly, the general manager will not receive the document till the direct manager signs it. This process cannot be changed.

In a state machine pattern, it is the user who decides whether the direct or the general manager should sign the document first. In this case the decisions are made by people. Since state machines are controlled by external factors, there could be numerous events that will lead to process completion. From this point of view, workflow engine is more beneficial as it guides you throughout the whole process.

与状态机相比，工作流引擎在本质上是可预测的。它们使用在开始时总是预定义的条件。假设你需要得到直接经理和总经理的书面批准。该文件可以以任何顺序签署。如果您选择一个工作流引擎，这个过程将是预定义的。例如，一开始直接管理人员签署文件，然后是总经理。因此，总经理将不会收到文件，直到直接经理签字。这个过程是不能改变的。

在状态机模式中，由用户决定直接或总经理是否应该首先签署文档。在这种情况下，决策是由人做出的。由于状态机是由外部因素控制的，所以可能会有许多事件导致过程的完成。从这个角度看，工作流引擎更有益，因为它指导您整个过程。

 

Conclusion

State machine is a good solution if your system is not very complex. You may implement it if you are capable of drawing all the possible states as well as the events that will cause transitions to them. In general, state machines work well for network protocols or some of the embedded systems.

Workflow engine implementation is a good way of managing business processes. It is the right solution for task allocation, CRM and other complex systems. All in all, its ultimate goal is to improve business processes and company’s efficiency. That is why it perfectly suits for business process automation.

如果您的系统不是很复杂，状态机是一个很好的解决方案。如果您能够绘制所有可能的状态以及将导致转换的事件，您可以实现它。一般来说，状态机在网络协议或某些嵌入式系统中运行良好。

工作流引擎实现是管理业务流程的好方法。它是任务分配、CRM和其他复杂系统的正确解决方案。总之，它的最终目标是改善业务流程和公司的效率。这就是为什么它非常适合业务流程自动化。