process-mining
latest
false
重要 :
请注意此内容已使用机器翻译进行了部分本地化。
UiPath logo, featuring letters U and I in white
Process Mining
Automation CloudAutomation Cloud Public SectorAutomation SuiteStandalone
Last updated 2024年11月13日

Structure of transformations

概述

以下是Process Mining应用程序模板的转换步骤概述。



models\文件夹是根据转换步骤的结构进行组织的。


1. 输入

输入步骤用于加载原始数据。 通常会执行以下操作,为下一个转换步骤准备数据:

  • 选择具有可选宏和必选宏的字段。 使用可选宏时,原始数据中不需要存在字段。
  • 将字段类型 转换为适当的数据类型。
  • 在转换的早期筛选 表以减少数据大小。

注意: 建议尽可能减少提取中已存在的数据大小。

命名约定

如果您预计名称会在接下来的转换步骤中与表格名称冲突,最佳实践是为输入表添加后缀_input

可选字段

连接器的输入包含必填数据和可选数据。 对于可选字段,应使用 pm-utils 包中的 optional 宏。 这可确保字段在源数据中不可用时获取值 null 。 这样,所有转换都将正常运行。
  • 如果整个表格都是可选的,请使用 optional_table() 宏。

2. 实体

在“实体”步骤中,输入表将转换为实体表。 预期事件所需的每个实体都应具有自己的表格。 请参阅设计事件日志。 此外,也可以在此处定义支持实体。

在下面的示例中,将 3 个输入表Invoices_inputInvoice_types_inputCustomers_input联接在一起以创建实体表 Invoices。


准则

创建实体表时,请遵循以下准则。

  • 有一个实体 ID 字段,该字段对于每个数据记录都是唯一的。
  • 数据分析所需的所有实体字段均已存在。
  • 所有实体字段都具有易于理解的名称。
如果适用,实体表通过 ID 字段与另一个实体相关联。 请参阅下面的示例,其中发票行通过Invoice_ID字段与发票实体相关联。


Additional transformations

并非所有输入表都转换为实体表。 此外,其他输入表可能包含相关信息,例如示例中的“客户”表。 在实体步骤中将它们定义为单独的表格可能会很方便,以便可以在数据转换中重用它们。

命名约定

如果实体表名称日后会导致名称冲突,请在表中添加后缀 _base。

3. 事件

注意:事件日志自定义流程应用程序模板的输入已经是 Process Mining 定义良好的事件日志。 无需在此处将源系统中的数据转换为 Process Mining 的事件。 这意味着事件日志应用程序和自定义流程应用程序的转换中不存在3. events

在此转换步骤中,将为每个实体创建事件表。 请参阅设计事件日志。 事件表中的每条记录代表发生的一个事件。 关于数据的结构化方式,有两种情况:

  • 时间戳字段: 实体表上具有事件时间戳的字段。 例如, Invoices表中的Invoice_created字段。
  • 事务日志:事件列表。

根据数据的结构,用于创建事件表的转换会有所不同。

Timestamp fields

在这种情况下,时间戳字段的值必须转换为事件表中的单独记录。 以下示例是包含三个时间戳字段的发票表格。



每个时间戳字段用于创建单独的事件表。 对于时间戳字段包含值的每条记录,请创建一个表格,其中包含发票 ID、事件名称(活动)和事件发生的时间戳(事件结束)。



Invoices_input table分为Invoice_events_Create_invoiceInvoice_events_Delete_invoiceInvoices_events_Change_invoice_price
然后,可以将单独的事件表合并到每个实体的单个事件表中,例如Invoices_events

事务日志

如果事件存储在事务日志中,则应标识每个实体的相关事件。 为每个实体创建一个表,并存储相应的实体 ID、事件名称 (Activity) 以及事件发生的时间戳 (Event end)。

在以下示例中,事务日志包含 采购订单发票 实体的事件。



在事件表中,以下字段为必填字段。 事件表中的所有记录都应包含这些字段的值。

字段

描述

实体 ID

发生事件的实体的 ID。 例如, 发票 ID

活动

该活动描述了对实体执行的操作。

Event end

“事件结束”字段指示特定事件的完成时间。 理想情况下,这应该是日期时间字段,而不是日期。

命名约定

根据 [Entity] + _events结构命名表。 例如 Purchase_order_eventsInvoice_events

4. 事件日志

单个实体流程

当流程包含一个实体时,此步骤不需要其他转换。 单个实体表和事件表的格式已正确。

多实体流程

当一个流程中涉及多个实体时,所有实体的事件都需要链接到在流程中被视为“案例”的主要实体。 有关详细信息,请参阅定义事件日志。 以下步骤描述了如何将所有事件与主要实体相关联,以及如何将它们组合到单个事件日志中。

Entity relations

创建“实体关系”表以集中所有实体之间的关系。 此实体关系表将包含相关实体的 ID 字段。

要创建实体关系表,请根据 ID 字段联接所有实体表:

  • 从主要实体开始
  • 使用左联接将相关实体联接到主实体。
  • 如果实体与主实体不直接相关,则将实体左联接到已联接到主实体的相关实体。

在以下示例中,存在三个实体: 采购订单发票行发票 采购订单 被视为流程中的主要实体。 发票行 直接链接到 采购订单发票 通过 发票行间接链接。





docs image

以下是生成的实体关系表。



Relation tables

使用实体关系表中的组合信息,将主实体和每个其他实体之间的单个关系存储在单独的表中。
docs image


docs image


事件日志

下一步是使用这些关系向每个事件表添加相应的“案例 ID”。 “案例 ID”是通过关系表获取的,其中事件信息是从事件表中获取的。 要创建完整的事件日志,请合并每个实体的事件表。
docs image

命名约定

如果事件日志表名称可能导致日后出现名称冲突,请在事件日志表的名称中添加后缀_base

5. 业务逻辑

在最后一个转换步骤中,根据需要添加业务逻辑以进行数据分析。 可以在此处将其他派生字段添加到现有表格中。 例如,在仪表板的 KPI 中使用的特定吞吐量时间或布尔值字段。

在 Process Mining中,此转换步骤中定义了两个额外的标准表: TagsDue dates

标签

标签是案例的属性,表示某些业务规则。 通常添加标签是为了便于分析这些业务规则。 例如:

  • 由同一人支付和批准的发票。
  • 发票审批时间超过 10 天。
  • 已跳过检查发票活动。

标签表中的每条记录都代表特定案例的数据中出现的一个标签。 此表格的必填字段为“案例 ID”和“标签”。 并非所有案例都有标签,有些案例可能有多个标签。 以下是“标签”表格示例。



到期日期

截止日期表示流程中的截止日期。 这些活动将添加到数据中,以分析活动是否在这些截止日期按时执行。

到期日期表中的每条记录代表特定事件的一个到期日期。到期日期示例如下:

  • 付款事件的付款截止日期。
  • 批准事件的批准截止日期。
此表的必填字段为 Event IDDue dateActual dateExpected date


并非所有活动都有截止日期,有些活动可能有多个截止日期。

此页面有帮助吗?

获取您需要的帮助
了解 RPA - 自动化课程
UiPath Community 论坛
Uipath Logo White
信任与安全
© 2005-2024 UiPath。保留所有权利。