この章では、次のように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
のサブクラスを独自に作成する必要があります。これには、AbstractJDBCRiskAnalyzerDataSource
の拡張、AbstractTextFile-RiskAnalyzerDataSource
の拡張またはAbstractRiskAnalyzerDataSource
の拡張という3つの方法があります。
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()
をオーバーライドします。
テキスト・ファイルからのデータをロードしている場合、これは適切な選択肢です。これは、ファイルをオープンするためのデフォルトの動作、日付がセッション・セット範囲の開始位置の日付以降である(ファイル内の)最初の行へのスキップ、日付がセッション・セット範囲の終了位置の日付より後である行に到達した際の停止を含みます。このスキームが動作するには、入力ファイルを日付でソートする必要があります。次の2つの抽象メソッドを実装する必要があります。
dateOfCurrentRecord()
。現行レコードの日付を知らせます。このメソッドをコールした場合、currentLine
フィールドが有効で、ファイルの現在の行を含んでいることが保証されます。
buildNextRecord()
。ファイルの1つ以上の行をロード可能なデータ・レコードに変換します。
入力ファイルに無視する必要がある行が含まれる場合、メソッドに渡されたテキストを調べて、スキップする必要がある行でtrueを戻すように、lineIsBad()
メソッドをオーバーライドできます。
スーパークラスにはprotectedフィールドが用意されており、前述の抽象クラスを実装する際に必要になります。最も重要な2つのメソッドは、ファイルで最後に読み取られた行を参照するcurrentLine
と、ファイルの文字ストリームでありcurrentLine
の次の行(存在する場合)でポイントされるreader(java.io.BufferedReader
)です。hasMoreRecords()
をコールしてtrueが返された場合、currentLine
がNULLではなく、セッション・セットの範囲内にあることが保証されます。
ユーザーが知っておく必要のある別のフィールドはコントローラです。コントローラはRiskAnalyzer
のインスタンスで、現行のOAAMオフライン・ジョブに関するコンテキスト情報を含みます。
デフォルトの動作が要件に合わない場合にオーバーライドできるその他のメソッドは、getTotalNumberToProcess()
、isBeforeBeginning()
、isAfterEnd()
およびskipToBeginning()
です。
getTotalNumberToProcess()
のデフォルトの実装では、ユーザーが、処理するレコードの数を知らないことを想定しているため、無効な値の定数(N/Aを表す)を返します。ご使用の実装で、処理するレコードの数を判別する方法がある場合は、このメソッドを所定のアルゴリズムに従ってオーバーライドできます。
isBeforeBeginning()
のデフォルトの実装は、dateOfCurrentRecord()
によって返される日付がコントローラの開始日範囲より前の場合にtrueを返します。これを別の方法で実行する必要がある場合は、このメソッドをオーバーライドできます。ファイルは、比較対象となるフィールド(複数も可能)でソートしてください。
isAfterEnd()
のデフォルトの実装は、dateOfCurrentRecord()
によって返される日付がコントローラの終了日範囲より後の場合にtrueを返します。これを別の方法で実行する必要がある場合は、このメソッドをオーバーライドできます。ファイルは、比較対象となるフィールド(複数も可能)でソートしてください。この動作をオフにする場合は、このメソッドが定数値falseを戻すようにオーバーライドできます。
skipToBeginning()
のデフォルトの実装は、isBeforeBeginning()
によってfalseが返されるレコードが見つかるまでファイル内を反復します。この動作をオフにする場合は、このメソッドの本体が空になるようにオーバーライドできます。このメソッドが次のレコードにスキップする際のデフォルトの動作は、ロード可能なレコードをいったん作成しておきながら、破棄してしまうというものです。この手順は、ファイルの複数の行から単一のロード可能なレコードを作成する場合は必須です。それらの行が一度にスキップされたことを確認する必要があるからです。行とロード可能なレコードが1対1で対応していることが確かな場合は、このメソッドを次のより効率的なバージョンに置き換えることができます。nextRecordIsReady
変数は、次の行にスキップする必要があるかどうかを判別するためにhasMoreRecords()
が確認するフラグです。skiptoBeginning()
をどのようにオーバーライドする場合でも、hasMoreRecords()
をコールする前に初期化フラグをtrueに設定する必要があります。無限ループを回避するためです。
protected void skipToBeginning() throws Exception { initialized = true; while (hasMoreRecords() && isBeforeBeginning()) { nextRecordIsReady = false; } }
AbstractJDBCRiskAnalyzerDataSource
またはAbstractTextFile-RiskAnalyzerDataSource
のどちらも適切でない場合は、かわりにAbstractRiskAnalyzerDataSource
を拡張する必要があります。バイナリ・ファイルを読み取る場合や、カスタム再生モードのデータソースの実装中にTopLinkを使用してOAAMオフライン・データベースから読み取る場合、この状況になることがあります。
コンストラクタを使用して、データを反復できる状態にクラスを準備しておく必要があります。次の4つの抽象メソッドを実装する必要があります。
getTotalNumberToProcess()
。特定のセッション・セット定義の条件を満たす、データソース内のレコードの総数を返します。
hasMoreRecords()
。処理が必要なレコードが存在する場合にtrueを返し、必要に応じてレコード・ポインタを次の使用可能なレコードに移動します。シグナル用のnextRecordIsReady
というフラグも存在します。スーパークラスは、次の使用可能なレコードを使用した後でこのフラグをfalseに設定します。hasMoreRecords()
の実装は、nextRecordIsReady
フラグの値を確認して、このフラグの値がfalseの場合にのみポインタを次のレコードに移動する必要があります。ポインタが次のレコードに正常に移動した後は、フラグの値をtrueに変更する必要もあります。このパラダイムに従う場合、nextRecordIsReady
がtrueのときにhasMoreRecords()
の実装がコールされたときは、どのレコード・ポインタの状態も変更せずにtrueを戻す必要があります。
buildNextRecord()
。AbstractTransactionRecord
の必須のサブクラスの新しいインスタンスを返します。
close()
。すべてのレコードの処理を終了したときにコールされます。必要なクリーンアップ処理は、ここで実行する必要があります。
ロード動作または再生動作のカスタマイズされたクラスを作成した場合、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の場合にのみ選択されます。