协作

协作（Collaboration）表示业务流程中多个参与者之间的交互。每个参与者都使用唯一的 ID 和名称进行定义，并通过 processRef 属性与特定的流程定义相关联。

图形表示法

协作本身没有独特的可视化表示。但是，图中至少存在一个 泳池 则表示它是协作的一部分。

XML 表示

在 XML 中，协作由包含 <participant> 子元素的 <collaboration> 元素定义。每个 <participant> 都通过 processRef 属性与特定流程相关联，该属性需设置为流程定义的 ID。

<definitions . . .

  <collaboration id="Collaboration_1px6goz" name="Collaboration">
    <participant id="Participant_1" name="Participant One" processRef="Process_01" />
    <participant id="Participant_2" name="Participant Two" processRef="Process_02" />
  </collaboration>

此外，协作可能有 isClosed 属性，但 Jmix BPM 会忽略该属性。

属性

以下是 协作 的属性：

collaboration properties
ID

协作的标识符。

Name

name 属性描述协作的作用。其最大长度为 255 个字符。但是该名称不在图中显示。

Documentation

可以填写协作的描述。其最大长度为 4000 个字符。

消息流

协作对象通常具有消息流，表示不同泳池之间的通信。 消息流表示参与者之间如何交换信息或任务，从而增强对流程间交互的理解。

消息流在 BPMN 中显示为虚线，用于说明两个准备发送和接收消息的参与者（泳池）之间的信息流。并不能表示交换消息的特定顺序。

消息流可以连接：

  • 不同泳池的两个节点

  • 一个泳池的节点和另一个泳池

  • 两个泳池

但是，消息流无法链接同一泳池中的节点。

行为

Flowable 本身并不处理消息的实际接收，因为这依赖于应用程序的环境。 开发人员必须实现接收消息的逻辑，比如可能包括连接到 JMS 或 REST API 等外部服务。

文档目的

虽然消息流对于流程之间交互的可视化非常有用，但业务流程在执行期间通常不会考虑消息流。其主要作用是作为文档工具，以阐明不同实体在 BPMN 模型中如何通信。

示例

协作可以用在不同场景中。第一种，使用协作可以在单一图中放置主流程和子流程：

collaboration example 1

消息流只是说明了主流程的不同点调用了同一个子流程。

这种方法比将主流程和子流程存在单独的 XML 文件中更方便。

第二个情况是，可以对流程间通信进行建模：

collaboration example 2

在这里，流程 One 发送消息启动流程 Two，然后等待，直到收到来自流程 Two 的消息。或者定时器事件触发，流程 One 的信号启动流程 Three。

这里也是，可以在一个图内看到所有协作的流程。