业务自动化中的数据流

在处理不可执行模型的BPMN中，
，趣玩不用担心流程数据，，它完全被排除在模型之外。。。
。趣玩只是假设流程任务产生或接收的任何数据在下游都可用
。。但在业务自动化中，
，，即可执行的BPMN，，，，情况并非如此。。

流程数据并不普遍
，
，可在任何需要的地方自动获取
，
，
，它在图中显示的流程变量和流程任务之间“流动”。。。事实上，，数据流是使流程可执行的原因
。
。。对于大多数BPMN工具，
，定义数据流需要编程，，，但借助Low-Code，，，，可以通过扩展工具执行流程设计
。。在本文中趣玩来解释它是如何工作的
。
。

首先，，，趣玩需要区分流程变量和任务变量
。。
。。流程变量在BPMN图中显示为数据输入、、、、数据输出和常规数据对象。。数据输入表示进程从外部接收的数据。。。当趣玩将可执行流程部署为云服务时，，，，数据输入是触发流程的API调用的输入参数。。同样，，
，，数据输出是API调用的输出参数，，，，即响应
。。
。数据对象是在运行过程中创建和填充的流程变量。。。

业务自动化中的数据流

通常
，
，任务变量不显示在流程图中，
，，它们是任务的属性，
，，BPMN规范没有指定如何向建模者显示它们。。。图中显示的是数据关联，，，虚线箭头将流程变量与流程任务连接起来。。。从流程变量到任务的数据输入关联意味着该变量和任务输入之间存在映射。
。。。类似地，，从任务到流程变量的数据输出关联意味着任务输出和流程变量之间存在映射。。每个任务的内部逻辑，，比如决策服务或外部云服务，，引用任务变量，，，不引用留程变量
。。。。

任务输入和输出显示在任务配置中的数据映射框表达式中。
。
。任务变量定义取决于任务类型
。。服务任务、、、、决策任务和调用活动由被调用元素定义，，
，，而不是由调用任务定义。。脚本和用户任务，，在流程模型中定义，
，实际上是在数据映射配置中
。
。。

服务任务调用REST服务操作
。。。。BPMN工具中的操作库提供了流程中服务任务可用的服务操作目录
，，，，操作库中的每个条目都指定了服务输入和输出参数等细节
。。
。将Service任务绑定到操作库中的某个条目时，，Service任务输入是该服务的输入参数
，
，，Service任务输出是该服务的输出参数。。。。

决策任务调用BPM平台上的DMN决策服务。
。。
。在DMN模型中
，，，可以快速创建决策服务，，，指定输出决策和服务输入。
。。将决策任务绑定到决策服务时，，，，服务输入将成为决策任务输入
，
，服务输出将成为决策任务输出。。
。。

服务任务、、、决策任务和呼叫活动
，，，
，给出了任务输入和输出，，不能在调用流程中更改。。。调用流程中的流程变量不必与它们连接的任务变量具有相同的名称或数据类型
。。。。所需要的只是可以在它们之间定义映射。。。

对于决策任务，
，
，任务输入和输出已经确定作为决策服务的输入和输出参数。。它看起来像这样：在脚本任务输入映射中
，，建模者在映射部分的第一列中定义任务输入的名称和类型。。。这些任务输入的映射是更复杂的文字表达式。
。。脚本文字表达式引用这些任务输入，，而不是流程变量。。用户任务的工作方式相同，
，
，只是它们不限于单个任务输出
。。

数据流将不可执行的流程变成可执行的流程。。触发API调用填充一个或多个流程数据输入，，，数据从这些输入通过输入映射传递到任务输入。
。。
。结果任务输出映射到其他流程变量（数据对象），
，
，
，依此类推
，，直到API响应从流程数据输出返回。。。在无代码的BPM平台上，，这一切都不需要编程，，，，只是绘制数据关联并使用FEEL填写数据映射表的问题。
。