| Oracle® Fusion MiddlewareOracle Adaptive Access Manager開発者ガイド 11gリリース2 (11.1.2.3.0) E67356-01 |
|
 前 |
 次 |
| Oracle® Fusion MiddlewareOracle Adaptive Access Manager開発者ガイド 11gリリース2 (11.1.2.3.0) E67356-01 |
|
前 |
次 |
この章では、基本フレームワークやデフォルト実装など、OAAMオフラインの全体的なデータ・ローダー・フレームワークについて説明します。デフォルト機能をオーバーライドする方法に関する情報も含まれます。
この章は次の項で構成されています:
このドキュメントは、読者がOAAMオフラインの概念に精通していることを前提としています。
カスタム・ローダーの抽象クラスは、IDM_Homeディレクトリ内のoaam/cli/libフォルダ内にあるoaam_core.jarに格納されています。
自分のカスタム・ローダーをデプロイするには、次の手順に従います。
oracle.oaam.extensions.warファイルをORACLE_MW_HOME/Oracle_IDM1/oaam/oaam_extensions/genericフォルダから抽出します。
WEB-INF/libフォルダに自分のjarファイルを配置します。
oracle.oaam.extensions.warファイルを再びパッケージします。
Oracle WebLogic管理コンソールで、oracle.oaam.extensionsライブラリを更新して再起動し、OAAMオフライン・アプリケーションを再起動します。
カスタム・ローダーが、OAAMサーバー・データベースからトランザクションをロードします。
カスタム・ローダーが必要になるのは、データベース以外のソースからのデータやログイン情報以外のデータが存在する場合、またはOAAMオフライン・タスクで複雑なデータが必要な場合のみです。
OAAMオフラインのカスタム・ローダーは、次の主要部分から構成されます。
ロード可能なオブジェクト
データソース
ローダー
実行モード
ロード可能なオブジェクトは、個々のデータ・レコードを表します。データソースは保存されたデータ・レコード全体を表し、ローダーはこれらのレコードを処理します。実行モードには、ロードと再生の2種類があります。これらの実行モードは、セッション・セットのロードとセッション・セットの実行との違いをカプセル化したものです。
表22-1に、各種のデータ・ローダー・クラスの要約を示します。
表22-1 データ・ローダー・クラス
| クラス | 説明 |
|---|---|
|
RunMode |
RunModeには基本的に、ロードと再生の2種類があります。 ロード実行モードはOAAMオフライン・システムにセッション・セット・データをインポートし、再生実行モードは事前ロードされたセッション・セット・データを処理します。それぞれの実行モードはデータソースとローダーを作成します。実行モードのその他の役割として、自動増分するセッション・セットや一時停止した後で再開される実行セッションのスケジューリングを繰り返し行う場合など、前のジョブが終了した時点からジョブを開始する方法を決定します。
|
|
RiskAnalyzerDataSource |
|
|
AbstractTransactionRecord |
|
|
AbstractRiskAnalyzerLoader |
|
次の疑似コードは、一般的なフレームワーク実行を示しています。
AbstractRiskAnalyzerLoader loader = runMode.buildObjectLoader();
RiskAnalyzerDataSource dataSource = runMode.acquireDataSource();
try{
while (dataSource.hasMoreRecords()) {
AbstractTransactionRecord eachRecord = dataSource.nextRecord();
loader.process(eachRecord);
}
} finally {
dataSource.close();
}
リスク・アナライザのデータ・ローダー・フレームワークのデフォルトの実装は次のとおりです。
ロード・モード: データソースとして任意のデータベースが使用され、ログイン・データが期待されます。また、デバイスのフィンガープリント処理が実行されます。
再生モード: データソースとしてVCRYPT_TRACKER_USERNODE_LOGS表とV_FPRINTS表が使用され、各レコードに対してすべてのアクティブ・モデルが実行されます。
図22-2に、デフォルトのロード実装の要約を示します。
表22-2 デフォルトの実装
| コンポーネント | 説明 |
|---|---|
|
LoadRunMode |
デフォルトの |
|
DatabaseRiskAnalyzerDatasource |
|
|
LoginRecord |
ログイン・レコードには、TrackerAPIUtilクラスでデバイスのフィンガープリント処理用のメソッドをコールする際に必要とされるすべての使用可能なフィールドが含まれます。 |
|
AuthFingerprintLoader |
|
図22-3に、デフォルトの再生実装の要約を示します。
表22-3 デフォルトの再生実装
| コンポーネント | 説明 |
|---|---|
|
PlaybackRunMode |
デフォルトの |
|
UserNodeLogsRiskAnalyzerDatasource |
|
|
LoginRecord |
ログイン・レコードには、 |
|
RunRulesLoader |
|
いくつかのケースでは、デフォルトの動作のオーバーライドが必要になります。データベース以外のソースからデータをロードする場合やシステムにトランザクション・データをロードする場合、デフォルトのロード動作をオーバーライドする必要があります。ルール処理以外の手順を実行する場合は、デフォルトの再生動作をオーバーライドする必要があります。
JDBCデータベース以外のデータソースからログイン・データをロードする場合やトランザクション・データをロードする場合、RiskAnalyzerDataSourceのサブクラスを独自に作成する必要があります。それには2つの方法があり、AbstractJDBCRiskAnalyzerDataSourceを拡張するか、AbstractRiskAnalyzerDataSourceを拡張します。
JDBC接続を介してなんらかのデータをロードしている場合、これは適切な選択肢です。これは、JCBC接続をオープンするためのデフォルトの動作、JDBC結果セットを作成するためのサブクラスを指定したSQL問合せの発行、データベースへのレコード総数のカウントの問合せを含みます。
次の3つの抽象メソッドを実装する必要があります。
buildBaseSelect()。データの読取りに使用するSQL問合せを返します。ORDER BY文は含めないでください。スーパークラスがgetOrderByField()の実装を使用してORDER BY文を追加します。
getOrderByField()。問合せのソート対象のデータベース・フィールドの名前を返します。通常、日付フィールドになります。
buildNextRecord()。JDBC結果セットの1つ以上のレコードをロード可能なデータ・レコードに変換します。
スーパークラスにはprotectedフィールドが用意されており、前述の抽象クラスを実装する際に必要になります。最も重要なメソッドはresultSetで、JDBC結果セットを参照します。hasMoreRecords()をコールしてtrueが返された場合、resultSetが有効な状態にあり、現行のレコードを指していることが保証されます。また、buildNextRecord()を実装する際には、resultSetが有効な状態にあり、現行のレコードを指しているとみなしても問題ありません。
ユーザーが知っておく必要のあるその他のフィールドは接続とコントローラです。接続は、リモート・データベースに対するJDBCを指しています。コントローラはRiskAnalyzerのインスタンスで、現行のOAAMオフライン・ジョブに関するコンテキスト情報を含みます。
デフォルトの動作が要件に合わない場合にオーバーライドできるその他のメソッドは、buildConnection()、buildSelectCountStatement()、getTotalNumberToProcess()およびbuildSelectStatement()です。
リモートJDBC接続のインスタンス化の方法を変更する場合、override buildConnection()を実行します。
読取り対象とするレコードの数をカウントするSQLを変更する場合、buildSelectCountStatement()をオーバーライドします。
読取り対象とするレコードの数を戻すアルゴリズムを置き換えたい場合、getTotalNumberToProcess()をオーバーライドします。これは、buildSelectCountStatement()をオーバーライドしても必要な動作が得られなかった場合にのみ実行します。
最後に、リモート・データベースからレコードを読み取るSQLを変更する場合(ORDER BY句の適用方法の変更など)、buildSelectStatement()をオーバーライドします。
AbstractJDBCRiskAnalyzerDataSourceが適切でない場合は、かわりにAbstractRiskAnalyzerDataSourceを拡張する必要があります。たとえば、バイナリ・ファイルを読み取る場合や、カスタム再生モードのデータソースの実装中にTopLinkを使用してOAAMオフライン・データベースから読取りを行う場合に、その必要があります。
コンストラクタを使用して、データを反復できる状態にクラスを準備しておく必要があります。次の4つの抽象メソッドを実装する必要があります。
getTotalNumberToProcess()。特定のセッション・セット定義の条件を満たす、データソース内のレコードの総数を返します。
hasMoreRecords()。処理が必要なレコードが存在する場合にtrueを返し、必要に応じてレコード・ポインタを次の使用可能なレコードに移動します。シグナル用のnextRecordIsReadyというフラグも存在します。スーパークラスは、次の使用可能なレコードを使用した後でこのフラグをfalseに設定します。hasMoreRecords()の実装は、nextRecordIsReadyフラグの値を確認して、このフラグの値がfalseの場合にのみポインタを次のレコードに移動する必要があります。ポインタが次のレコードに正常に移動した後は、フラグの値をtrueに変更する必要もあります。このパラダイムに従う場合、nextRecordIsReadyがtrueのときにhasMoreRecords()の実装がコールされたときは、どのレコード・ポインタの状態も変更せずにtrueを戻す必要があります。
buildNextRecord()。AbstractTransactionRecordの必須のサブクラスの新しいインスタンスを返します。
close()。すべてのレコードの処理を終了したときにコールされます。必要なクリーンアップ処理は、ここで実行する必要があります。
テキスト・ファイルからのロード
ファイル・ベースのカスタム・ローダーを使用する必要がある場合は、AbstractRiskAnalyzerDataSourceを拡張してカスタム・クラスを実装します。それには、AbstractTextFileRiskAnalyzerDataSourceの動作を確認してそのコードをAbstractTextFileRiskAnalyzerDataSourceからコピーします。
ロード動作または再生動作のカスタマイズされたクラスを作成した場合、AbstractLoadLoginsRunMode、AbstractLoadTransactionsRunModeまたはPlaybackRunModeのカスタマイズされたサブクラスを要件に応じて作成する必要があります。
最も重要なRunModeメソッドはacquireDataSourceとbuildObjectLoaderです。
acquireDataSource(RiskAnalyzer)は、プロセスの実行に必要なRiskAnalyzerDataSourceのインスタンスを返します。RiskAnalyzerパラメータには、RunModeでデータソース・オブジェクトのインスタンス化に使用できるコンテキスト情報が含まれます。
buildObjectLoader(RiskAnalyzer)は、プロセスの実行に必要なAbstractRiskAnalyzerLoaderのインスタンスを返します。RiskAnalyzerパラメータには、RunModeでオブジェクト・ローダーのインスタンス化に使用できるコンテキスト情報が含まれます。
RunModeを実装する際には、オブジェクト・ローダーがデータソースと互換性があることを確認してください。つまり、返されるデータソースによって、オブジェクト・ローダーが期待する特定のタイプのロード可能なオブジェクトが生成されることを確認してください。
chooseStartDateRange(VCryptDataAccessMgr, RunSession)メソッドは、OAAMオフライン・ジョブの開始日範囲を判別するために使用されます。RunModeのすべてのインプリメンタには、このメソッドのデフォルトの実装が含まれます。デフォルトの動作は次のとおりです。ジョブの初回実行時の場合、実行セッションのセッション・セットから開始日(存在する場合)を戻すか、データソース内の最も早い日付よりも確実に早い任意の日付(セッション・セットに開始日が存在しない場合)を返します。再開されたジョブの場合は、実装に従って、ジョブ再開時にどのレコードから処理を開始するかを決めます。
ログイン・データのロード中にカスタム・データソースが必要な場合、これは適切な選択肢です。acquireDataSource(RiskAnalyzer)メソッドを実装して、カスタム・データソースの新しいインスタンスを戻す必要があります。AbstractRiskAnalyzerLoaderのカスタム実装が必要な場合は、この実装を戻すようにbuildObjectLoader(RiskAnalyzer)をオーバーライドできます。
AbstractLoadLoginsRunModeでは、再開時のログイン日付を判別するロジックが次のように実装されます。スーパークラス・メソッドretrieveLowerBoundDateFromQueryは、BharosaDBQueryを戻す抽象メソッドbuildQueryToRetrieveLowerBoundをコールします。このクラスのbuildQueryToRetrieveLowerBoundの実装は、最新のVCryptTrackerUserNodeLog.createTimeを選択します。
必要に応じて、この動作をオーバーライドする必要があります。buildQueryToRetrieveLowerBoundをオーバーライドして、問合せに追加の基準を追加したり、問合せ全体を置き換えることができます。唯一の要件は、問合せが単一の日付型の結果を戻すことです。かわりに、retrieveLowerBoundDateFromQueryやchooseStartDateRangeの各メソッドをオーバーライドして、このアルゴリズムを置き換えたり拡張することもできます。
カスタム・データソースが必要なため、トランザクション・データをロードする場合、これは適切な選択肢です。acquireDataSource(RiskAnalyzer)メソッドを実装して、カスタム・データソースの新しいインスタンスを戻す必要があります。AbstractRiskAnalyzerLoaderのカスタム実装が必要な場合は、この実装を戻すようにbuildObjectLoader(RiskAnalyzer)をオーバーライドできます。
AbstractLoadTransactionsRunModeでは、再開時のログイン日付を判別するロジックが次のように実装されます。スーパークラス・メソッドretrieveLowerBoundDateFromQueryは、BharosaDBQueryを戻す抽象メソッドbuildQueryToRetrieveLowerBoundをコールします。このクラスのbuildQueryToRetrieveLowerBoundの実装は、最新のVTransactionLog.createTimeを選択します。
必要に応じて、この動作をオーバーライドする必要があります。buildQueryToRetrieveLowerBoundをオーバーライドして、問合せに追加の基準を追加したり、問合せ全体を置き換えることができます。唯一の要件は、問合せが単一の日付型の結果を戻すことです。かわりに、retrieveLowerBoundDateFromQueryやchooseStartDateRangeの各メソッドをオーバーライドして、このアルゴリズムを置き換えたり拡張することもできます。
デフォルトの再生データソースまたは処理動作の置換を必要とする要件の場合、これは適切な選択肢です。実装される抽象メソッドはありませんが、スーパークラス・メソッドをオーバーライドして要件を満たすことができます。
カスタム・データソースが必要な場合は、このデータソースを戻すようにacquireDataSource(RiskAnalyzer)をオーバーライドできます。AbstractRiskAnalyzerLoaderのカスタム実装が必要な場合は、この実装を戻すようにbuildObjectLoader(RiskAnalyzer)をオーバーライドできます。
PlaybackRunModeでは、再開時のログイン日付を判別するロジックが次のように実装されます。chooseStartDateRangeメソッドは、次の選択肢から最新の日付を選択します。セッション・セットの開始日(NULLでない場合)、実行セッションの最終処理日(NULLでない場合)、およびデータソース内の最も早い日付よりも確実に早い任意の日付です。3つ目のオプションは、最初の2つがNULLの場合にのみ選択されます。
