1、基于数据的包容网关
想让我们的过程更加灵活:当我们饿的时候，我们想要吃东西
- 只有一个沙拉,
- 沙拉和一些意大利面或牛排，
- 或者只是意大利面或牛排。
使用到目前为止学到的符号，我们可以使用图1.1所示的情况建模。
图1.1:组合餐的各种选择。
如果您想要更紧凑的表示，可以使用基于数据的包容性网关(或简称gateway)。(参见图1.2)使用或网关来描述处理，可以沿着一个、多个或者所有传出路径的情况进行，或者网关可以防止图变得过于复杂。
图1.2：网关支持复杂路径变量的紧凑表示
也可以组合路径:取决于我们是只吃沙拉还是吃一些牛排、意大利面，或者是沙拉和牛排、意大利面，我们必须等待一个令牌到达(合并)或两个令牌(同步)，然后我们才可以吃。但是，请注意它与图1.1之间的区别。在没有or gateway的版本中，我们本可以决定不准备任何东西(既不是沙拉也不是牛排和意大利面)，但我们在做出这个决定后吃了东西。or gateway排除了这种荒谬。我们必须决定至少是沙拉或牛排和意大利面，否则令牌会卡在入口。严格地说，bpmn规范确定在这种情况下会发生运行时错误，这对于技术流程实现很重要。
实际上，处理网关并不像这些示例所暗示的那样简单。很容易理解，进程依赖于等待另一个令牌到达or合并。对于跨越多个页面的复杂图表，跟踪同步规则可能比较困难。仅仅记住“或者”拆分时的条件并不是一个解决方案。
图1.3:第二个网关需要等待多长时间?
考虑图1.3:or合并是否需要同步取决于or分割是否通过一个或多个路径运行。场景:第一个令牌在30天后到达or合并。因为答案2也应用于前一个或分割，另一个令牌正在进行中，它将在task 2中再停留15天。此任务完成后，xor分割时做出的决策可能会导致第二个令牌通过answer 1路径路由，并被end事件使用。同步或合并时第一个令牌发生了什么?or网关必须注册第二个令牌已经消失，并且必须转发第一个令牌。
这可能在三种情况下导致问题:
- 您在流程手册的第10页遇到了or merge，您必须翻看前面的9页，以了解哪些条件需要哪些等待时间。
- 您在一个组织中实现这样一个过程，该组织让一个人负责任务3，但不允许这个人对过程进行控制。
- 工作流引擎运行流程并控制同步行为。
实现这样的检查是昂贵的，而且肯定会失败。在某些情况下，这是不可能的。
使用or网关有几个原因——要小心。
问题:我们可以按照图1.4所示的流程建模吗?
图1.4:非常紧凑的版本。
回答:当然，这使模型更紧凑，但它改变了意义。该过程模型产生以下结果:
- 我们只吃意大利面。
- 我们只吃牛排。
- 我们只吃沙拉。
- 我们吃意大利面和沙拉。
- 我们吃牛排和沙拉。
- 我们吃意大利面和牛排。
- 我们吃意大利面、牛排和沙拉。
最后两种结果不是我们想要的!
本文会持续更新，欢迎关注，技术支持：盘古BPM