このトピックでは、Case Managementアプリケーションで使用される主要な概念について説明します。ここで取り上げる用語は次のとおりです。
アラートは、Case Managementで使用されるレビュー作業の最小単位です。アラートは通常、異なるデータ・ソースの2つのレコード間のマッチ可能性を表します。アラートの内容は、アラート・キーで定義されます。
複数のアラートがまとめてグループ化されてケースが形成されます。アラートには、現在の状態や権限など、時間の経過に従ってその値が変化する複数の属性があります。アラートには拡張属性もあります（システムに対して構成されている場合）。
アラート・キーはケース・ソースに定義され、関係をまとめてグループ化してアラートを形成する方法を指定します。1つのアラートは、各アラート・キー・フィールドの値が同じである一連の関係で構成されます。
ケース・ソースに含まれる各データ・ソースは通常、そのデータ・ソースの行を一意に識別するのに十分なフィールドをアラート・キーに対して提供します。
属性は、すべてのケースおよびアラートに存在するフィールドです。属性に格納されるデータは、マッチ・プロセスから導出される場合がありますが、マッチ・プロセスに発行されたデータを直接反映することはありません。
属性値は、受入ルールによって実行される処理の一環として設定できます。また、受入ルールでは、その条件処理の一環として属性値が検査されます。
属性値は、遷移の結果として、または状態が期限切れになると変更される場合もあります。
ケースは、関連するアラートのグループです。ケースの内容は、ケース・キーで定義されます。
ケース・キーはケース・ソースに定義され、アラートをまとめてグループ化してケースを形成する方法を指定します。ケースは関連するアラートのグループであるため、ケース・キーは通常、アラート・キーのフィールドのサブセットから形成されます。多くの場合、適切なケース・キーによって作業データから単一の行が識別されます。この場合、1つのケースは単一の作業データ行と関連付けられ、その行と参照データ・ソースのマッチにより生成されるすべてのアラートがそのケースに格納されます。
ケース・ソースは、Case Managementを使用するすべてのマッチ・プロセッサに対して定義する必要があります。ケース・ソースは、マッチ・プロセッサによって生成される関係を使用して、ケースおよびアラートを作成する方法を制御します。
ケース・ソースは次の内容を定義します。
ケース・ソースは、このプロセッサから生成されるケースおよびアラートに使用するワークフローも指定します。
ケース・ソースは、Case Managementを使用しているマッチ・プロセッサの「Advanced Options」ダイアログで定義します。詳細は、「マッチ・プロセッサの詳細オプション」を参照してください。
データ・ソースは、ケース・ソースによって想定される入力データ・ストリームのモデルです。データ・ソースは、Case Management内部の実際の入力データのモデルとして使用されます。このモデルは、ケースおよびアラートを生成するプロセスによって認識されます。ケース・キー、アラート・キーおよびフラグ・キーは、実際の入力データ・ストリームのフィールドではなく、データ・ソースのフィールドに関して定義されます。
データ・ソースの使用により、入力データ・ストリームの不明瞭なフィールド名をより一貫性のある判読可能な名称に再パースできる場合があります。また、データ・ソースの使用は、他のマッチ・プロセッサでケース・ソースを再使用できることを意味します（ケース・ソースにすでに定義されているデータ・ソースに入力データ・ストリームをマップできる場合）。
拡張属性は、ケースおよびアラートに存在するカスタム・フィールドです。これらは、属性と同じ方法で移入されて処理されますが、定義方法と格納方法は異なります。
属性はケースおよびアラート構造の本質的な部分であるのに対し、拡張属性は..\config\casemanagementディレクトリにあるflags.xml構成ファイルに定義されています。
デフォルトのインストールでは、次の2つの拡張属性が定義されています。
フラグ・キーはケース・ソースに定義され、ケース・キーまたはアラート・キーに含まれないが、その内容がマッチ判定にとって重要であると考えられるデータ・フィールドを指定します。つまり、これらのフィールドの情報は、レビュー担当者によるこのアラートが完全一致か擬陽性かどうかの判定に影響を与える可能性があります。この情報を変更すると、マッチ・プロセスの次回実行時に、アラートの再レビューがトリガーされます。
マッチ判定に関係しないフィールドがフラグ・キーに含まれている場合は、実際には追加レビューが必要ないアラートが再度作成されるため、レビュー担当者の負担が増えます。一方、フラグ・キーに含める必要があるフラグが省略されている場合は、データに対する重要な変更を見逃す可能性があります。したがって、フラグ・キーの設計は、スクリーニング・ソリューションの継続的な精度にとって重要です。
パラメータは、ワークフローの一部として定義されます。パラメータはマッチ・プロセッサによって移入され、ケースおよびアラート生成メカニズムへの追加情報の受渡しに使用されます。そのケースおよびアラートに対するパラメータ値の計算方法は、ケース・ソースによって指定されます。詳細は、「ワークフロー・パラメータの移入」を参照してください。
|
注意: パラメータ値は、ケースおよびアラートに自動的にコピーされません。かわりに、ワークフローにも定義されている受入ルールによって、パラメータ値の使用方法が指定されます。 |
Case Managementの権限は、EDQユーザー権限の拡張機能です。権限は、どのユーザーがどのデータにアクセスできるかを制御するために使用されます。
権限はCase Managementの管理で定義され、ケース・ソース、状態および遷移と関連付けられます。権限は、EDQの他のセキュリティと同様に、グループを介してユーザーに割り当てられます。ユーザーに権限を割り当てる方法の詳細は、「ユーザー権限の設定」トピックを参照してください。
ユーザーは各自の権限と互換性のある権限設定を使用することによってのみデータを参照できます。ケースまたはアラートに遷移を適用できるのは、そのための適切な権限があるユーザーのみです。ユーザーに付与されていない権限設定をケース・ソースに割り当てることにより、データ・セット全体をそのユーザーのグループに対して非表示にできます。
受入ルールは、新しいケースまたはアラートが最初にワークフローに入ったときの処理方法を定義するために使用されます。受入ルールは、アプリケーションにとって受信イベントとみなされる一連のアクションで構成されます。各アクションでは、ケースまたはアラートごとに評価される条件式を指定できます。アクションがそのアラートに適用されるのは、式がtrueと評価された場合のみです。
アクションでは、属性および拡張属性に対する新しい値を指定でき、受信ケースまたはアラートに適用する遷移も指定できます。
状態は、遷移とともに、ワークフローの基本要素です。アラートまたはケースの状態は、ワークフロー内でのそれぞれの位置を示します。各状態には、その状態からの有効な遷移が定義されます。
状態は、自動的に期限切れにして、新しい状態に遷移したり、その属性または拡張属性の値に変更されるように構成することもできます。
遷移は、ケースまたはアラートが新しい状態に入る方法を定義します。遷移は、ケースまたはアラートの新しい状態に加えて、同時に発生する属性または拡張属性の値に対する変更を指定します。遷移と状態の関連付けは、ケースまたはアラートがその状態から遷移に指定された状態に移動可能であることを意味します。ケースまたはアラートは、その状態に割り当てられた遷移の1つに従うことによってのみ、現在の状態から移動できます。
遷移が指定するのは、ケースまたはアラートの新しい状態のみであるため、ワークフロー内で繰り返して再使用できます。たとえば、「toSecondLevelReview」という遷移により、ケースまたはアラートの「SecondLevelReview」という状態への移動を指定したとします。この遷移は「FirstLevelReview」および「AwaitingMoreInformation」という状態に関連付けることができます。この関連付けは、ケースおよびイシューが他の2つの状態からSecondLevelReview状態に移動可能であることを意味します。
|
注意: 遷移は単方向です。つまり、ケースまたはアラートが状態Aから状態Bに移動可能であるという事実は、状態Bから状態Aに移動可能であることを意味しません。また、遷移は、ケースまたはアラートの開始ステータスを認識しません。つまり、ケースまたはアラートを状態Bに移動する遷移は、ワークフロー内のその他の状態から実行される可能性があります。 |
遷移にはコメントの追加が必要な場合もあります。各遷移にコメント・テンプレートを定義して、頻繁に使用される理由（フレーズ）を適用できます。
ワークフローは、遷移によってリンクされた一連の状態で構成されます。これらが一緒になって、有効なケースまたはアラートのライフサイクルを表すネットワークが形成されます。
ワークフローでは、マッチ・プロセッサからの追加情報を提供するパラメータ、および新しいケースまたはアラートの初回作成時に実行する処理を指定する受入ルールも定義できます。
ケース・ソースは、2つのワークフロー（アラート用に1つ、およびケース用に1つ）を使用するように構成されています。
Case Managementでは、デフォルトの2つのワークフロー（アラート用に1つ、およびケース用に1つ）が提供されます。追加のワークフローは、Case Managementの管理アプリケーションで定義できます。
Oracle (R) Enterprise Data Qualityオンライン・ヘルプ バージョン8.1
Copyright (C) 2006,2011 Oracle and/or its affiliates.All rights reserved.