如何将工作流系统与自动化某些工作的普通应用程序区分开来?系统是否有任何特定功能必须被归类为工作流系统?
5 回答
工作流系统管理具有关联状态的对象(通常是逻辑上或实际的文档电子替代品)。系统中对象的状态是状态机(或Petri 网)中的节点。
状态转换将对象从一种状态移动到另一种状态。转换可以由人、自动事件、计时器、日历等触发。通常,转换代表现实世界中流程中的步骤。
这很抽象,所以考虑一个例子:错误跟踪软件。错误报告可能在开始时未经验证,因此在 QA 测试人员的队列中。QA 测试人员将验证报告并确保步骤清晰,对报告进行严重程度等分级,并将其分配给开发人员或开发人员组。然后在开发人员的队列中,最终将修复或决定不修复错误,这会将其发送回 QA 进行验证。如果对 bug 有争议,它可能会进入管理堆栈冒泡的状态。
上面的一个简单实现是对与每个对象关联的状态使用枚举,并使每个人的收件箱成为对具有特定枚举值状态的对象的查询。
这就是它的要点,但事情可能会变得更复杂,例如拆分新对象、对非人类事件(例如时间、内部或外部(即第三方)服务等)做出反应。
工作流管理系统推动用户通过一个过程,该过程跨越系统内的多个功能,并且可能跨越工作流中的多个参与者。工作流引擎知道流程的状态,并将其存储在自己的存储中,该存储可能是也可能不是主应用程序数据库的一部分。
可以使用状态机、Petri 网或各种其他结构(包括普通的旧脚本语言)对工作流进行建模。独立的编排系统可用于管理跨多个应用程序的工作流。许多(但不是全部)支持BPEL(业务流程执行语言)作为工作流的标准描述语言。如果您的应用程序设置为面向服务的体系结构,则工作流系统可以控制应用程序功能来执行此操作。工作流引擎的另一个特性是它应该可以中止工作流并撤消任何状态更改,同时保持数据库的一致性。
www.workflowpatterns.com拥有一系列关于工作流系统的文档,以及一个模式库。
工作流系统的应用示例:
保险索赔管理。基本上是他们所有人的祖父。通常,此流程将包含规则,包括谁可以授权多少,谁可以处理不同业务类别的索赔,需要提供哪些文件并链接以提供审计跟踪,签发和跟踪付款问题以及授权损失调整工作. 典型的索赔工作流程将跟踪索赔,从通知到准备金和付款授权,再到发放付款,以及安排损失调整工作(可能通过第三方)的辅助流程,持有付款权限直到完成并发放和发放支付理赔费用。在实践中,这些过程会变得相当复杂。
复杂产品(如计算机系统)的订购、报价和配置管理。
一个不寻常的例子是由制药商开发的一个系统,用于跟踪新药品的批准过程。这还包含了一个专家系统,该系统中编码了监管框架,并且可以选择一条通过监管圈的最短路径。这将他们的平均研发生命周期上市时间从 9 年缩短到 5.5 年。
如果用户被引导完成业务流程,而无需参考该业务流程的任何外部文档,我会将应用程序视为工作流系统。
扩展 Barry 的错误跟踪示例我会说您的错误跟踪应用程序是一个工作流应用程序,例如,如果有一个名为“关闭”的按钮,按下该按钮会将错误转换为关闭状态,可能允许用户输入关闭评论,记录时间戳和用户名,然后发送通知电子邮件。
如果用户必须从下拉列表中选择新状态,然后自己发送通知电子邮件,则它不是工作流系统。
我不认为有一个精确的定义。以下是一些宽松的标准:
- 协调不止一个人的工作(但不是群件),
- 在复杂的组织环境中,
- 通常作为托管业务流程的一部分(如在 BPM 中)。
业务流程的全部或部分自动化,在此期间,文档、信息或任务根据一组程序规则从一个参与者*传递给另一个参与者以采取行动。
*participant = resource (human or machine)
在我看来,就软件而言,有两种类型的工作流程。静态(或内置)工作流程和动态(可编程)工作流程。许多文档管理、错误跟踪,甚至博客软件都有使用简单状态转换的内置工作流程。
当人们说“工作流”时,我认为他们通常是指您可以将业务逻辑编程到一些现有软件中的那些,例如如果库存缺少胡萝卜,则自动调用 sysco。
有关工作流功能的真实示例,请参阅Microsoft Dynamics CRM。