【问题标题】:BPMN Combining Collaboration Diagrams or using Call ActivityBPMN 结合协作图或使用呼叫活动
【发布时间】:2016-07-25 11:22:26
【问题描述】:

假设我有一个协作图,它模拟了一个名为 CheckMessage 的流程,该流程非常复杂并且跨越了几个通道和池。现在我想为另一个过程建模,例如CreateMessage 它将利用前面的过程首先检查消息是否不存在或其所有字段是否有效等。

问题是,两个进程都使用相同的泳道和池。对此类交互进行建模的正确方法是什么?我正在考虑将 CheckMessage 建模为 CreateMessage 的子流程,但是子流程不能附加到池或通道 - 如果我理解正确,它们只会保留在调用它们的活动通道内。 Call Activity 可以封装这样的行为(跨池和通道)吗?或者我可以以某种方式引用整个 CheckMessage 图吗?

提前致谢。

【问题讨论】:

    标签: enterprise-architect bpmn


    【解决方案1】:

    我可以想到以下方法:

    1. 使用图表参考:当您想轻松切换到更复杂的部分时,经常使用此功能。缺点是,与 SD 中的片段不同,您无法真正连接流入和流出引用图表的流。
    2. 重复部分流程:在这里,您只需从复杂流程中挑选那些应该与其他流程交互的操作。您可以通过在它们周围设置边界并如上所述添加图表参考来突出显示这一点。
    3. 呼叫活动:这是另一种有效的方式。在这里,您有一个活动,您将其实例化为操作。这里的好处是您可以为输入和输出参数添加引脚。

    我想没有灵丹妙药,您必须在每种情况下选择合适的。

    编辑关于#3,它看起来像这样:

    (这是一个例子,不要在实践中使用) 右侧的 Action 是 Activity 的实例,您可以通过 Ctrl-L(显示父级)看到。

    【讨论】:

    • 感谢您的回答,但是我不确定是否可以选择选项 1。因为引用的 Digram 必须提供输出(至少以消息流的形式)和选项2,我真的不需要图表的一部分,更需要一个整体。我最安全的选择是调用活动,但根据定义,调用活动似乎可以引入新的池和通道,但我不确定它是否也可以使用父活动的池或通道。不知何故,我认为这种行为会违反最佳实践,因为单个池中的所有任务都不会通过序列流连接。
    • 为什么呼叫活动应该引入新的池/通道?它本身就是一个元素。
    • "全局子进程与其父进程的连接远没有那么紧密,它们可以拥有自己的池和通道。" camunda.org/bpmn/reference/#activities-call-activity
    • “可以拥有”而不是“必须拥有”。
    • 我的意思是对我来说重要的是“他们自己的游泳池和车道”部分。正如我在问题中所述,充当 CheckMessage 进程的调用活动希望使用与父进程 (CreateMessage) 相同的池和通道。这就是让我怀疑的原因,因为我不确定它是否合法。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多