| Oracle® WebCenter Content Imaging管理者ガイド 11g リリース1(11.1.1) B72420-01 |
|
 前 |
 次 |
入力エージェントは、ドキュメントを一括でImagingにアップロードし、索引を作成するために使用されるImagingサービスです。この項では、Imagingで入力エージェントを有効にし、一括アップロードの入力ファイルを作成する方法について説明します。
この項の内容は次のとおりです。
入力エージェントは、アプリケーション定義、入力定義、および入力ファイルと呼ばれる特殊な形式のテキスト・ファイルを使用して、Imagingドキュメントの索引を一括で作成します。入力ファイルでは、索引を作成するイメージとアプリケーション内でそれらに関連付けるメタデータのリストを指定します。入力エージェントはマルチスレッドで、大量のデータを処理するようにも少量のデータを処理するようにも構成可能です。
入力エージェントを構成する手順は次のとおりです。
管理対象サーバーを起動し、WLSTまたはEnterprise ManagerのMBeanブラウザを使用してImaging構成MBeanに移動します。
CheckIntervalを、環境に適した値に設定します。CheckInterval MBeanは、実行する新しい処理を確認するまでの休止時間(分)を指定するシステム設定です。デフォルトは15分です。
InputAgentRetryCountを設定して、ジョブが失敗した後で実行可能な再試行の回数を制御します。デフォルトは3です。4回目以降、ジョブは失敗ディレクトリに配置されます。
InputDirectories MBeanを設定して、入力ファイルのパスを指定します。この値は、場所の配列として表すことができます。マルチノード間のImagingインストールを使用している場合、この場所はすべての入力エージェント間で共有され、すべてのエージェントがアクセスできる必要があります。入力エージェントが異なるマシン上にある場合は、共有ネットワークである必要があります。
前述の手順を完了すると、入力エージェントがアクティブになり、処理を開始できる状態になります。アプリケーション(第4.2項「アプリケーションの作成」を参照)と入力定義(第5.2項「入力定義の作成」を参照)を作成すると、入力エージェントはジョブの処理を開始します。
入力エージェントは、入力ファイルに基づいて処理を行います。入力ファイルは、CSV(カンマ区切りの値)ファイルのような簡単なテキスト・ドキュメントで、Imagingシステムで索引を作成するためのファイルおよび関連するメタデータのリストが格納されています。正しいエンコーディングが入力定義で指定されていれば、入力ファイルでは様々なエンコーディングを使用できます。入力エージェントは、入力定義の定義に使用されるサンプル・ファイルではなく、入力定義の入力マスクと一致するすべての入力ファイルを検索します。APIを使用して入力を作成する場合、サンプル・ファイルは必要ありません。サンプル・ファイルは、ユーザーがデータを表示して列を選択できるようにユーザー・インタフェースを使用して入力を作成する場合にのみ使用します。
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として処理されます。行に対するコマンドは、列としてカウントされません。第9.3項「入力ファイリング・コマンドの使用」を参照してください。
入力ファイル内の列がアプリケーションの順序と一致している必要はありませんが、索引を正しく作成するには、入力定義で指定された場所にある必要があります。
|
注意: 入力ファイルで指定されている日付および時刻には、指定された日付に適用されている夏時間(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がコマンドで指定されていない場合、入力ファイル内の最後の新しいドキュメント行に注釈が適用されます。最後の新しいドキュメントが索引の作成に失敗した場合、注釈を適用する対象のドキュメントが存在しないため、注釈の適用コマンドも失敗します。
複数の注釈コマンドは相互を上書きし、累積されません。
構文
@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キューにあることが通知されると、入力インジェスタがファイルの処理を開始します。
インジェスタがリポジトリへの接続をオープンし、ドキュメントを追跡するためのエラー・ファイルおよび新しいバッチ・オブジェクトを作成します。
スレッドによって、入力ファイルの解析およびImagingでのドキュメントの索引の作成が開始されます。索引の作成中に発生したエラーは、エラー・ファイルに記録されます。入力ファイル内のすべてのエントリについて、この手順が繰り返されます。
すべてのドキュメントが処理されると、バッチが終了し、エラー・エントリがなかった場合は、エラー・ファイルが削除されます。
インジェスタがリポジトリへの接続をクローズし、入力ファイルがProcessedまたはFailedディレクトリ下の現在の日付のディレクトリに移動されます。インジェスタは、ステージングされた次の入力ファイルの処理を開始します。
ワーク・マネージャは、多数のスレッドを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サーバー環境の構成を参照してください。
ドメインのWebLogicコンソールを起動し、デプロイメント・セクションに移動します。
Imagingアプリケーションを選択して、Imagingの詳細を表示します。
「構成」タブ、「負荷」タブの順に選択して、「ワーク・マネージャ」リストを表示します。
「InputAgentWorkManager」を選択して調整します。
ページの下部にある「InputAgentMaxThreadsConstraint」を選択します。
スレッド数を新しい最大スレッド数に更新し、「保存」をクリックします。
管理対象サーバーを再起動すると、新しいスレッド数が有効になります。
入力エージェントには再試行メカニズムが備わっており、リカバリ可能なエラーが発生した場合には入力ファイルの処理を再試行できます。このようなエラーの例としては、リポジトリがまだ使用可能でないときに初期化を完了する必要がある場合などがあります。リカバリ可能なエラーが入力エージェントで検出された場合、ファイリングが再度JMSキューに配置されます。このキューには、入力ファイルがすぐに再処理されないようにするための構成可能な再試行の待機タイマーがあります。また、InputAgentRetryCount MBeanを設定して、ジョブを再試行できる回数を制御することもできます。デフォルトは3です。4回目以降、ジョブは失敗ディレクトリに配置されます。
入力ファイルのエラーをトラブルシューティングする手順は次のとおりです。
Errorsディレクトリを調べて、入力ファイルの解析を妨げている重大なエラーがないかどうかを確認します。重大なエラーの場合、元の入力ファイルとエラー・ファイルの2つのファイルがErrorsディレクトリに格納されます。元の入力ファイルは、エラー・コードとエラーが発生した日時を元のファイル名に追加することによって、名前が変更されます。ファイル名の形式は次のとおりです。
original name-error code.YYYY-MM-DD.HH-mm-SS.original ext
エラー・ファイルには、元の入力ファイル名にエラーの日時を追加した名前が使用され、.err拡張子が付けられます。ファイル名の形式は次のとおりです。
original name.YYYY-MM-DD.HH-mm-SS.err
たとえば、入力ファイルinvoices.datでエラーが発生した場合、名前が変更されて、invoices.dat-errorcode.05-21-2010.16_36_07.datとしてProcessedディレクトリに格納され、invoices.dat.05-21-2009.16_36_07.errというエラー・ファイルが関連付けられます。
|
注意: 入力ファイルに名前を付ける際には、使用するファイル・システムのファイル名の文字数制限を考慮する必要があります。追加されるエラー・コードと日時スタンプの文字数を確保するには、入力ファイル名をファイル・システムの制限より少なくとも55文字少なくする必要があります。 たとえば、Windows NTFSファイル・システムでは、ファイル名とファイル・パスを合わせた長さが256文字に制限されています。Errorsディレクトリのパスが150文字の場合、入力ファイル名が51文字を超えないようにする必要があります。256(文字数の制限)-150(ディレクトリ・パスの文字数)-55(エラー・コードと日付スタンプの文字数)=51(ファイル名に残された文字数)となるためです。この例では、51文字を超える文字数が入力ファイル名に必要な場合、Errorsディレクトリを短いパスに移動する必要があります。 |
エラー・レポートがある場合、失敗した元の入力ファイルのすべての行とエラー・メッセージを含む追加の列から成るリストがエラー・レポートに格納されます。たとえば、次のような元の行があったとします。
C:\IBPM Data\WorkFiles\Filer\input\Images\C885|Identifier 165|27/06/2008|28215|495.75|
この場合、エラー・ファイルには次のように表示されます。
C:\IBPM Data\WorkFiles\Filer\input\Images\C885|Identifier 165|27/06/2008|28215|495.75|Could not find file C:\IBPM Data\WorkFiles\Filer\input\Images\C885
Imagingでより詳細なロギング・レベルが有効になっている場合、ファイリングがProcessedディレクトリに格納されると、次のようなログ・エントリが作成されます。
Filing <Input Name> completed successfully with <indexed doc count> documents processed successfully out of <total doc count> documents.
ファイリングが失敗した場合は、次のようなログ・エントリが作成されます。
An error occurred while completing a batch.
行単位のエラーの一般的な原因は、無効な値範囲やデータの切捨てなど、ロードされるメタデータの適切なフォーマットに関する問題です。
サーバーのOracle Diagnostic Logging(ODL)フレームワークのログを参照します。これをチェックするための最も一般的な方法は、Enterprise ManagerのImagingアプリケーション用のログ・ビューアを使用することです。この場合の一般的な問題は、基になるリポジトリやファイル権限に関する問題に起因します。
