Search

データライフサイクルポリシーを使用してパージ（またはアーカイブ）するにはどうすればよいですか？

環境:

インシデントのパージとアーカイブ
Oracle B2C Service, 全てのリリース

解決策:

18Bリリースより前は、構成設定を介してインシデントのアーカイブとパージの設定を使用でき、インターフェイスごとにこの値を設定することもできました。

18Bリリースから、構成機能がデータライフサイクルポリシーフレームワークに移行され、対応する構成設定が削除されました。 サイトに複数のインターフェイスがあり、インシデントアーカイブまたはパージがインターフェイスごとに異なるように構成されている場合、18B以降へのサイト更新後に、サイト固有および複数インターフェイス固有のインシデントのデータライフサイクルサイクルポリシーが作成されます。 インシデントアーカイブとパージの構成値は、サイト更新中に適切なデータライフサイクルポリシーにコピーされます。 この機能のドキュメントはこちらから入手できます。

18Bでは、Data Lifecycle Managementフレームワークを使用して、インターフェース固有のインシデントアーカイブを作成したり、ポリシーをパージしたりすることはできません。 ただし、18Cからは、インシデントのカスタムデータライフサイクルポリシーを作成し、ビジネスニーズに合わせてアーカイブ/パージを行うことができます。

データライフサイクルポリシーのフィルター条件の構成に使用されるすべてのフィールドは、単一のインデックスの一部としてインデックスを作成する必要があります。 Object Designerを使用して、最大4つのカスタム属性のインデックスを作成できます。 ただし、標準フィールドとカスタム属性を組み合わせてインデックスを作成し、その結果、標準フィールドとカスタム属性の組み合わせを使用してデータライフサイクルポリシーのフィルター条件を構成することはできません。 カスタムフィールドは、データライフサイクル管理フレームワークでもサポートされていません。

注：ポリシーを作成するには、フィルターテンプレートから開始する必要があります。これらのフィールドは、インデックス付きフィールドに関連付けられたカスタムサブオブジェクトがある場合（詳細は以下）、または次の標準インシデントフィルターテンプレートのいずれかを使用している場合にのみ存在します ：

インシデントオブジェクトの次の標準インデックスは、データライフサイクルポリシーの作成中に使用できます:

1. インターフェース、ステータス、クローズ
2. ステータス、クローズ

データディクショナリを見ると、これらがインシデントテーブルにどのように一致するかを確認できます。 そこにあるインデックスには、これら2つが含まれています。 インシデントテーブルには他のインデックスがありますが、これらは標準のフィルターテンプレートに使用される2つだけであることに注意してください。

インデックスの最初のフィールドまたはそのフィールドの最初の文字を使用して、フィルターテンプレートを検索できます。

たとえば、インシデントが閉じられてから「X」（固定）日後に特定のインターフェースのすべての「クローズ」ステータスインシデントをパージするポリシーを作成する場合、インターフェース、ステータスで構成されるフィルターテンプレートを使用できます そして、最初のフィールド、すなわち「インターフェース」を持つフィルターテンプレートを検索することにより閉じられます。 すべてのインターフェースに共通のポリシーが必要な場合は、ステータスおよびクローズフィールドを使用して標準ポリシーを編集し、「s」または「ステータス」で検索できます。

カスタム属性を使用すると、カスタムデータライフサイクルポリシーの真の可能性を実現できます。 カスタムデータライフサイクルポリシーでフィルターとしてカスタム属性を使用するには、オブジェクトデザイナーを介してデータライフサイクルポリシーでフィルターとして使用する必要があるすべての必要なカスタム属性を含むインデックスを作成する必要があります。 インデックスが使用可能になってデプロイされると、インデックスの最初のフィールドをキーとして使用して同じカスタム属性のセットで構成されるフィルターテンプレートを検索し、フィルターテンプレートを検索してそれを使用して新しいカスタムポリシーを作成できます 。 インデックスの最初のフィールドの検索が機能しない場合は、オブジェクトデザイナ内で定義されているそのフィールドの説明を検索します。

たとえば、連絡先が最後に連絡した日付フィールドを含む連絡先オブジェクトに作成された「lastContacted」日付データ型カスタム属性があり、最後の連絡が1年以上古い連絡先を削除する場合。 「lastContacted」をフィルターとして使用して、連絡先オブジェクトにカスタムデータライフサイクルポリシーを作成することで、連絡先の削除を自動化できます。 データライフサイクルポリシーワークスペースでフィルターテンプレートとして使用可能になる前に、最初にオブジェクトデザイナーを使用して「lastContacted」カスタム属性にインデックスを作成して展開する必要があることに注意してください。

データライフサイクルポリシーを有効にすると、存在し続け、無期限に実行されます。 パージされたデータは回復できません。 そのため、ビジネスはデータを削除する必要がないという正確な確認と検証の後にのみポリシーを有効にします。

よくある質問：

Q)  データライフサイクルポリシーを有効にすると、運用のパフォーマンスに影響しますか？

はい。 サイト上の他のデータと同様に、削除する前に対象となるデータの量を特定することは常にベストプラクティスです。 これらのレコードを効率的に削除するためのコードが記述されていますが、大規模なデータセットは依然として望ましくないテーブルロックとタイムアウトを引き起こす可能性があります。 したがって、データの大部分（トランザクションなど）を削除する場合は、バッチで削除することをお勧めします。

例：

デフォルトのトランザクションポリシーは、6か月より古いトランザクションをパージします。 その期間がサイトの数百万件のレコードを構成している場合は、「作成日」に追加の演算子を追加して、ターゲットデータセットを削減する必要があります。 6か月未満はエントリを変更できませんが、目的の保持ポリシーを達成するためにエントリを追加することはできます。

Q)  パージはすぐに開始されますか？もしその場合、ピーク時間外にこの構成を編集することをお勧めしますか？

データライフサイクルポリシーの実行は定期的に実行されるようにスケジュールされているため、パージ（またはアーカイブ）がいつ開始されるかは決定できません。 すぐに起動するという前提で設定することをお勧めします。

Q)  データライフサイクルポリシーの進捗を監視する方法はありますか？

データライフサイクルポリシーの実行を監視する明示的な方法はありません。 ただし、deleted_recsをチェックして、ソースレベルを参照として使用して、Data Lifecycle Management（DLM）を介してレコードがパージされているかどうかを確認できます。

Q)  トランザクションを6か月以上経過させたい場合、トランザクションをパージするためのカスタム期間を追加するにはどうすればよいですか？

既定のDLMポリシー用に作成された既定の条件には、2つのタイプがあります。 1つのケースでは、それらをまったく編集できません（たとえば、少なくとも6か月以上前のトランザクションパージ期間）。 その他の場合、値のみを編集できます（例：標準ポリシーのインシデントアーカイブ/パージ期間の値）。

期間値を増やしてトランザクションを6か月以上パージするには、追加の条件を作成できます。 たとえば、10か月以上前のトランザクションレコードを削除するフィルター条件を作成できます。

6か月未満のカスタムフィルター値を指定した場合、パージを6か月以上に制限する標準フィルターが存在するため、有効にならないことに注意してください。

Q)  データライフサイクルポリシーが自動的に無効になったのはなぜですか？

データライフサイクルポリシーの作成時に設定されたフィルター条件が実行時に当てはまらない場合、システムはデータライフサイクルポリシーを無効にします。 例えば カスタムポリシーの作成と展開後、連絡先オブジェクトの「lastContacted」フィールドで作成されたカスタムインデックスを削除した場合、または無効なフィルターのために条件が検証されない場合、カスタムポリシーはポリシーの実行時に自動的に無効になります。

Q)  標準オブジェクト（連絡先、インシデント、またはトランザクション）の新しいポリシーを設定するにはどうすればよいですか？

アンサーID11055: 標準オブジェクトのデータライフサイクルポリシーの作成

Q)  カスタムオブジェクトの新しいポリシーを設定するにはどうすればよいですか？

Q) データライフサイクルポリシーへのアクセスを設定するにはどうすればよいですか？

Q) データライフサイクル管理の標準ポリシーが有効になっているかどうかを知る方法は？