- 基本情報
- ベスト プラクティス
- テナント
- リソース カタログ サービス
- Automation Suite ロボット
- フォルダー コンテキスト
- 自動化
- プロセス
- ジョブ
- トリガー
- ログ
- 監視
- キュー
- アセット
- ストレージ バケット
- Test Suite - Orchestrator
- Integrations
- クラシック ロボット
- トラブルシューティング
プロセスのデータ保持ポリシー
プロセスを実行すると大量のジョブ データが生成され、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 に反映されません。
注: 削除されたジョブの一意の参照は保持されるため、新しいジョブを追加しても重複する一意の参照は作成されません。
UiPath は、この機能がユーザーのデータに与える影響を認識しています。したがって保持ポリシーのオプションを 3 つの段階に分けて公開します。これは、業務のニーズに最も適したポリシーを評価および判断するための十分な時間を確保することを目的としています。たとえカスタム保持ポリシーを設定しない場合でも既存のポリシーは適用され、120 日が経過した既存のプロセス アイテムはすべて削除されます。
フェーズ |
フェーズの説明 |
---|---|
フェーズ 0 |
情報共有のフェーズです。すべての組織に対して、今後適用されるポリシー、アカウントへの影響、今後の挙動、ロールアウトのメカニズムについて発表します。 フェーズ 0 の最後の時点で機能とその UI がすべての環境にデプロイされますが、ポリシーはアクティブ化されません。 |
フェーズ 1 |
機能のデプロイ後に初めてポリシーをアクティブ化するまでの 6 週間の期間です。この間にプロセスの調整や準備を行うことができます。 アプリケーション情報のカウンターには保持ポリシーが開始するまでの残りの日数が表示されるため、ポリシーの本稼働日の前にアカウントの準備を忘れず行うことができます。 フェーズ 1 の最後の時点で既定のポリシーや設定済みのポリシーがすべて適用されます。 |
フェーズ 2 |
すべてのポリシーがアクティブになり、ポリシーの設定に基づいてアカウントのデータがオフロードされます。 フェーズ 2 には終了日はありません。つまり、新しいポリシーを設定するとそれが直ちに適用されます。 |
サーバーがビジーでない時間帯にバックグラウンド ジョブが毎日実行され、すべての保持ポリシーに必要なアクションを実行します。
最初は大量のデータを処理する必要があります。運用パフォーマンスへの影響を回避するため、ジョブがデータのバックログを解析し正確なタイミングで処理を行えるようになるまでに 1 か月程度かかる可能性があります。
そのためポリシーが即時で適用されない可能性がありますが、処理は 1 か月程度で追い付きます。
たとえば、プロセスに 45 日の削除ポリシーを設定するとします。ポリシーはフェーズ 1 の終了時にアクティブ化されますが、45 日が経過したジョブがすべて確実に処理されるまでには約 1 か月かかります。これは、ジョブにデータのバックログを処理させるための初回例外です。
ジョブのデータを失わずに Orchestrator のデータベースから情報をオフロードする必要がある場合は、ジョブをアーカイブします。
前提条件: アーカイブされるジョブを保存するストレージ バケットが必要です。
アーカイブされた情報を取得するには、関連するストレージ バケットのアーカイブ ファイルにアクセスします。
注 1: ストレージ バケットには Orchestrator のストレージ バケットを使用するか、外部のストレージ バケットをリンクできます。
注 2: アーカイブによってストレージ バケットにアイテムを追加できるよう、使用するバケットは読み取り専用にしないでください。
注 3: 同じストレージ バケットを使用して異なるプロセスのプロセス アイテムをアーカイブできます。
注 4: このフィールドは [アーカイブ] オプションでのみ使用できます。
注 5: 正常に完了したアーカイブ操作は [テナント] > [監査] ページに記録され、[アクション] の種類が [アーカイブ] であることで識別できます。
注 6: エラーによってアーカイブ操作が中断された場合、エラーを修正するためにアラートで通知されます。アーカイブ操作は、削除の次回実行時 (次のカレンダー日) にリトライされます。アーカイブのリトライが成功するまで、影響を受けるジョブを表示またはアクセスすることはできません。
最終ステートのキュー アイテム (キュー アイテム イベントとコメントを含む) はすべて、設定したデータベースに無期限に保持されます。
.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
のようになります。
.zip
ファイルは同じ名前構文を持つ .csv
ファイルを表示します。ファイル名は次のとおりです。
「Process-{process_key}-{archiving_operation_date}-{archiving_operation_timestamp}.csv」
保持ポリシーをクライアントに組み込むには、Swagger ファイルで ReleaseRetention API の専用のエンドポイントを使用します。エンドポイントは以下のとおりです。
- GET
/odata/ReleaseRetention
- すべてのアクティブなポリシーのリストを返します。ポリシーのアクション、保持期間 (日)、ポリシーが適用されるプロセスの ID などの情報が含まれます。 - GET
/odata/ReleaseRetention({key})
- 指定したプロセスのポリシーの情報を返します。 - PUT
/odata/ReleaseRetention({key})
- 指定したプロセスのポリシーの情報を更新します。 - DELETE
/odata/ReleaseRetention({key})
- 指定したプロセス ポリシーを、既定のポリシー (30 日間の保持 + 削除) にリセットします。
詳しくは、『UiPath Orchestrator API ガイド』をご覧ください。
カスタム保持ポリシーが設定されているプロセスを簡単に特定するには、[プロセス] ページの [列] ドロップダウン リストで [保持期間後のアクション] と [保持期間 (日)] 列のチェックボックスをオンにし、これらの列を有効化します。
[保持期間後のアクション] 列にはポリシーの結果が表示され、[保持期間 (日)] 列にはポリシーが適用されるまでの残り時間が表示されます。
前述のとおり、新しく作成されるプロセスには 30 日間の保持ポリシーが適用されます。ただし、既定のポリシーが設定されているプロセスを識別する際には、保持期間の値を識別基準として常に信頼することはできません。たとえば、カスタム保持期間を 55 日間に設定し、その後期間を 30 日間に更新した場合、更新後のポリシーは既定のポリシーではありません。各シナリオに既定のポリシーが設定されているかどうかを確認するには、[監査] ページをご覧ください。
バックグラウンド ジョブによって保持ポリシーに関連するクリーンアップ操作 (アーカイブと削除、または単なる削除) が実行された場合、対応するエントリが管理者に代わって監査に作成されます。
1 はアーカイブのアクションを表します。0 は削除のアクションを表します。