プロセスのデータ保持ポリシー

概要

プロセスを実行すると大量のジョブ データが生成され、Orchestrator のデータベースに急速にデータが溜まる可能性があります。保持ポリシーを使用すると、秩序立った方法でデータベースを解放できます。

保持ポリシーとは、一定期間後にデータベースからデータを削除するアクションを設定することで、データをオフロードする組み込み機能を確実に使用することに合意する契約です。保持ポリシーを利用することでデータベースが軽くなり、Cloud Orchestrator のパフォーマンスが向上します。

ジョブの条件

指定したプロセスに対して設定した保持ポリシーは、以下の条件を同時に満たすすべてのジョブに適用されます。

• 最終ステータスにあること。たとえば、エラー、成功、停止など。
• 保持期間である X 日以上前に終了していること。

ジョブが削除されるタイミングを特定する

保持期間はカレンダー日に基づいて計算されます。したがって、条件を満たしたジョブは X+1 カレンダー日に削除されます。ここでの X は保持期間、+1 はその直後のカレンダー日に削除されることを示します。

削除は直後のカレンダー日の最初、つまり保持期間が終了した時点の数時間後に実行される可能性がありますのでご注意ください。

たとえば、保持期間を 1 日に設定するとします。

ジョブの終了日時が 2022 年 6 月 6 日の 0 時 1 分 (カレンダー日の最初の 1 分) でも、2022 年 6 月 6 日の 23 時 59 分 (カレンダー日の最後の 1 分) でも、削除は 6 月 8 日 (6 月 6 日 + 1 日の保持期間 + 1 日後 = 6 月 8 日) に実行されます。

つまり、以下のことが分かります。

• 直後のカレンダー日にアーカイブを行うことで、少なくとも 1 カレンダー日 (保持期間) はジョブのデータが確実に保持されます。
• アイテムのアーカイブは、直後のカレンダー日の終わりまでに確実に完了することが目指されます。

ポリシーの種類

保持ポリシーの種類は以下の 3 つです。

• 新しく作成されるプロセス向けの既定のポリシー - 新しいプロセスから作成されるすべてのジョブは 30 日後に削除され、削除されたトランザクションを元に戻すことはできません。これは組み込みのオプションです。
• カスタム ポリシー - すべてのジョブは選択した期間 (最大 180 日) の保持期間後に削除またはアーカイブされます。このオプションは、「カスタム保持ポリシーを設定する」セクションの指示に従って設定できます。

重要:

既定の 30 日のポリシーは以下に適用されます。

• 関連付けられたプロセスがないジョブ
• 関連付けられたプロセスが削除されているジョブ

ポリシーの結果

カスタム保持ポリシーのもたらす結果は次のとおりです。

• 指定した期間より古いジョブが削除されます。

• 指定した期間より古い、有効なジョブが削除されますが、そのデータは既存のストレージ バケットにアーカイブされ、あとで参照できます。これにより、情報を失うことなく Orchestrator のデータベースをオフロードできます。

  注:

  削除されたジョブの情報を含む Insights のダッシュボードでは、引き続き正しいデータが表示されます。

  Orchestrator での削除は、Insights に反映されません。

  注: 削除されたジョブの一意の参照は保持されるため、新しいジョブを追加しても重複する一意の参照は作成されません。

オフロードのメカニズム

サーバーがビジーでない時間帯にバックグラウンド ジョブが毎日実行され、すべての保持ポリシーに必要なアクションを実行します。

最初は大量のデータを処理する必要があります。運用パフォーマンスへの影響を回避するため、ジョブがデータのバックログを解析し正確なタイミングで処理を行えるようになるまでに 1 か月程度かかる可能性があります。

そのためポリシーが即時で適用されない可能性がありますが、処理は 1 か月程度で追い付きます。

たとえば、プロセスに 45 日の削除ポリシーを設定するとします。ポリシーはフェーズ 1 の終了時にアクティブ化されますが、45 日が経過したジョブがすべて確実に処理されるまでには約 1 か月かかります。これは、ジョブにデータのバックログを処理させるための初回例外です。

カスタム保持ポリシーを設定する

カスタム保持ポリシーを設定する手順は次のとおりです。

1. Orchestrator でテナント内の目的のフォルダーに移動します。
2. [プロセス] ページを開きます。
3. 新しいプロセスを追加するには、[プロセスを追加] をクリックします。既存のプロセスを編集するには、対象のプロセスのそれぞれで [その他のアクション] > [編集] をクリックします。[プロセスを追加]/[プロセスを編集] ページが開きます。
4. [保持ポリシー] セクションで、[アクション] ドロップダウン メニューからポリシーの結果を選択します。

   ジョブを削除して情報を保持するには、「ジョブをアーカイブする」の手順をご覧ください。

   ジョブを完全に削除するには、「ジョブを削除する」の手順をご覧ください。

ジョブをアーカイブする

ジョブのデータを失わずに Orchestrator のデータベースから情報をオフロードする必要がある場合は、ジョブをアーカイブします。

前提条件: アーカイブされるジョブを保存するストレージ バケットが必要です。

1. [アクション] ドロップダウン メニューから [アーカイブ] を選択します。
2. [保持期間] を選択します。1 と 180 の間の値を入力します。既定値は 30 です。

   この期間の終了時には、それまでの間に更新されていない最終ステートのジョブ (ジョブ イベントや実行メディアを含む) はすべて削除され、それらの情報は対象のバケットに保存されます。

3. アーカイブされるアイテムを保存する対象のバケットを選択します。

アーカイブされた情報を取得するには、関連するストレージ バケットのアーカイブ ファイルにアクセスします。

注:

注 1: ストレージ バケットには Orchestrator のストレージ バケットを使用するか、外部のストレージ バケットをリンクできます。

注 2: アーカイブによってストレージ バケットにアイテムを追加できるよう、使用するバケットは読み取り専用にしないでください。

注 3: 同じストレージ バケットを使用して異なるプロセスのプロセス アイテムをアーカイブできます。

注 4: このフィールドは [アーカイブ] オプションでのみ使用できます。

注 5: 正常に完了したアーカイブ操作は [テナント] > [監査] ページに記録され、[アクション] の種類が [アーカイブ] であることで識別できます。

注 6: エラーによってアーカイブ操作が中断された場合、エラーを修正するためにアラートで通知されます。アーカイブ操作は、削除の次回実行時 (次のカレンダー日) にリトライされます。アーカイブのリトライが成功するまで、影響を受けるジョブを表示またはアクセスすることはできません。

ジョブを削除する

処理済みのジョブのデータを不要と判断した場合は、すべての情報を Orchestrator のデータベースから削除できます。

1. [アクション] ドロップダウン メニューから [削除] を選択します。
2. [保持期間] を選択します。1 と 180 の間の値を入力します。既定値は 30 です。

   この期間の終了時には、それまでの間に更新されていない最終ステートのジョブ (ジョブ イベントや実行メディアを含む) が完全に削除されます。

出力をアーカイブする

.zip ファイル

ジョブをアーカイブすると、保持期間が終わった時点で .zip ファイルが作成されます。パスは次のとおりです。

「Archive/Processes/Process-{process_key}/{archiving_operation_date}-{archiving_operation_timestamp}.zip」それぞれ、次の値が使用されます。

• {process_key} - ジョブを含むプロセスの一意の識別子です。
• {archiving_operation_date} - アーカイブが生成された UTC 日付 (yyyy-MM-dd の形式) です。
• {archiving_operation_timestamp} - アーカイブが生成された UTC 時刻 (HH-mm-ss-fff の形式) です。
  たとえば、アーカイブ ファイルの名前は Archive/Processes/Process-1d1ad84a-a06c-437e-974d-696ae66e47c2/2022-05-26-03-00-08-496.zip のようになります。

.csv ファイル

ファイルを展開すると、.zip ファイルは同じ名前構文を持つ .csv ファイルを表示します。ファイル名は次のとおりです。

「Process-{process_key}-{archiving_operation_date}-{archiving_operation_timestamp}.csv」

Metadata.json ファイル

.json ファイルには、コンテナー プロセスに関する詳細が含まれており、コンテナー プロセスを容易に特定できます。

データ ボリュームが大きい場合

プロセスが多数のジョブを処理していた場合、それらはバッチでアーカイブされます。この場合、各バッチの ZIP ファイル名の {archiving-operation-timestamp} の値はバッチ アーカイブの作成時刻に応じて異なります。

プロセスの保持ポリシーの API

保持ポリシーをクライアントに組み込むには、Swagger ファイルで ReleaseRetention API の専用のエンドポイントを使用します。エンドポイントは以下のとおりです。

• GET /odata/ReleaseRetention - すべてのアクティブなポリシーのリストを返します。ポリシーのアクション、保持期間 (日)、ポリシーが適用されるプロセスの ID などの情報が含まれます。
• GET /odata/ReleaseRetention({key}) - 指定したプロセスのポリシーの情報を返します。
• PUT /odata/ReleaseRetention({key}) - 指定したプロセスのポリシーの情報を更新します。
• DELETE /odata/ReleaseRetention({key}) - 指定したプロセス ポリシーを、既定のポリシー (30 日間の保持 + 削除) にリセットします。

注: 保持ポリシー機能の導入前に作成されたプロセスに対して DELETE エンドポイントを呼び出した場合、組み込み保持ポリシー (30 日間の保持 + 削除) が適用されます。

詳しくは、『UiPath Orchestrator API ガイド』をご覧ください。

ポリシーの追跡列と監査

カスタム保持ポリシーが設定されているプロセスを簡単に特定するには、[プロセス] ページの [列] ドロップダウン リストで [保持期間後のアクション] と [保持期間 (日)] 列のチェックボックスをオンにし、これらの列を有効化します。

[保持期間後のアクション] 列にはポリシーの結果が表示され、[保持期間 (日)] 列にはポリシーが適用されるまでの残り時間が表示されます。

前述のとおり、新しく作成されるプロセスには 30 日間の保持ポリシーが適用されます。ただし、既定のポリシーが設定されているプロセスを識別する際には、保持期間の値を識別基準として常に信頼することはできません。たとえば、カスタム保持期間を 55 日間に設定し、その後期間を 30 日間に更新した場合、更新後のポリシーは既定のポリシーではありません。各シナリオに既定のポリシーが設定されているかどうかを確認するには、[監査] ページをご覧ください。

バックグラウンド ジョブによって保持ポリシーに関連するクリーンアップ操作 (アーカイブと削除、または単なる削除) が実行された場合、対応するエントリが管理者に代わって監査に作成されます。

1 はアーカイブのアクションを表します。0 は削除のアクションを表します。