在实践中介绍CMMN：第四部分

在实践中介绍CMMN：第四部分

我们一直在通过一个示例CMMN模型进行跟踪，以此作为介绍使用CMMN描述案例管理自动化的一些方法的方法。在上一篇文章中，我们谈到了激活“处理索赔”的第三阶段。在这篇文章中，我们将研究带有条件的条目哨兵以及如何使用自动完成功能。

现在，通知任务决策者的任务一旦处于活动状态就将变为活动状态，这对您来说就不足为奇了，因为它没有入口哨兵。您还会看到的其他内容取决于您选择的操作：接受还是拒绝。

处理任务“支付索赔”确实具有输入哨兵。该哨兵没有关联的事件，因此每次案件状态更新时都会对其进行评估-例如，通过修改案件变量值。如果选择“接受声明”操作并查看UI中的当前任务，您将看到它必须已触发，因为链接过程中有一个活动任务。

发生了什么事呢？如果在模型中选择条目哨兵，您将看到该哨兵触发流程任务所需的条件表达式。CMMN标准中没有表达式的语法定义，与BPMN几乎相同。Flowable在CMMN和BPMN中使用相同的表达语言和评估。我们在示例中使用的表达式是：

${vars:equals(claimAccepted, true)}

这将测试ClaimAccepted变量是否等于true，如果变量不存在则失败。如果我们知道变量始终可用true或false值，则可以使用$ {claimAccepted}。

这个变量在哪里设置？当时我们没有考虑这一点，但是在上一阶段选择了Claim Claim接受的里程碑。在其属性中，您将看到Create Milestone变量设置为ClaimAccepted的值。这意味着只要里程碑被激活，就将创建该变量并将其设置为true。对于“索赔被拒绝”里程碑定义了一个不同的变量。里程碑的这种用法对于指示案件进一步发展时已经满足的案件或阶段中的某个点非常有用。

进入标准是根据迄今收集的信息启动不同过程的有效方法的一个示例：一个阶段可以具有一组过程任务，所有任务均具有不同的进入条件，这些进入条件定义了这些过程何时适合自动启动或提供给客户。用户可以根据需要手动启动。我们将其与机器学习结合使用，作为拥有智能哨兵的一种方法–哨兵条件会呼叫“ AI”以查看在给定情况下是否应触发。这样，某些案例行为可能会坐在那里，等待AI正在监视触发的任何案例数据发生变化。嗯，这就是市场宣传册所说的，再加上一个白色的人形机器人的照片！

完成案例的其余任务，您将看到案例本身已经完成。为此，需要在模型中提供一些帮助。因为流程任务具有输入条件，所以如果满足拒绝里程碑，则该条件最初将失败；但是，阶段不知道此变量是否可以在将来的某个时刻更改为true，因此它处于等待状态。为了阻止这种潜在的未来，我们可以设置自动完成处理任务上的属性。这意味着即使该任务已启用或可用，也可以忽略该任务并自动完成该阶段（您也可以根据需要在CMMN中标记元素，这意味着当该元素尚未终止或无法终止时，父阶段也无法自动完成完成）。该阶段在底部有一个黑色矩形，以直观地表明它将自动完成。

完成最后阶段后，除非我们将总体案例计划设置为自动完成，否则案例本身仍然无法完成。这是因为所有阶段之外的人工任务和用户事件侦听器将以与最后阶段相同的方式阻止完成。

即使我们已经完成了该案例，我们也将在下一篇文章的阶段之外再次回顾这两个项目，介绍重复的任务。