- リリース ノート
- はじめる前に
- 基本情報
- Integrations
- プロセス アプリを使用する
- アプリを作成する
- データを読み込む
- プロセス アプリをカスタマイズする
- アプリ テンプレート
- その他のリソース
- すぐに使えるタグと期限日
- ローカル環境でデータ変換を編集する
- ローカルのテスト環境を設定する
- イベント ログをデザインする
- SAP Ariba の抽出ツールを拡張する
- パフォーマンス特性
- 基本的なトラブルシューティング ガイド
![](https://docs.uipath.com/_next/static/media/grid.05ebd128.png?w=3840&%3Bq=100)
変換の構造
入力手順を使用して生データを読み込みます。通常は、次の操作を行って、データを次の変換手順用に準備します。
- 任意および必須のマクロが含まれるフィールドを選択します。任意のマクロが使用される場合、フィールドを生データに含める必要はありません。
- フィールドを適切なデータ型に型キャストします。
-
テーブルをフィルター処理し、変換の早い段階でデータ サイズを減らします。
エンティティの手順では、入力テーブルをエンティティ テーブルに変換します。予期されるイベントに必要なエンティティごとに専用のテーブルを用意する必要があります。「イベント ログを定義する」をご覧ください。さらに、サポート エンティティもここで定義できます。
Invoices_input
、Invoice_types_input
、Customers_input
の 3 つの入力テーブルが結合され、エンティティ テーブル「Invoices」が作成されています。
エンティティ テーブルを作成する際は、以下のガイドラインに従ってください。
- エンティティ ID フィールドが 1 つあり、各データ レコードで一意である。
- データ分析に必要なすべてのエンティティ フィールドが存在する。
- すべてのエンティティ フィールドに分かりやすい名前が付いている。
Invoice_ID
フィールドを介して請求書エンティティに関連しています。
すべての入力テーブルがエンティティ テーブルに変換されるわけではありません。また、他の入力テーブルに関連情報が含まれる場合もあります (この例では Customers テーブル)。エンティティの手順でそれらを別個のテーブルとして定義し、データ変換で再利用できるようにしておくと便利です。
この変換手順では、各エンティティに対してイベント テーブルを作成します。「イベント ログを定義する」をご覧ください。イベント テーブルの各レコードは、実行される 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
に分割されます。
Invoices_events
)。
イベントがトランザクション ログに保存されている場合は、エンティティごとの関連イベントを特定する必要があります。エンティティごとのテーブルを作成し、対応するエンティティ ID、イベントの名前 (Activity)、イベントが発生したタイムスタンプ (Event end) を格納します。
以下の例では、トランザクション ログに Purchase Order エンティティと Invoice エンティティのイベントが含まれています。
以下のフィールドは、イベント テーブルで必須です。イベント テーブルのすべてのレコードに、これらのフィールドに対応する値が含まれる必要があります。
フィールド |
説明 |
---|---|
エンティティ ID |
イベントが発生するエンティティの ID です。たとえば、Invoice ID です。 |
アクティビティ |
アクティビティでは、エンティティで発生したアクションを記述します。 |
Event end |
[Event end] フィールドは、特定のイベントが完了したタイミングを示します。日付フィールドではなく日時フィールドであるのが理想的です。 |
プロセスに含まれるエンティティが 1 つである場合、このステップでさらに変換を行う必要はありません。単一のエンティティ テーブルと複数のイベント テーブルで既に正しい形式になっています。
プロセスに複数のエンティティが含まれる場合、すべてのエンティティのイベントを、プロセスの「ケース」と見なされるメイン エンティティにリンクする必要があります。「イベント ログを定義する」をご覧ください。以下の手順では、すべてのイベントをメイン エンティティに関連させる方法と、そのイベントを単一のイベント ログに結合する方法について説明します。
「entity-relations」テーブルを作成して、すべてのエンティティ間の関係を一元管理します。この entity-relations テーブルに、関連するエンティティの ID フィールドを格納します。
entity-relations テーブルを作成するには、すべてのエンティティ テーブルを ID フィールドに基づいて結合します。
- メイン エンティティから開始します。
- 関連するエンティティを左結合でメイン エンティティに結合します。
- エンティティがメイン エンティティに直接関連していない場合は、それらのエンティティを、既にメイン エンティティに結合されている関連エンティティに左結合します。
以下の例では、Purchase order、Invoice line、Invoice の 3 つのエンティティがあります。Purchase order はプロセスのメイン エンティティと見なされます。Invoice line は Purchase order に直接リンクされ、Invoice は Invoice line を介して間接的にリンクされます。
生成される entity-relations テーブルは以下のとおりです。
最後の変換手順では、データ分析に必要なビジネス ロジックが追加されます。ここでは、追加の派生フィールドを既存のテーブルに追加できます。たとえば、ダッシュボードの KPI で使用する特定のスループット時間フィールドや Boolean フィールドです。
Tags
と Due dates
があります。
タグはケースのプロパティで、特定のビジネス ルールを表します。通常は、ビジネス ルールを簡単に分析できるようにするために追加します。以下に例を示します。
- 請求書の支払と承認が同じユーザーによって行われている。
- 請求書の承認時間が 10 日を超えている。
- 請求書を確認するアクティビティがスキップされている。
タグ テーブルの各レコードは、特定のケースのデータで発生した 1 つのタグを表します。このテーブルの必須フィールドは、「Case ID」と「Tag」です。すべてのケースにタグが付くわけではありません。一部のケースには複数のタグが付く可能性もあります。以下は、Tags テーブルの例です。