入力エージェントは、ドキュメントを一括でImagingにアップロードし、索引を作成するために使用されるImagingサービスです。
入力エージェントは、アプリケーション定義、入力定義、および入力ファイルと呼ばれる特殊な形式のテキスト・ファイルを使用して、Imagingドキュメントの索引を一括で作成します。入力ファイルでは、索引を作成するイメージとアプリケーション内でそれらに関連付けるメタデータのリストを指定します。入力エージェントはマルチスレッドで、大量のデータを処理するようにも少量のデータを処理するようにも構成可能です。
入力エージェントを構成する手順は次のとおりです。
注意:
入力ファイルを処理するには、入力エージェントが入力ディレクトリに対して適切な権限を持っている必要があります。また、入力ディレクトリでファイル・ロックが許可されている必要があります。入力エージェントを使用するには、WebLogic Serverサービスを実行するユーザー・アカウントが、入力ディレクトリと入力ディレクトリ内のすべてのファイルおよびサブディレクトリに対して読取りと書込みの権限を持っている必要があります。これらの権限は、入力エージェントがファイルを処理する際に様々なディレクトリへファイルを移動できるようにするために必要です。共有におけるファイル・ロックは、入力エージェントがクラスタのサーバー間で処理を調整するために必要です。
前述の手順を完了すると、入力エージェントがアクティブになり、処理を開始できる状態になります。アプリケーション(「アプリケーションの作成」を参照)と入力定義(「入力定義の作成」を参照)を作成すると、入力エージェントはジョブの処理を開始します。
入力エージェントは、入力ファイルに基づいて処理を行います。入力ファイルは、CSV(カンマ区切りの値)ファイルのような簡単なテキスト・ドキュメントで、Imagingシステムで索引を作成するためのファイルおよび関連するメタデータのリストが格納されています。正しいエンコーディングが入力定義で指定されていれば、入力ファイルでは様々なエンコーディングを使用できます。入力エージェントは、入力定義の定義に使用されるサンプル・ファイルではなく、入力定義の入力マスクと一致するすべての入力ファイルを検索します。APIを使用して入力を作成する場合、サンプル・ファイルは必要ありません。サンプル・ファイルは、ユーザーがデータを表示して列を選択できるようにユーザー・インタフェースを使用して入力を作成する場合にのみ使用します。
警告:
入力ファイル・マスクはImagingシステムに対して一意である必要があり、重複することはできません。入力エージェントでは1つの入力に対する1つの入力ファイルのみを処理し、異なる入力定義用に、ファイルを再ステージングして再度処理することはありません。入力が処理される順序はランダムであるため、ある共有入力ファイルがどの入力によって選択されるかは予測できません。
入力ファイルの例は次のとおりです。
C:\IPMData\Input Files\print\NewPrintstreams\doc16.txt|NEW ORDER|10/06/94|B82L|218482 C:\IPMData\Input Files\print\NewPrintstreams\doc17.txt|NEW ORDER|10/06/94|N71H|007124 C:\IPMData\Input Files\print\NewPrintstreams\doc18.txt|NEW ORDER|10/06/94|B83W|24710
入力ファイルの詳細な構造は、次のように定義されます。
[path to document file][delimiter][metadata value 1]<[delimiter]<metadata value 2> ... <delimiter>>
大カッコ([])内の項目は必須で、山カッコ(<>)内の項目はオプションです。
path to document file
は、Imagingに保存されるtiff、jpeg、docまたはその他のファイル・タイプの場所です。入力エージェントを実行するユーザー・アカウントがアクセス可能なパスである必要があります。
delimiter
は、パイプ文字(|)など、値を相互に区切る文字です。
metadata value x
は、ドキュメントの索引を作成するためにアプリケーションで使用される索引値です。
デリミタ文字は入力ファイル全体で同じ文字であり、入力定義で指定されている文字と一致している必要があります。デフォルトはパイプ文字(|)です。
アプリケーション内の必須フィールドごとにメタデータ値が1つずつ必要です。たとえば、「名前」フィールドと「日付」フィールドの両方がアプリケーションで「必須」として指定されている場合、入力ファイルにも「名前」フィールドと「日付」フィールド両方の値が必要です。追加の値を指定することもできますが、その場合は、[delimiter]<metadata value>という形式に従う必要があります。
各行に長さの制限はありませんが、改行文字は新しいドキュメントの開始を示すため、ファイルに関連するすべてのメタデータを1行に入力する必要があります。
各値は、デリミタで区切ります。区切られた値は、入力エージェントでは列1...列Nとして処理されます。行に対するコマンドは、列としてカウントされません。「入力ファイリング・コマンドの使用」を参照してください。
入力ファイル内の列がアプリケーションの順序と一致している必要はありませんが、索引を正しく作成するには、入力定義で指定された場所にある必要があります。
注意:
入力ファイルで指定されている日付および時刻には、指定された日付に適用されている夏時間(DST)ルールではなく、現在のDSTルールが適用されます。そのため、ドキュメントのタイムスタンプが最大で前後2時間変更されることがあります。タイムスタンプが深夜をまたいで変更される場合、ドキュメント入力に使用されている日付も変更されることがあります。
入力エージェントでは、入力ファイルに特殊なコマンド・シーケンスを挿入することで、ファイリング・プロセスをより詳細に制御できます。入力定義はすべてのファイルに適用されますが、コマンドは、入力エージェントによって必要に応じて入力ファイルに挿入でき、ファイルごとに異なっていてもかまいません。そのため、日付書式や数値の表示を変更するためのファイルのロケールなど、ファイルごとに固有の動作を柔軟に設定できます。
これらのコマンドでは、コマンドに応じて、入力ファイル全体を処理することも、ファイルの1つの行のみを処理することもできます。個々のコマンドの詳細は次のとおりです。
ロケール・コマンドは、エージェントがデータの解析に使用するロケールを変更します。このコマンドは、ドキュメントを指定する前に、入力ファイルの先頭で1回のみ使用できます。データが処理された後でこのコマンドが使用されると、エラーが発生し、ファイリングが停止します。
構文
@Locale[delimiter][locale]
例
@Locale|es-es
注意
このコマンドは入力ファイルの先頭でのみ使用でき、ファイル全体に適用されます。複数のロケールを使用する必要がある場合は、異なるファイルにデータを分割する必要があります。デリミタは、入力ファイル全体で使用されているものと同じである必要があります。ロケールは、ISO言語コード-ISO国コードという形式に従います。
新規コマンドはImagingシステムで新しいドキュメントを作成し、行の索引データをそのまま残すように動作します。このコマンドは、注釈が付けられた行にのみ適用され、次の行ではリセットされます。
構文
@New[delimiter][line data]
line data: 通常の入力ファイルにあるようなドキュメントのメタデータ値です。
例
@New|TestTiff.TIF|98.765|Good Company LTD|10/08/2003|0000|1.733,12|10/09/2003
注意
行の先頭の@Newは、マップされる列の1つとしてカウントされません。
サポートするコンテンツ・コマンドを使用すると、新しいドキュメントを作成するかわりに、サポートするコンテンツとしてファイルをドキュメントに適用できます。明示的なドキュメントIDがコマンドで指定されていない場合、入力ファイル内の最後の新しいドキュメント行にコンテンツが適用されます。最後の新しいドキュメントが索引の作成に失敗した場合、コンテンツを追加する対象のドキュメントが存在しないため、サポートするコンテンツ・コマンドも失敗します。
構文
@Support[delimiter][key][delimiter][content path]<[delimiter][document id]>
key: ファイルが格納される、サポートするコンテンツ・キーです。ドキュメントで一意である必要があります。
content path: サポートするコンテンツとして保存するファイルのパスです。
document id(オプション): サポートするコンテンツを適用するImagingドキュメントのIDです。この値が指定されている場合、前の新しいドキュメントは無視され、指定されたドキュメントIDにサポートするコンテンツが配置されます。
例
@Support|supporting content key 1|C:\temp\sample.tif
注釈の適用コマンドは、事前に生成された注釈ファイルをドキュメントに適用します。明示的なドキュメントIDがコマンドで指定されていない場合、入力ファイル内の最後の新しいドキュメント行に注釈が適用されます。最後の新しいドキュメントが索引の作成に失敗した場合、注釈を適用する対象のドキュメントが存在しないため、注釈の適用コマンドも失敗します。
複数の注釈コマンドは相互を上書きし、累積されません。
注意:
入力エージェントを使用して新規ドキュメントをImagingにアップロードする場合のみ、このコマンドを使用して注釈を適用します。ドキュメントに関連付けられた既存の注釈を上書きしてしまうため、既存のドキュメントに注釈を適用するためにこのコマンドを使用することはお薦めしません。
構文
@Annotation[delimiter][file path]<[delimiter][document id]>
file path: ドキュメントに適用する注釈ファイルのパスです。
document id(オプション): 注釈を適用するImagingドキュメントのIDです。この値が指定されている場合、前の新しいドキュメントは無視され、指定されたドキュメントIDにサポートするコンテンツが配置されます。
例
@Annotation|C:\temp\annot.xml
この項では、入力エージェントが入力ファイルをどのように処理するかについて説明します。
構成MBeanで指定された入力ディレクトリは、ディレクトリ構造の最上位です。入力エージェントは処理を行うために、最上位の入力ディレクトリの下に、次の構造で他のディレクトリを作成して管理します。ディレクトリ定義は、次のファイル構造に従います。
Input - Errors – Holding – Processed — YYYY-MM-DD – Samples – Stage
ディレクトリ | 定義 |
---|---|
Input |
これは、構成MBeanで定義された最上位のディレクトリです。入力エージェントは、新しい入力ファイルをここで検索します。MBeanで複数の入力ディレクトリが定義されている場合があります。MBeanの各エントリで、その下にこれと同じ構造が作成されます。 |
Errors |
正常に作成された索引と索引の作成試行の失敗が入力ファイルに混在している場合、そのファイリングのエラー・ファイルがこのディレクトリに作成されます。 |
Holding |
CleanupExpireDaysおよびCleanupFileExclusionList MBeanが有効な場合、Holdingディレクトリには、注釈およびサポートするコンテンツ・ファイルとともに、正常に処理されたファイルが保存されます。イメージは、CleanupExpireDays設定に指定された日数が経過するまでそこに残されます。これ以降、ファイルおよびバッチ・フォルダは削除されます。削除しないファイルについては、正確なファイル名を使用してCleanupFileExclusionList設定に指定してください。 |
YYYY-MM-DD |
これらのディレクトリは、処理された日付で入力ファイルを編成する、年-月-日(2009-04-01など)という形式の日付値です。これは、ファイルが処理された日付を示し、1つのディレクトリに格納されるファイルが多くなりすぎるのを防ぎます。 |
Processed |
このディレクトリのファイルは、ファイリング・プロセス中に解析されています。処理中にエラーが発生した場合は、エラー・ファイルがErrorsディレクトリに格納され、Imagingシステムでドキュメントが作成されなくても、元のファイルがProcessedディレクトリに格納されます。 |
Samples |
このディレクトリには、ユーザー・インタフェースで入力オブジェクトを操作するすべてのサンプル・ファイルが格納されます。このディレクトリ内のファイルはユーザー・インタフェースの入力ウィザードに表示され、本番データを格納することはできません。Samplesディレクトリの場所は、入力ディレクトリとは別に構成され、入力ディレクトリ下でなくてもかまいません。 |
Stage |
このディレクトリ内のファイルは処理対象として選択されており、エージェントによる処理中です。ファイリングが完了すると、ファイルはProcessedディレクトリに移動します。処理が失敗すると、エラー・レポートが生成されます。 |
入力エージェントは入力ファイルをポーリングし、ステージングして、処理可能なファイルがあるというメッセージをJMSキューにポストします。入力インジェスタはJMSキューをリスニングし、ステージングされたファイルの処理を開始します。各イベントの順序は次のとおりです。
処理のためにステージングされたファイルがJMSキューにあることが通知されると、入力インジェスタがファイルの処理を開始します。
ワーク・マネージャは、多数のスレッドを1つのプロセスに割り当てる方法を制御するためのOracle WebLogic Serverの概念です。Imagingでは、多数のスレッドを入力エージェントに割り当てる方法を制御し、システムに対する負荷を増減するために使用されます。新規インストール時には、10個のスレッドが入力エージェントに割り当てられます。WebLogic Serverワーク・マネージャのInputAgentMaxThreadsConstraintのデフォルト設定(10)をシステム・ニーズに合わせて変更することで、Oracle WebLogic Serverが入力エージェントに提供するスレッドの数を再構成できます。1台のマシンで遅延が発生してバックログが生成されることがないように、すべてのシステムでスレッドの最大数を同等に調整する必要があります。値-1または0を指定すると、制約は無効になります。1より大きい値を指定すると、スレッドの数が指定した数に制限されます。
スレッドの設定を更新するには、WebLogic Server管理コンソールで次の手順を実行します。WebLogic Serverの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の管理』を参照してください。
入力エージェントには再試行メカニズムが備わっており、リカバリ可能なエラーが発生した場合には入力ファイルの処理を再試行できます。このようなエラーの例としては、リポジトリがまだ使用可能でないときに初期化を完了する必要がある場合などがあります。リカバリ可能なエラーが入力エージェントで検出された場合、ファイリングが再度JMSキューに配置されます。このキューには、入力ファイルがすぐに再処理されないようにするための構成可能な再試行の待機タイマーがあります。また、InputAgentRetryCount MBeanを設定して、ジョブを再試行できる回数を制御することもできます。デフォルトは3です。4回目以降、ジョブは失敗ディレクトリに配置されます。
入力ファイルのエラーをトラブルシューティングする手順は次のとおりです。