假设一个描述活动、网关、开始和结束事件的 BPMN 流程。如下:
每个步骤都由 BPMN 引擎管理。在某一时刻,我们如何判断哪个是进程的状态?活动似乎定义了一些体现为动作的状态(例如评估请求)。我对么 ?
此外,如果我们假设活动代表状态,那么如果我们要通过专门的后续应用程序导航,我们如何获得下一个可能状态的列表?
是否应该以更加面向工作流的方式对流程进行建模以表达这些状态/动作的可能性?我的直觉是事件也可以用来管理状态和可能的相关动作。
由于我不确定您对流程状态的理解到底是什么,因此我将首先尝试对其进行定义。我想您知道令牌概念,请参阅Camunda 论坛中的讨论:
令牌是一个 BPMN 概念,它表示流程实例中的状态。它没有任何变量或任何消息。
您现在可以将流程的状态定义为在给定时间存在多少令牌以及当前在给定活动或事件中有多少令牌的统计信息。
可以从您最喜欢的 BPMN 引擎中提取此统计信息(例如在 Camunda 的 Cockpit 中,可以将其视为彩色的小气泡)。有了这些统计数据,您原则上可以生成对下一个可能状态的预测,即确定在每个活动中可能在下一个时间实例中有多少令牌的场景。
状态在 BPMN 中有不同的含义,它可能意味着: 1 - 流中的令牌在哪里?2 - 流程是否正确运行?3 - 或者,通过表单中的特定变量(字段)。如果您指的是流程中常见的第三种情况,则必须在数据模型中将字段定义为枚举(取决于引擎)并手动或自动更改其在表单中的值。
显然,BPMN 相当抽象的 Petri-Net 式令牌流语义并没有捕捉到业务流程的真实语义。由于学术压力集团,它刚刚被人为地强加给 BPMN。真正有意义的语义必须引用拥有它的业务系统中流程的信息上下文。
当然,作为流程(类型)所有者的业务系统,在流程运行过程中的任何时刻,都处于某种复杂的动态信息状态,其中某些部分构成了流程的上下文,因此可以考虑它的状态。
事实上,流程的(信息)状态本质上是由流程(的事件/活动)使用或影响的对象的所有属性值槽给出的。除了这些“全局变量”,一个进程的状态还包括
查看Imixs-Workflow 项目。它是一个面向事件的工作流引擎,而不是 BPM 引擎中常见的面向任务的设计。
这种工作流引擎中的每个任务都在您的流程模型中定义了一个状态。工作流引擎保持此状态,直到触发事件。事件定义了从一种状态到另一种状态的转换。
您可以在此处找到如何在事件驱动的工作流模型中对不同场景建模的示例。