Process Mining

変換の構造

概要

UiPath Process Mining アプリテンプレートの変換手順の概要は以下のとおりです。

models\ フォルダーは、変換手順の構造に従って編成されます。

1. 入力

入力手順を使用して生データを読み込みます。通常は、次の操作を行って、データを次の変換手順用に準備します。

任意および必須のマクロが含まれるフィールドを選択します。任意のマクロが使用される場合、フィールドを生データに含める必要はありません。
フィールドを適切なデータ型に型キャストします。
テーブルをフィルター処理し、変換の早い段階でデータサイズを減らします。

注: 可能な場合は、抽出時までにデータサイズを減らしておくことをお勧めします。

命名規則

次の変換手順でテーブル名の競合が予想される場合のベストプラクティスは、入力テーブルにサフィックス「 _input」を追加することです。

任意のフィールド

コネクタの入力は必須のデータと任意のデータからなります。任意のフィールドの場合は、pm-utils パッケージの任意のマクロを使用する必要があります。これにより、ソースデータに値がない場合、フィールドが確実に値 null を取得するようにします。こうすることで、すべての変換が正しく実行されます。

テーブル全体が任意の場合は optional_table() マクロを使用します。

2. エンティティ

エンティティの手順では、入力テーブルをエンティティテーブルに変換します。予期されるイベントに必要なエンティティごとに専用のテーブルを用意する必要があります。「イベントログを定義する」をご覧ください。さらに、サポートエンティティもここで定義できます。

以下の例では、Invoices_input、Invoice_types_input、Customers_input の 3 つの入力テーブルが結合され、エンティティテーブル「Invoices」が作成されています。

ガイドライン

エンティティテーブルを作成する際は、以下のガイドラインに従ってください。

エンティティ ID フィールドが 1 つあり、各データレコードで一意である。
データ分析に必要なすべてのエンティティフィールドが存在する。
すべてのエンティティフィールドに分かりやすい名前が付いている。

これに該当する場合、エンティティテーブルは ID フィールドを介して別のエンティティに関連しています。以下の例をご覧ください。請求書明細 (invoice_lines) は、Invoice_ID フィールドを介して請求書エンティティに関連しています。

その他の変換

すべての入力テーブルがエンティティテーブルに変換されるわけではありません。また、他の入力テーブルに関連情報が含まれる場合もあります (この例では Customers テーブル)。エンティティの手順でそれらを別個のテーブルとして定義し、データ変換で再利用できるようにしておくと便利です。

命名規則

エンティティテーブルの名前が後で競合する場合は、テーブルにサフィックス「_base」を追加します。

3. イベント

注: イベントログとカスタムプロセスのアプリテンプレートの入力データは、既に Process Mining 用に適切に定義されたイベントログです。ソースシステムのデータを Process Mining のイベントにこの段階で変換する必要はありません。つまり、イベントログとカスタムプロセスのアプリの変換には 3. events は存在しません。

この変換手順では、各エンティティに対してイベントテーブルを作成します。「イベントログを定義する」をご覧ください。イベントテーブルの各レコードは、実行される 1 つのイベントを表します。データを構造化する方法には次の 2 つのシナリオがあります。

タイムスタンプフィールド: イベントのタイムスタンプが付いたエンティティテーブルのフィールドです。たとえば、Invoices テーブルの Invoice_created フィールドです。
トランザクションログ: イベントのリストです。

データがどのように構造化されているかによって、イベントテーブルを作成するための変換は異なります。

タイムスタンプフィールド

このシナリオでは、タイムスタンプフィールドの値をイベントテーブルの別個のレコードに変換する必要があります。以下の例は、3 つのタイムスタンプフィールドを含む Invoices テーブルです。

各タイムスタンプフィールドを使用して、別個のイベントテーブルを作成します。タイムスタンプフィールドに値が含まれるすべてのレコードに対して、請求書 ID (Invoice ID)、イベントの名前 (Activity)、イベントが発生したタイムスタンプ (Event end) が含まれるテーブルを作成します。

Invoices_input table は、Invoice_events_Create_invoice、Invoice_events_Delete_invoice、および Invoices_events_Change_invoice_price に分割されます。

その後、別個のイベントテーブルをエンティティごとに 1 つのイベントテーブルにマージできます (例: Invoices_events)。

トランザクションログ

イベントがトランザクションログに保存されている場合は、エンティティごとの関連イベントを特定する必要があります。エンティティごとのテーブルを作成し、対応するエンティティ ID、イベントの名前 (Activity)、イベントが発生したタイムスタンプ (Event end) を格納します。

以下の例では、トランザクションログに Purchase Order エンティティと Invoice エンティティのイベントが含まれています。

以下のフィールドは、イベントテーブルで必須です。イベントテーブルのすべてのレコードに、これらのフィールドに対応する値が含まれる必要があります。

フィールド	説明
エンティティ ID	イベントが発生するエンティティの ID です。たとえば、Invoice ID です。
アクティビティ	アクティビティでは、エンティティで発生したアクションを記述します。
Event end	[Event end] フィールドは、特定のイベントが完了したタイミングを示します。日付フィールドではなく日時フィールドであるのが理想的です。

命名規則

テーブルの名前は、[エンティティ] + _events の構造に従います (例:  Purchase_order_events、Invoice_events)。

4. イベントログ

単一のエンティティプロセス

プロセスに含まれるエンティティが 1 つである場合、このステップでさらに変換を行う必要はありません。単一のエンティティテーブルと複数のイベントテーブルで既に正しい形式になっています。

複数のエンティティプロセス

プロセスに複数のエンティティが含まれる場合、すべてのエンティティのイベントを、プロセスの「ケース」と見なされるメインエンティティにリンクする必要があります。「イベントログを定義する」をご覧ください。以下の手順では、すべてのイベントをメインエンティティに関連させる方法と、そのイベントを単一のイベントログに結合する方法について説明します。

エンティティのリレーション

「entity-relations」テーブルを作成して、すべてのエンティティ間の関係を一元管理します。この entity-relations テーブルに、関連するエンティティの ID フィールドを格納します。

entity-relations テーブルを作成するには、すべてのエンティティテーブルを ID フィールドに基づいて結合します。

メインエンティティから開始します。
関連するエンティティを左結合でメインエンティティに結合します。
エンティティがメインエンティティに直接関連していない場合は、それらのエンティティを、既にメインエンティティに結合されている関連エンティティに左結合します。

以下の例では、Purchase order、Invoice line、Invoice の 3 つのエンティティがあります。Purchase order はプロセスのメインエンティティと見なされます。Invoice line は Purchase order に直接リンクされ、Invoice は Invoice line を介して間接的にリンクされます。