ixp

latest

false

Communications Mining 用户指南

上次更新日期 2025年10月20日

UiPath™ 自动化框架

备注：

增强型辅助功能 - 活动内容重定位

我们一直在不断努力改善您的体验，并使我们的资源更加方便用户使用。

我们重新整理了开发者指南，并将活动重新定位到新的Communications Mining™ 活动指南。现在，您可以更轻松地访问并改进导航。

我们相信此更改可优化您的体验，并帮助您更有效地找到所需的信息。我们重视您的反馈，并期待着支持您利用我们的平台不断取得成功。

概述

The Communications Mining™ Dispatcher Framework is a UiPath® Studio template that you can use when integrating Communications Mining with RPA implementations. Its objective is to take the comments from a Communications Mining stream and add them one by one, into one or many UiPath Orchestrator unique references queues. You should define one queue for each downstream process needing the data from a stream as input. By default, in the configuration file, we have set up two process queues (for Process A and B), and one generic one, but you can configure as many as you need.

You can get the framework from Studio, under Templates, by searching for Communications Mining Dispatcher.

Important: When creating your queues, select the Enforce unique references option.

The template is based on the Robotic Enterprise Framework (REFramework), covering all the essential best practices in RPA projects, such as flexible configuration through the Config.xlsx file, exception handling, retry mechanisms, and meaningful logging.

Note: Prior to working with the Communications Mining Dispatcher, make sure you consult the official REFramework documentation, if you are not familiar with it.

从 REFramework 项目开始，我们封装了使用来自 Communications Mining 流的数据时需要执行的两个关键操作：获取和推进。提取是从 Communications Mining 流中获取数据的过程，而推进本质上是将注释标记为已读，这样我们下次提取时就不会返回相同的注释。我们将在下一节中更详细地讨论它们。

By default, the framework will stop the fetching and advancing cycle when it passes the end of the stream, that is, when the stream has no more unread comments. However, you can configure the framework to run continuously, even when it reaches the end of the stream. To do so, you can mark the ExitOnEmptyStream setting as False in the Config.xlsx file. This setting allows the framework to cycle infinitely, and whenever new data becomes available in the stream, it will process it instantly, with no need to wait for the when the process of the framework is scheduled to run.

The end goal is to have the comments available in a usable Orchestrator queue, one queue item per comment, containing their corresponding data and predicted labels and general fields. This way, the downstream automations will have access to the predicted information.

The communication is not added to its corresponding queue without passing the validation rules. There are some basic validation rules already defined in the framework - mainly for understanding to which process every item pertains - but you can add your own validation algorithms in the code. Also, as an example, in the Config.xlsx file, we have separate validation settings sheets for each downstream automation process, that is, ProcessAValidations and ProcessBValidations. Since they were configured just as examples for theoretical processes, feel free to add your own sheets and settings.

重要提示：

Make sure you do not have multiple settings with the same name in the Config file, even if they are on different sheets. They will all be added to the same Config dictionary and override each other.

In the file, we offered some examples of naming conventions for the validation settings that might be useful. The logic in the workflow that checks the validation rules follows the same conventions, so be careful when implementing your own, in case you want to change them.

If the validation fails, the information is added to a human-in-the-loop queue, which also requires unique references, for human to validate in Action Center. You can add the name of your human-in-the-loop queue in the Config file.
You are recommended to define a trigger on the human-in-the-loop queue, which starts a new Orchestration Process for each new item, creating a task in Action Center. The task would contain the data retrieved from Communication Mining for the current item, and the human should validate it before sending it into its corresponding downstream automation process queue.

流

在 Communications Mining™ 中成功训练模型后，我们可以创建一个新的流，并为已训练的每个概念配置阈值。流定义了数据集中的注释集合。它支持通过注释实现持久性、有状态的迭代，并提供使用给定模型版本计算的预测标签和通用字段。

备注：

我们建议您按照 Communications Mining 官方文档和 Academy 操作，了解模型训练步骤以及所涉及的所有概念的详细信息。

UiPath™ Studio 与 Communications Mining 的集成包括使用 Communications Mining 流中的每条注释。然后，每个通信预测都可以用于一个或多个下游流程。下图描述了通用的 UiPath 和 Communications Mining 集成：

我们的方法建议，对于 n 个自动化，在 UiPath 中配置 n+1 个流程：n 个 RPA 流程和一个队列馈送程序。引入了单个馈送流程，该流程负责从 Communications Mining 的流中读取结构化通信，并通过 Orchestrator 队列将其分发到相关 RPA 流程。然后，可以标记可能因 Communications Mining 提取而发生的任何异常，以进行手动验证。从队列中获取项目的流程将是标准 UiPath 自动化，这些自动化会从队列项目的数据中读取输入数据。所提供的调度程序框架履行队列馈送程序的角色。

获取-高级循环

要从流中使用注释，我们的框架需要实现“获取和高级循环”，如下所示：

每个流都有一个当前注释：
我们可以从此当前注释开始获取注释。在下图中，我们要提取两个注释：
从流返回的每条注释都将具有sequence_id ：
```
{
   "comment":{
      "messages":[ ... ],
      "user_properties":{ ... },
      "id":"comment 1"
   },
   "entities":[ ... ],
   "labels":[ ... ],
   "sequence_id":"ABC123"
}{
   "comment":{
      "messages":[ ... ],
      "user_properties":{ ... },
      "id":"comment 1"
   },
   "entities":[ ... ],
   "labels":[ ... ],
   "sequence_id":"ABC123"
}
```
我们可以使用此sequence_id将当前注释推进到队列中的下一个。现在，当我们获取 2 时，我们将返回注释 2 和 3：

Communications Mining 框架将为您实现此获取和推进循环。

调度程序框架概述

通过简单修改必要的设置，您可以配置调度程序框架以使用自己的流中的注释，从而节省实施时间并确保遵循最佳实践。

就像 REFramework 一样，它可以完全按原样使用，作为即插即用的解决方案，因为无需修改代码（只需在配置 Excel 文件中添加设置），它会从定义的流（作为在 CommunicationsMining 包中定义（请查看“依赖项”部分）类型的对象，并将其数据添加到相应的队列中。或者，也可以完全自定义，您可以根据需要添加自己的逻辑（例如，用于验证 Communications Mining™ 预测的规则）。

如上所述， Communications Mining Dispatcher Framework使用获取和高级循环方法，我们可以一次推进一个注释，或一次推进一批注释（我们可以在配置文件中设置批次的大小）。请记住，调度程序用作一个或多个下游流程的订阅源，因此在配置文件中，我们还在为每个流程定义了相应的队列，并定义了将项目添加到队列的规则。

总体步骤如下：

我们获取初始批次的注释。这将从 Communications Mining 流返回一批注释、批次中最后一个项目的sequence_id以及从当前批次中筛选出的项目数。
如果没有发生异常（已成功连接到流），并且未处于流的末尾，我们会检查当前批处理中是否还有项目需要处理（如果还有批处理，我们甚至可能会获取不带注释的批次）筛选器，并且当前批次中的所有注释均不适用）。
如果有项目需要处理，我们会逐个处理：根据当前项目所属的使用者 RPA 流程，我们会检查项目数据的验证规则。
如果项目通过检查，我们会将新的队列项目添加到相关队列中（根据配置 Excel 文件中的设置）。注释的 uid 将设置为队列项目的引用。如果未通过验证规则，我们会将一个队列项目添加到 HIT L 队列中。创建的每个队列项目都将包含注释的所有通用字段和标签预测，以便在下游流程中使用。
处理完当前批次中的每个项目后，我们首先使流前进（使用批次的最后一个项目的sequence_id ），然后从流中获取新批次。
如果到达流的末尾（因为我们在该批处理中没有检索到任何注释，并且没有筛选出的注释），我们就知道已经越过流的末尾，处理结束。

配置

配置调度程序所需的所有设置都可以在 Data/Config.xlsx 文件中找到。

注意：确保将所有相应资产添加到 Orchestrator。

设置和资产工作表

名称	说明
OrchestratorProcessAQueueName	我们的调度程序会将有效注释推送到此队列，以供 RPA 使用者流程 A 处理。
OrchestratorProcessBQueueName	我们的调度程序会将有效注释推送到此队列，以供 RPA 使用者流程 B 处理。
OrchestratorHITLQueueNameA	如果注释未通过为相应流程定义的“验证规则”，我们的“调度程序”将将该队列推送到此队列。 HITL 队列将由“人工回圈”编排流程处理，该流程为添加的每个队列项目创建验证操作。
OrchestratorGeneralQueueName	我们的调度程序将未针对特定 RPA 使用者流程分类的注释推送到此队列。
Communications MiningApiTokenCredential	从流中获取并在流中推进所需的 Communications Mining™ API 令牌，存储在凭据资产中。
ExitOnEmptyStream	如果此设置为 False，则即使我们到达流的末尾，框架也将持续运行。

每个流程验证表

名称	说明
{ProcessName}_Label	设置的命名约定是，将注释标记为指定由当前流程处理的标签+“_”+“标签”关键字。它的值是下游流程的名称。示例：名称`Policy_Label` ，值`ProcessA` 。

由于调度程序可以填充一个或多个下游流程的输入队列，因此我们建议您在配置文件中为每个流程创建一个新工作表，您将在其中定义该流程的验证规则。工作表的命名约定应为：“{ProcessName}Validations”。默认情况下，配置文件包含流程 A 和流程 B 的 2 个验证工作表。

异常处理

框架会将每个事务项目（Communications Mining™ 注释）处理过程中发生的每个异常收集到两个数据表中：一个用于系统异常，另一个用于业务规则异常。

在“结束流程状态” 中，您可以使用表格根据业务逻辑处理异常（使用这些表格创建 Excel 文件、将其作为报告电子邮件的附件发送等）。

架构

依赖项

我们创建了自定义活动来处理可从 UiPath™ 执行以与 Communications Mining™ 集成的主要操作：“获取流”、“推进流”。此外，框架的事务类型为 CommunicationsMining.Result，这是包中定义的一种数据类型，用于保存为每个注释定义的所有信息条及其相应的预测标签和通用字段。

You need to have the CommunicationsMining package in one of your feeds, in order for the Dispatcher Framework to load correctly, downloaded from the Marketplace: here.

状态

由于框架基本上是一个 REFramework，因此它是一个具有相同状态的状态机。请查阅 REFramework 文档，以获取有关每种状态的更多详细信息。

唯一的修改是在“获取事务数据状态”和“流程事务状态”之间添加了“高级流转换”。如果当前获取的批次中没有要处理的项目，则执行将返回到“获取事务数据”状态，以在流中进一步推进。

共享变量

下面的变量在 Main.xaml 文件中声明，并作为参数共享给在框架中调用的工作流，或者它们只是决定通过框架的执行流程：

变量名称	说明
ShouldStop(Boolean)	当作业（从 Orchestrator）强制停止时为 True。
TransactionItem(CommunicationsMining.Result)	事务项目由 Communication Mining 流中的一个注释表示。我们一次处理一个项目，并将其数据添加到相应的队列中。
SystemException(Exception)	在状态转换期间使用，以表示业务异常以外的异常。
BusinessException(BusinessRuleException)	在状态之间转换期间使用，表示不符合正在自动化的流程的规则的情况。
TransactionNumber(Int32)	事务项目的顺序计数器。
Config(Dictionary(String,Object))	Dictionary structure to store configuration data of the process (settings, constants, assets and Validation properties).
RetryNumber(Int32)	用于控制在系统异常的情况下重试事务处理的次数。
TransactionData(IList(CommunicationsMining.Result))	当前按最新的“提取”操作从流中检索的注释批次。
ConsecutiveSystemExceptions(Int32)	用于控制连续出现系统异常的次数。
BusinessExceptionsDT(DataTable)	包含有关事务处理期间发生的业务规则异常的详细信息的表格。一行包含有关一个错误事务的信息。
ApplicationExceptionsDT(DataTable)	Table with details on the System Exceptions occurred during the processing of the Transactions. One row contains info about one faulty transaction
GlobalRetryInterval(TimeSpan)	默认情况下为框架中每个重试范围设置的全局重试间隔。
GlobalMaxAttempts(Int32)	The global number of Max Attempts set by default for every Retry Scope in the Framework.
CurrentSequenceId(String)	最新的流批次提取操作检索到的序列 ID。这是当前流批次中最后一个项目的序列 ID。
CurrentBatchFilteredResults(Int32)	不符合为 Communication Mining 中的流定义并由最新的“提取”活动（从“当前提取的批次”中筛选出）筛选出的筛选器的项目数。
CommunicationsMiningApiToken(SecureString)	在 Communication Mining 中定义的 API 令牌。其值应存储在 Orchestrator 的凭据资产中。
CurrentBatchNumber(Int32)	最好将流拆分为多个批次（以缩短检索数据的性能）。这将告诉我们当前正在处理的批次。
ShouldAdvanceTheStream(Boolean)	如果当前获取的批次中没有要处理的项目，则执行将返回到“获取事务数据”状态，以在流中进一步推进。

Communications Mining™ 特定工作流

工作流名称	说明
GetNextStreamBatch	我们正在尝试获取下一个 Communications Mining™ 流批次注释。“获取流”活动将连接到 Communications Mining，并使用以下内容填充“获取流”对象：- 结果集合（大小符合请求的大小）- 当前批次的序列 ID（检索到的批次中最后一个注释的序列 ID））- 筛选出的注释数量（如果我们对 Communications Mining 流应用了筛选器，则系统将跳过与筛选器不匹配的注释）“获取”活动对 Communications Mining 执行 HTTPS 请求。
AdvanceStreamBatch	我们正在尝试推进 CommunicationsMining 注释流。 “高级流” 活动将连接到 CommunicationsMining，并使用流中某个注释的序列 ID 作为输入，该活动会在流中将注释（在具有给定序列 ID 的注释之前和之后）标记为已读，以便下次从流中获取时不返回相同的值。如果您连续多次提取而不推进流，则您每次都会收到相同的电子邮件。“推进”活动对 CommunicationsMining 执行 HTTPs 请求。
GetTransactionData	从数组注释中获取事务项目。由于存在多个事务，因此我们使用参数 in_TransactionNumber 作为索引来检索要处理的正确事务。如果当前批次中没有更多事务，则需要推进流并获取下一批。如果我们连续多次提取而不推进流，则您每次都会得到相同的结果。如果批次中存在项目，并且仍有一些项目需要处理，我们将采用批次中下一个事务项目的实例。否则，我们会标记一个事实：当前批次中没有更多项目需要处理，并且我们需要推进流。此处，我们不会将 io_TransactionItem 设置为“无”，因为这会停止整个框架的处理，并且下一批中可能仍有项目。在“获取事务数据状态”中设置了“停止”条件
CheckValidationRules	这是一个基本的验证算法示例，用于仅根据为当前项目预测的标签数量来确定预测是否有效。如果有一个标签，则验证成功，我们只需要从配置文件中获取下游流程的名称即可。如果我们有多个标签，则自动验证将设置为失败。添加您自己的逻辑，以决定使用者流程的名称，以及对项目的预测是否有效或需要人工验证。如果我们为当前项目只有一个预测标签，则必须获取其相应流程的名称。我们根据为当前项目预测的一个标签，从配置文件中获取下游（使用者）流程的名称。在配置文件中，流程名称设置的命名约定为：注释标签 + "_" + "Label" 关键字。如果预测当前项目具有多个标签，则需要人工决定如何进行下游自动化。因此，自动验证成功应标记为 false，以便将当前项目添加到“循环中的人工”队列中，以便稍后进行手动验证。
CreateDictionaryFromCommunicationsMiningItem	我们需要将从 CommunicationsMining 中获取的当前项目的信息添加到队列中。因此，我们将基于它创建一个字典。我们将使用字典添加新队列项目的定义属性。
AddTransactionItemToQueue	将新项目添加到队列中。其所有属性应已在 in_QueueItemProperties 字典中设置。确保已选中您队列的“强制执行唯一引用”复选框。
流程	调度程序的用途是使用在 Communications Mining™ 中获得的每个项目的信息填充相应的队列，以便下游自动化中的使用者流程处理这些项目。在此工作流中，我们必须将当前项目添加到其相应的队列中。步骤：1.我们将基于事务项目创建字典。我们将使用字典添加新队列项目的定义属性。2.根据在 Communications Mining 中获得的当前项目信息，我们将决定其相应的使用者流程，并根据预测数据检查验证规则。3.如果验证成功，我们会将该项目添加到使用者流程的队列中。如果没有，我们会将其添加到“大循环”队列中，以等待人工验证，并可能由人工处理。对于当前事务：- 如果引发“业务规则异常”，则系统会跳过该事务。-如果发生另一种异常，则可以重试当前事务。
ExceptionsHandler	此工作流应用于框架中的最终异常处理程序。如果输入数据表已填充，则其中包含有关在流程当前运行期间发生的所有应用程序和/或业务规则异常的详细信息。

使用框架

在使用框架之前：

确保在 Orchestrator 中配置所有必需的资产（查看“设置和资产”部分），并在 Data/Config.xlsx 文件中进行必要的修改。
确保要添加项目的队列存在于 Orchestrator 中，并且选中了“强制执行唯一引用”复选框，以避免向队列添加重复项并在下游自动化中多次处理同一项目。
在 Communications Mining/CheckValidationRules.xaml 中添加您自己的验证规则。目前，我们仅检查当前项目是否具有多个预测标签。如果是，则验证失败。如果不是，我们将根据当前项目的标签获取与当前项目相对应的流程名称。

在此页面上