Lan*_*ard 84 business-process-management state-machine task-management workflow-engine
我想知道您的具体问题 - SO读者 - 使用工作流程引擎解决了您使用的库和框架,如果您没有使用自己的库.我还想知道什么时候工作流引擎不是最佳选择以及是否/如何选择更简单的东西,比如使用状态机的TaskList/WorkList/Task-Management类型应用程序.
问题:
我正在寻找第一手经验.
我检查过的一些资源:
小智 59
我也有偏见,因为我是StonePath的主要作者.
我为美国国务院,日内瓦人道主义排雷中心,几家财富500强客户以及最近的华盛顿特区公立学校系统开发了工作流程应用程序.每当我看到一个试图成为业务流程的主要参考的"工作流引擎"时,我就看到一个组织正在努力解决这个问题.这可能是因为这些解决方案一直是供应商/产品驱动的,然后最终成为一个"顾问"的战术团队不断为应用程序提供服务......但正因为如此,当我听到这个时,我倾向于做出消极反应基于流程的工具的好处,承诺"将工作流程定义集中在一个地方并使其可重复".
也就是说,我非常喜欢Ruote - 我已经关注了那个项目一段时间了,如果我需要那种解决方案,它将成为我愿意尝试的下一个工具.StonePath与ruote有着截然不同的目的--Ruote一般对Ruby很有用,StonePath针对Rails,这是用Ruby编写的Web框架.Ruote是关于长期业务流程及其相关定义的,StonePath是关于管理基于状态的工作流和任务.坦率地说,我认为与外界观察的区别可能是微妙的 - 很多时候同样的业务流程可以用任何一种方式表示 - 基于状态和任务的模型往往会映射到我的心理模型.
让我来描述一个基于状态的工作流程的亮点.简而言之,想象一下围绕处理抵押贷款或护照更新等事宜的工作流程.随着文件"绕办公室"移动,它从一个州到另一个州旅行.想象一下,如果你对文件负责,你的老板每隔几个小时就会要求你进行一次状态更新,并想要一个简短的回答...你会说"这是在数据输入中"......"我们正在检查申请人的凭证现在"......"我们正在等待质量审查"......"我们完成了"...等等.这些是基于状态的工作流程中的状态.我们从状态移动通过转变到状态 - 如"批准","应用",回扣",'拒绝’,等等,这些往往是行为动词像这样的事情进行建模软件所有的时间作为状态机. .
基于状态/任务的工作流的下一部分是创建任务.任务是一个工作单元,通常具有截止日期和处理指令,将工作项(例如贷款申请或护照续签)连接到"框内"的用户.任务可以相互或sequentialy并行发生,我们可以自动创建任务时,我们进入状态,手动创建任务的人意识到工作需要完成,而且需要的任务完成之前,我们可以移动到一个新的状态.所有这些行为都是可选的,也是工作流定义的一部分.
兔子洞可以比这更深入,我写了一篇关于PragPub问题的文章,实用程序员杂志.查看上面的reo链接,了解该文章的更新PDF.
在过去几个月与StonePath合作时,我发现基于状态的模型很好地映射到了宁静的Web架构 - 特别是,任务和状态转换很好地映射为嵌套资源.期待未来有关此主题的文章.
jme*_*aux 30
我有偏见,我是ruote的作者之一.
变量1)状态机附加到资源(文档,订单,发票,书籍,家具).
变量2)状态机附加到名为任务的虚拟资源
变体3)工作流引擎解释工作流定义
现在您的问题被标记为"BPM",我们可以将其扩展为"业务流程管理".每种变体中都会出现这种管理方式？
在变体1中,业务流程(或工作流)分散在应用程序中.附加到资源的状态机强制执行工作流的某些方面,但仅强制执行与资源相关的方面.在同一业务流程之后,可能有其他资源拥有自己的状态机.
在变体2中,工作流可以集中在任务资源周围,并由围绕该资源的状态机表示.
在变体3中,通过解释称为工作流定义(或业务流程定义)的资源来制定工作流.
业务流程发生变化时会发生什么？是否值得拥有一个工作流引擎,其中业务流程是可管理的资源？
大多数状态机库都有1组状态+转换.工作流引擎(大多数是工作流定义解释器)允许多个不同的工作流一起运行.
改变工作流程的成本是多少？
变体不是互斥的.我已经看到很多例子,其中工作流引擎改变了多个资源的状态,其中一些资源由状态机保护.
我还使用变量3 + 2进行人工任务:工作流引擎,在运行流程实例的某些时刻,将任务(工作项)交给人参与者(创建资源任务并将其置于"准备好"状态) .
您可以单独使用变体2(任务管理器变体).
我们还可以提到变体0),其中没有状态机,没有工作流引擎,并且业务流程在应用程序中分散和/或硬编码.
你可以提出很多问题,但是如果你没有花时间阅读答案而没有花时间去尝试和试验,你就不会走得太远,永远不会获得任何使用时的天赋.这个或那个工具.
我是开源临时工作流引擎的作者之一，我们最初是在 Uber 开发的 Cadence。Temporal 与大多数现有工作流引擎之间的区别在于，它以开发人员为中心，并且非常灵活和可扩展（每秒数万个更新和多达数十亿个开放工作流）。工作流被编写为面向对象的程序，并且引擎确保在主机发生故障时完全保留工作流对象的状态（包括线程堆栈和局部变量）。
您使用工作流引擎解决了哪些问题？
时间几乎可用于任何超越单个请求回复的后端应用程序。用法示例有：
和许多其他人
另一组用例基于移植现有工作流引擎以在 Temporal 上运行。实际上，任何现有的引擎工作流规范语言都可以移植到 Temporal 上运行。这样，单个后端服务就可以为多个特定于域的工作流系统提供支持。
您使用了哪些库/框架？
Temporal 是一个用 Go 编写的自包含服务，带有Go、Java、Typescript、Python、.NET和PHP客户端 SDK。唯一的外部依赖是存储。支持 Cassandra、MySQL 和 PostgreSQL。Elasticsearch 可用于高级索引。
Temporal 还支持异步跨区域（使用 AWS 术语）复制。
什么时候一个更简单的状态机/任务管理系统就足够了？
开源 Temporal 服务可以自行托管，也可以使用 temporal.io 云产品。因此，构建任何自定义状态机/任务管理的开销始终高于使用 Temporal。需要在公司外部设置其服务和存储。如果您已经拥有 SQL 数据库，则通过 docker 映像部署服务非常简单。docker 还用于在个人计算机或笔记本电脑上运行本地临时服务以进行开发。