什么是工作流程系统？
如何将工作流系统与自动执行某些工作的普通应用程序区分开来？ 系统是否必须具有任何特定功能才能被归类为工作流系统？
How can I differentiate a Workflow system from a normal application that automates some work? Are there any specific feature a system must have to be categorized as a workflow system?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
工作流系统管理具有关联状态的对象（通常是文档的逻辑或实际电子替代品）。 系统中对象的状态是状态机（或Petri 网）。
状态转换将对象从一种状态移动到另一种状态。 转换可以由人、自动化事件、计时器、日历等触发。通常转换表示现实世界中的过程中的步骤。
这非常抽象，所以考虑一个例子：错误跟踪软件。 错误报告可能一开始未经验证，因此位于 QA 测试人员的队列中。 QA 测试人员将验证报告并确保步骤清晰，对报告的严重性等进行评分，并将其分配给开发人员或开发小组。 然后，开发人员将最终修复或决定不修复该错误，然后将其发送回 QA 进行验证。 如果对错误存在争议，它可能会进入管理堆栈中冒泡的状态。
上述内容的一个简单实现是对与每个对象关联的状态使用枚举，并使每个人的收件箱成为对具有特定枚举值状态的对象的查询。
这就是它的要点，但事情可能会变得更加复杂，例如拆分新对象、对非人类事件（例如计时、内部或外部（即第三方）服务等）做出反应。
Workflow systems manage objects (often logically or actual electronic replacements for documents) that have an associated state. The state of an object in the system is node in a state machine (or a Petri net).
State transitions move an object from one state to another. The transitions can be triggered by people, automated events, timers, calendars, etc. Usually the transitions represent steps in a process in the real world.
That's pretty abstract, so consider an example: bug tracking software. A bug report probably starts out unvalidated, and as such is in a QA tester's queue. The QA tester will validate the report and make sure the steps are clear, grade the report for severity etc., and assign it to a developer or developer group. It is then in the developer's queue, who will ultimately fix or decide not to fix the bug, which will send it back to QA for validation. If there's a dispute over the bug, it might go into a state in which it bubbles up the management stack.
A trivial implementation of the above is to use an enumeration for the state associated with every object, and make everybody's inbox be a query for objects with a state of a particular enumeration value.
That's the gist of it, but things can get more complex, such as splitting off new objects, reacting to non-human events such as timing, internal or external (i.e. third-party) services, etc.
工作流管理系统推动用户完成一个跨越系统内多个功能的流程，并且工作流程中可能有多个参与者。 工作流引擎了解流程的状态，并将其存储在自己的存储中，该存储可能是也可能不是主应用程序数据库的一部分。
可以使用 状态机, petri 网 或各种其他结构，包括普通的旧脚本语言。 独立的编排系统可用于管理跨多个应用程序的工作流程。 许多（但不是全部）支持 BPEL（业务流程执行语言） 作为标准描述语言工作流程。 如果您的应用程序设置为面向服务的架构，工作流系统可以控制应用程序功能来执行此操作。 工作流引擎的另一个功能是，在维护时应该可以中止工作流并撤消任何状态更改。数据库一致性。
www.workflowpatterns.com 拥有有关工作流系统的文档集合以及模式库。
工作流程系统的应用程序示例：
保险索赔管理。 本质上是他们所有人的祖父。 通常，该流程将制定规则，涵盖谁可以授权多少金额、谁可以处理不同类别业务的索赔、需要提供哪些文件并链接以提供审计跟踪、发放和跟踪付款以及授权损失调整工作。 典型的索赔工作流程将跟踪索赔，从通知到准备金和付款授权，一直到发放付款，以及安排损失调整工作（可能通过第三方）的辅助流程，持有付款权，直到完成并发放和支付损失调整费用。 实际上，这些流程可能会变得相当复杂。
复杂产品（例如计算机系统）的订购、报价和配置管理。
一个不寻常的例子是一家制药制造商开发的系统，用于跟踪新药品的审批流程。 它还包含一个专家系统，其中编码了监管框架，可以选择一条穿过监管圈的最短路径。 这将他们的平均研发生命周期时间从 9 年缩短到 5.5 年。
A workflow management system pushes users through a process that hops across more than one function within a system and potentially more than one participant in the workflow. The workflow engine knows about the state of the process, and stashes this in its own storage, which may or may not be a part of the main application database.
Workflows can be modelled using state machines, petri nets or various other constructs, including plain old scripting languages. An independent orchestration system can be used to manage workflows across multiple applications. Many (but not all) support BPEL (Business Process Execution Language) as a standard description language for workflows. If your applications are set up as a service-oriented architecture the workflow system can control the application functionality to do this. The other feature of a workflow engine is that it should be possible to abort the workflow and undo any state changes while maintaining database consistency.
www.workflowpatterns.com has a collection of documents about workflow systems, along with a library of patterns.
Examples of applications for workflow systems:
Insurance Claims Administration. Essentially the grand-daddy of them all. Typically this process will have rules covering who can authorise how much, who can process claims on different classes of business, what documents need to be present and linked to provide an audit trail, issuing and tracking the issue of payments and authorising loss-adjustment work. A typical claims workflow would track a claim from notification to authorisation of reserves and payments, through to issuing the payment, with side-processes for arranging loss-adjustment work (possibly through third parties), holding payment authority until this is finished and issuing and paying loss-adjusting expenses. In practice, these processes can get quite complicated.
Ordering, quoting and configuration management of a complex product such as a computer system.
One unusual example was a system developed by a pharmaceutical manufacturer that tracked the approval process for a new pharmaceutical product. This also incorporated an expert system that had the regulatory framework coded in it and could pick a shortest path through the regulatory hoops. This dropped their average R&D life-cycle time to market from 9 years to 5.5 years.
如果引导用户完成业务流程而不需要参考该业务流程的任何外部文档，我会将该应用程序视为工作流系统。
扩展巴里的错误跟踪示例，我会说您的错误跟踪应用程序是一个工作流程应用程序，例如，如果有一个名为“关闭”的按钮，按下该按钮会将错误转换为关闭状态，也许允许用户输入结束评论，记录时间戳和用户名，然后发送通知电子邮件。
如果用户必须从下拉列表中选择新状态，然后自己发送通知电子邮件，那么它就不是工作流系统。
I would consider the application a workflow system if the user is guided through the business process without to the need to refer to any external documentation of that business process.
Expanding on Barry's bug tracking example I would say your bug tracking application is a workflow application if for example there is a button called "Close" that when pressed transitions the bug into a closed state, maybe allows the user to enter a closing comment, records the timestamp and user name and then sends an notification e-mail.
It is not a workflow system if the user has to pick the new state from a drop down and then send a notification e-mail himself.
我不认为有一个精确的定义。 这里有一些宽松的标准：
I don't thing there is a precise definition. Here are some loose criteria:
什么是工作流程？
在我看来，软件方面有两种类型的工作流程。 静态（或内置）工作流程和动态（可编程）工作流程。 许多文档管理、错误跟踪甚至博客软件都具有使用简单状态转换的内置工作流程。
当人们说“工作流程”时，我认为他们通常指的是可以将业务逻辑编程到某些现有软件中的流程，例如如果库存缺胡萝卜，则自动调用 sysco。
有关工作流功能的实际示例，请参阅 Microsoft Dynamics CRM 。
What is workflow?
In my opinion, there are two types of workflow in terms of software. Static (or built-in) workflow and dynamic (programmable) workflow. Many document management, bug tracking, or even blog software have built-in workflow using simple state transition.
When people say "workflow," I think they generally mean the ones that you can program business logics into some existing software, like if the inventory is short on carrots, call sysco automatically.
For a real-life example of workflow feature, see Microsoft Dynamics CRM.