4 コンテンツのバッチ・ロード

この項では、バッチ・ローダー・ユーティリティを使用して、Oracle WebCenter Content Serverインスタンスで大量のファイルを同時にチェックイン(挿入)、削除および更新する方法を説明します。

この章の項目は次のとおりです。

• バッチ・ロードについて

• バッチ・ロード・ファイルの準備

• バッチ・ローダーの実行

• バッチ・ローダーのパフォーマンスの最適化

• ベスト・プラクティス事例

4.1 バッチ・ロードについて

大量のファイルのバッチ・ロードは、バッチ・ローダー・ユーティリティを使用して自動化することで、時間と労力を削減できます。バッチ・ローダーを使用する場合の例を次に示します。

• WebCenter Contentソフトウェアを購入したばかりで、データベースに存在するメタデータを含むすべての既存のファイルをチェックインします。

• コンテンツ・サーバー・リポジトリにチェックインされたドキュメントがあり、新規カスタム・メタデータ・フィールドを作成したばかりです。バッチ・ローダーを使用して、新規メタデータ・フィールドに指定する値を、既存の各コンテンツ・アイテムに追加できます。

• 特定の大量のファイルをシステムから削除します。

バッチ・ローダーは、バッチ・ロード・ファイルで指定したアクションを実行します。このファイルは、バッチ・ローダーに実行するアクションと、バッチ内の各コンテンツ・アイテムに割り当てるメタデータを指示するテキスト・ファイルです。

注意:

バッチ・ローダー・ユーティリティがOracle WebLogic Serverインスタンスを使用して正しく機能するには、JDBC接続設定を構成する必要があります。手順については、「スタンドアロン・モードでの管理アプリケーションの実行」を参照してください。

この項の項目は次のとおりです。

• バッチ・ロードのファイル・レコードについて

• バッチ・ロードのアクションについて

• バッチ・ロードの挿入アクションについて

• バッチ・ロードの削除アクションについて

• バッチ・ロードの更新アクションについて

• バッチ・ロード・ファイルのオプション・パラメータについて

• カスタム・メタデータ・フィールドについて

4.1.1 バッチ・ロード・ファイルのレコードについて

バッチ・ロード・ファイルは、実行するアクションまたは個々のコンテンツ・アイテムに対するメタデータ(あるいはその両方)を指定する名前と値のペアのセットである、ファイル・レコードで構成されています。

注意:

フィールド名およびパラメータは、大文字と小文字が区別されます。これらは、次の項で表示されているとおりに、バッチ・ロード・ファイルに表示される必要があります。たとえば、dDocNameは、ddocname、dDocnameまたはDDOCNAMEと同じになりません。

• 各ファイル・レコードは、<<EOD>> (データの終了)マーカーで終了します。

• 行頭にあるポンド記号(#)に続く空白は、コメントを示します。コメント記号の後には、空白を続ける必要があります。たとえば、# primaryFile=test.txtは正常に機能しますが、#primaryFile=test.txtはエラーが発生します。

• 次に、ファイル・レコードの例を示します。

  # This is a comment
  Action=insert
  dDocName=Sample1
  dDocType=Document
  dDocTitle=Batch Load record insert example
  dDocAuthor=sysadmin
  dSecurityGroup=Public
  primaryFile=links.doc
  dInDate=8/15/2001
  <<EOD>>

4.1.2 バッチ・ロードのアクションについて

バッチ・ロードの有効なアクションには、挿入、削除および更新があります。

• ファイルにアクションが指定されていない場合、システムは更新を実行しようとします。

• 各ファイル・レコードには1つのアクションのみ存在しますが、同じバッチ・ロード・ファイルに異なるアクションを持つファイル・レコードが存在する可能性があります。

• 各アクションのロジック・プロセスは異なります。

4.1.3 バッチ・ロードの挿入アクションについて

挿入アクションでは、新規ファイルをコンテンツ・サーバー・リポジトリにチェックインします。図4-1は、挿入アクションを示しています。

• コンテンツID (dDocName)がコンテンツ・サーバー・データベースに存在しない場合は、新規のファイルが作成されます。

• コンテンツID (dDocName)がコンテンツ・サーバー・データベースに存在し、リビジョン(dRevLabel)が指定されていない場合は、新規のリビジョンが作成されます。

• コンテンツID (dDocName)および指定したリビジョン(dRevLabel)がコンテンツ・サーバー・データベースに存在する場合、アクションは実行されません。

図4-1 新規ファイルにチェックインする挿入アクションの順序

「図4-1 新規ファイルにチェックインする挿入アクションの順序」の説明

4.1.3.1 挿入の要件

次の表では、挿入アクションが正常に動作するために必要なフィールドが定義されています。

注意:

バッチ・ロードされたリビジョンは、アクティブ・ワークフローの基準を満たしている場合でも、ワークフローを入力しません。

• フィールド長: フィールドで許可された最大文字数。

• 継承: 次のレコードにこのフィールドが含まれない場合、このフィールドの値は前のレコードから引き継がれます。

  重要

  カスタム・メタデータ・フィールドは、必須フィールドとして定義した場合、挿入アクションの際にも定義する必要があります。

  必須項目	フィールド長	継承	定義
  Action=insert	該当なし	あり	ファイルを挿入するコマンド。 Actionの語は大文字と小文字が区別され、最初は大文字にする必要があります。
  dDocName	30	なし	「コンテンツID」という名前のメタデータ・フィールド。
  dDocType	30	あり	「タイプ」という名前のメタデータ・フィールド。
  dDocTitle	80	なし	「タイトル」という名前のメタデータ・フィールド。
  dDocAuthor	30	あり	「作成者」という名前のメタデータ・フィールド。
  dSecurityGroup	30	あり	「セキュリティ・グループ」という名前のメタデータ・フィールド。
  primaryFile	該当なし	該当なし	「プライマリ・ファイル」という名前のメタデータ・フィールド。プライマリ・ファイル名は、完全パスまたはファイル名そのものになります。ファイル名のみが指定されている場合、ファイルの場所は次のように決定されます。 SetFileDirオプション・パラメータが現在のファイル・レコードまたは前のファイル・レコードで設定されている場合、SetFileDirに指定されたディレクトリが使用されます。 SetFileDirパラメータが設定されていない場合、バッチ・ロード・ファイルのパスが使用されます。(パスは、「バッチ・ローダー」ウィンドウの「バッチロード・ファイル」フィールドに指定します。) デフォルトでは、プライマリ・ファイル名は80文字を超えることはできません(このうち、拡張子に使用できるのは最大8文字のみです)。
  dInDate	該当なし	なし	「リリース日」という名前のメタデータ・フィールド。 dInDateは、バッチ・ローダーを実行しているユーザーのロケールの日付フォーマットを使用する必要があります。たとえば、米国英語の日付フォーマットはmm/dd/yy hh:mm:ss am/pmです。 時間情報はオプションです。時間を指定する場合、hh:mmの部分のみが必須です。ssおよびam/pmの部分はオプションです。
  <<EOD>>	該当なし	該当なし	ファイル・レコードのデータの終端を示します。

4.1.3.2 挿入の例

次のコード・フラグメントは、ファイルを挿入するためのバッチ・ロード・ファイルの構文を示しています。次の例では、2つのファイル・レコードがあります。

最初のファイル・レコードには、すべての必須フィールドおよびアクション文Action=insertが含まれています。2番目のファイル・レコードには、次の必須フィールドが示されていません: dDocType、dDocAuthorまたはdSecurityGroup。ただし、これらの項目の情報は、前のレコードから引き継がれます。また、2番目のレコードではアクションが指定されていないため、挿入アクションが継承されます。そのため、コンテンツID HR003が存在しない場合、このファイルは挿入されます。ただし、このコンテンツIDが存在する場合、アクションは更新ではなく挿入であるため、これは挿入されません。

• 最初のレコード:

  Action=insert
  dDocName=HR001
  dDocType=Form
  dDocTitle=New Employee Information Form
  dDocAuthor=Olson
  dSecurityGroup=Public
  primaryFile=hr001.doc
  dIndate=3/15/97
  <<EOD>>
  

• 2番目のレコード:

  dDocName=HR003
  dDocTitle=Performance Review
  primaryFile=hr003.doc
  dIndate=3/15/97
  <<EOD>>

4.1.4 バッチ・ロードの削除アクションについて

削除アクションでは、既存のファイルの1つまたはすべてのリビジョンを、コンテンツ・サーバー・リポジトリから削除します。指定したコンテンツID (dDocName)がコンテンツ・サーバー・データベースに存在しない場合、アクションは実行されません。図4-2は、削除アクションを示しています。

図4-2 削除アクションの順序

「図4-2 削除アクションの順序」の説明

4.1.4.1 削除の要件

次の表では、削除アクションが正常に動作するために必要なフィールドが定義されています。

必須項目	定義
Action=delete	ファイルを削除するコマンド。 Actionの語は大文字と小文字が区別され、最初は大文字にする必要があります。
dDocName	「コンテンツID」という名前のメタデータ・フィールド。
<<EOD>>	ファイル・レコードのデータの終端を示します。

4.1.4.2 削除の例

次の例は、ファイルを削除するためのバッチ・ロード・ファイルの構文を示しています。次の例では、2つのファイル・レコードがあります。最初のファイル・レコードは、コンテンツID HR001のすべてのリビジョンを削除します。2番目のファイル・レコードは、コンテンツ・アイテムHR002のリビジョン2を削除します。

Action=delete
dDocName=HR001
<<EOD>>
Action=delete
dDocName=HR002
dRevLabel=2
<<EOD>>

4.1.5 バッチ・ロードの更新アクションについて

更新アクションでは、既存のコンテンツ・アイテムを更新します。ファイル・レコードに存在する項目およびシステムに存在するコンテンツに応じて、次のアクションのうちの1つが発生します。

• 既存のコンテンツ・アイテムの新規リビジョンが作成されます。

• 既存のファイルのメタデータが更新されます。

• 新規コンテンツ・アイテムが挿入されます(Action=insert が実行されます)。

  注意:

  バッチ・ロードされたリビジョンは、アクティブ・ワークフローの基準を満たしている場合でも、ワークフローを入力しません。

次のシナリオのうち1つが発生すると、新規リビジョンが作成されます。

シナリオ	コンテンツID(dDocName)	リビジョン(dRevLabel)	バッチ・ロード・ファイル内のリリース日(dInDate)
シナリオ1	コンテンツ・サーバー・インスタンスに存在します。	バッチ・ロード・ファイルで指定されません。	システム内のファイルの最新リビジョンのリリース日の後。
シナリオ2	コンテンツ・サーバー・インスタンスに存在します。	バッチ・ロード・ファイルで指定されますが、コンテンツ・サーバー・インスタンスに存在しません。	システム内のファイルの最新リビジョンのリリース日の後。

図4-3 更新アクションの順序

「図4-3 更新アクションの順序」の説明

4.1.5.1 更新の要件

次の表では、更新アクションが正常に動作するために必要なフィールドが定義されています。

必須項目	フィールド長	継承	定義
Action=update	該当なし	あり	ファイルを更新するコマンド。 Actionの語は大文字と小文字が区別され、最初は大文字にする必要があります。
dDocName	30	なし	「コンテンツID」という名前のメタデータ・フィールド。
dDocType	30	あり	「タイプ」という名前のメタデータ・フィールド。
dDocTitle	80	なし	「タイトル」という名前のメタデータ・フィールド。
dDocAuthor	30	あり	「作成者」という名前のメタデータ・フィールド。
dSecurityGroup	30	あり	「セキュリティ・グループ」という名前のメタデータ・フィールド。
primaryFile	該当なし	該当なし	「プライマリ・ファイル」という名前のメタデータ・フィールド。 メタデータのみが更新されている場合、primaryFileフィールドは必須ではありませんが、dRevLabelは必須です。 オプションのdRevLabelフィールドが指定され、コンテンツ・サーバー・インスタンスに存在するリビジョン・ラベルと一致する場合、primaryFileフィールドは必須ではなく、そのリビジョンで指定されたプライマリ・ファイルが使用されます。 dRevLabelは必須フィールドではありませんが、primaryFileが存在しない場合、dRevLabelが必須フィールドになる点に注意することが重要です。 プライマリ・ファイル名は、完全パスまたはファイル名そのものになります。ファイル名のみが指定されている場合、ファイルの場所は次のように決定されます。 SetFileDirオプション・パラメータが現在のファイル・レコードまたは前のファイル・レコードで設定されている場合、SetFileDirに指定されたディレクトリが使用されます。 SetFileDirパラメータが設定されていない場合、バッチ・ロード・ファイルのパスが使用されます。(パスは、「バッチ・ローダー」ウィンドウの「バッチロード・ファイル」フィールドに指定します。)
dInDate	該当なし	なし	「リリース日」という名前のメタデータ・フィールド。 dInDateは、バッチ・ローダーを実行しているユーザーのロケールの日付フォーマットを使用する必要があります。たとえば、米国英語の日付フォーマットはmm/dd/yy hh:mm:ss am/pmです。 時間情報はオプションです。時間を指定する場合、hh:mmの部分のみが必須です。ssおよびam/pmの部分はオプションです。
<<EOD>>	該当なし	該当なし	ファイル・レコードのデータの終端を示します。

4.1.5.2 更新の例1

この例では、次のメタデータを持つ2つのファイルがすでにシステムにチェックインされていることを前提としています。

• HR001では、リリース日が1998年9月26日で、リビジョン1です

• HR002では、リリース日が1999年3月15日で、リビジョン2です

最初のファイル・レコードであるコンテンツID HR001は、システムに存在しますが、バッチ・ロード・ファイルで指定されたリビジョン(dRevLabel)がありません。そのため、バッチ・ローダーは、バッチ・ロード・ファイルに指定されたリリース日と、システム内の最新リビジョンのリリース日を比較します。1999年2月20日は1998年9月26日より後であるため、HR001の新規リビジョン2が追加されます。

2番目のファイル・レコードであるコンテンツID HR002は、システムに存在し、リビジョン(dRevLabel)が指定されていますが、リビジョン3がシステムに存在しません。そのため、HR002の新規リビジョン3が追加されます。

Action=update
dDocName=HR001
dDocType=Form
dDocTitle=New Employee Form
dDocAuthor=Olson
dSecurityGroup=Public
primaryFile=hr001.doc
DInDate=2/20/99
<<EOD>>
dDocName=HR002
dDocTitle=Payroll Change Form
primaryFile=hr002.doc
DIndate=2/20/99
dRevLabel=3
<<EOD>>

4.1.5.3 更新の例2

この例では、次のメタデータを持つ1つのファイルがすでにシステムにチェックインされていることを前提としています。

• コンテンツID = HR003

• リリース日 = 1997年3月15日

• リビジョン = 1

• タイトル = Performance Review

• 作成者 = Smith

コンテンツID HR003のリビジョン1がシステムに存在し、アクティブ・ワークフローにないため、このリビジョンは新しいタイトル、作成者およびリリース日のメタデータで更新されます。

Action=update
dDocName=HR003
dDocType=Form
dDocTitle=Performance Review Template
dDocAuthor=Smith
primaryFile=hr003.doc
dIndate=2/20/99
dRevLabel=1
<<EOD>>

4.1.6 バッチ・ロード・ファイルのオプション・パラメータについて

次の表は、バッチ・ロード・ファイル内のファイル・レコードで使用できるオプション・パラメータを示しています。

バッチ・ロード・ファイルでは、コンテンツ・アイテムのチェックインに割り当てられたプライマリ・フォーマットおよび代替フォーマットをオーバーライドするために、2つの方法があります。

• primaryFile:formatパラメータの値を指定、またはalternateFile:formatパラメータの値を指定、あるいはその両方。ただし、primaryOverrideFormatパラメータまたはalternateOverrideFormatパラメータを使用して、これらの値をオーバーライドできます。コンポーネントを特定のタイプのチェックインで特定のフォーマットにしたり、別々のフォーマットにする特定のアプリケーション機能がいくつかのコンポーネントに存在するようにすることも可能です。

• primaryOverrideFormatパラメータの値を指定、またはalternateOverrideFormatパラメータの値を指定、あるいはその両方。ただし、これらは、IsOverrideFormat構成変数を有効にする場合にバッチ・ロード・ファイルのパラメータとしてのみ機能します。この方法を使用すると、primaryFile:formatパラメータおよびalternateFile:formatパラメータに設定する値をオーバーライドすることに注意してください。

  オプション・パラメータ	定義
  dRevLabel	「リビジョン」という名前のメタデータ・フィールド。 最大フィールド長は10文字です。 値は整数であるか、システム・プロパティ設定で設定されたメジャー/マイナー・リビジョンのラベル・シーケンスに準拠している必要があります。
  dDocAccount	「アカウント」という名前のメタデータ・フィールド。 最大フィールド長は30文字です。 このフィールドは、次のファイル・レコードに継承されません。 アカウントが有効になっていない場合は、このフィールドを指定しないでください。 アカウントが有効になっていて、このフィールドが指定されていない場合、dDocAccountは空の値に設定されます。
  xComments	「コメント」という名前のメタデータ・フィールド。最大フィールド長は255文字です。
  dOutDate	「有効期限」という名前のメタデータ・フィールド。 dOutDateは、バッチ・ローダーを実行しているユーザーのロケールの日付フォーマットを使用する必要があります。たとえば、米国英語の日付フォーマットはmm/dd/yy hh:mm:ss am/pmです。 時間情報はオプションです。時間を指定する場合、hh:mmの部分のみが必須です。ssおよびam/pmの部分はオプションです。
  primaryFile:path	ファイルの場所を指定します。primaryFile:pathの値が指定されている場合、その値はprimaryFileパラメータに指定された値をオーバーライドします。ただし、primaryFile:pathの値は、ファイル変換フォーマットを決定するために使用されません。primaryFile:pathの値が指定されていない場合、場所はprimaryFileの値から決定されます。 このパラメータでは、次の構文が使用されます。 primaryFile:path=complete_path/primary_file_name
  primaryFile:format	プライマリ・ファイルに使用するファイル形式を指定します。このファイル形式は、ファイルのファイル拡張子によって指定されたもの、およびprimaryFileパラメータに指定した値をオーバーライドします。primaryFile:formatの値が指定されていない場合、ファイル形式はprimaryFileの値のファイル拡張子から決定されます。 このパラメータでは、次の構文が使用されます。 primaryFile:format=application/conversion_type
  alternateFile	「代替ファイル」という名前のメタデータ・フィールド。代替ファイル名は、完全パスまたはファイル名そのものになります。ファイル名のみが指定されている場合、ファイルの場所は次のように決定されます。 SetFileDirオプション・パラメータが現在のファイル・レコードまたは前のファイル・レコードで設定されている場合、SetFileDirに指定されたディレクトリが使用されます。 SetFileDirパラメータが設定されていない場合、バッチ・ロード・ファイルのパスが使用されます。(パスは、「バッチ・ローダー」ウィンドウの「バッチロード・ファイル」フィールドに指定します。)
  alternateFile:path	代替ファイルの場所を指定します。alternateFile:pathの値が指定されている場合、その値はalternateFileパラメータに指定した値をオーバーライドします。ただし、alternateFile:pathの値は、ファイル変換フォーマットを決定するために使用されません。alternateFile:pathの値が指定されていない場合、場所はalternateFileパラメータの値が指定されている場合はその値から決定されます。そうでない場合、デフォルトでは、primaryFileの値は計算に使用されます。 このパラメータでは、次の構文が使用されます。 alternateFile:path=complete_path
  alternateFile:format	代替ファイルに使用するファイル形式を指定します。このファイル形式は、ファイルのファイル拡張子によって指定されたもの、およびalternateFileパラメータに指定した値をオーバーライドします。alternateFile:formatの値が指定されていない場合、ファイル形式はalternateFileパラメータの値が指定されている場合はその値のファイル拡張子から決定されます。そうでない場合、デフォルトでは、primaryFileの値は計算に使用されます。 このパラメータでは、次の構文が使用されます。 alternateFile:format=application/conversion_type
  webViewableFile	Web表示可能ファイル名は、完全パスまたはファイル名そのものになります。webViewableFileの値が指定されている場合、変換プロセスは実行されません。ファイル名のみが指定されている場合、ファイルの場所は次のように決定されます。 SetFileDirオプション・パラメータが現在のファイル・レコードまたは前のファイル・レコードで設定されている場合、SetFileDirに指定されたディレクトリが使用されます。 SetFileDirパラメータが設定されていない場合、バッチ・ロード・ファイルのパスが使用されます。(パスは、「バッチ・ローダー」ウィンドウの「バッチロード・ファイル」フィールドに指定します。)
  webViewableFile:path	Web表示可能ファイルの場所を指定します。webViewableFile:pathの値が指定されている場合、その値はwebViewableFileパラメータに指定された値をオーバーライドします。ただし、webViewableFile:pathの値は、ファイル変換フォーマットを決定するために使用されません。webViewableFile:pathの値が指定されていない場合、場所はwebViewableFileの値から決定されます。 このパラメータでは、次の構文が使用されます。 webViewableFile:path=complete_path
  webViewableFile:format	Web表示可能ファイルに使用するファイル形式を指定します。このファイル形式は、ファイルのファイル拡張子によって指定されたもの、およびwebViewableFileパラメータに指定した値をオーバーライドします。webViewableFile:formatの値は明示的に指定する必要があり、これはwebViewableFileの値から決定されません。 このパラメータでは、次の構文が使用されます。 alternateFile:format=application/conversion_type
  primaryOverrideFormat	プライマリ・ファイルに使用するファイル形式を指定します。このファイル形式は、ファイルのファイル拡張子によって指定されたものをオーバーライドします。このオプションは、IsOverrideFormat構成変数を有効にする場合にパラメータとしてのみ機能します。この変数は、システム・プロパティ・ユーティリティでフォーマットのオーバーライドを許可を選択することで設定できます。ただし、これよりも、primaryFile:formatパラメータを使用することをお薦めします。
  alternateOverrideFormat	代替ファイルに使用するファイル形式を指定します。このファイル形式は、ファイルのファイル拡張子によって指定されたものをオーバーライドします。このオプションは、IsOverrideFormat構成変数を有効にする場合にパラメータとしてのみ機能します。この変数は、システム・プロパティ・ユーティリティでフォーマットのオーバーライドを許可を選択することで設定できます。ただし、これよりも、代替のFile:formatパラメータを使用することをお薦めします。
  SetFileDir	プライマリ・ファイルおよび代替ファイルがあるディレクトリを指定します。このフィールドは、次のファイル・レコードに継承されます。

4.1.7 カスタム・メタデータ・フィールドについて

構成マネージャに定義されている任意のカスタム・メタデータ・フィールドを、ファイル・レコードに含めることができます。

• カスタム・メタデータ・フィールドは、必須フィールドとして定義した場合、挿入アクションや更新アクションの際に定義する必要があります。

• カスタム・メタデータ・フィールドが必須フィールドではないが、空白であってもそれにデフォルト値がある場合、そのデフォルト値は、バッチ・ロード・ファイルで指定されていない場合は使用されます。

• カスタム・メタデータ・フィールドの値を指定する際には、フィールド名の前にxを付けます。たとえば、Locationというカスタム・メタデータ・フィールドがある場合、バッチ・ロード・ファイル・エントリはxLocation=valueになります。

• アドオン製品には、カスタム・メタデータ・フィールドを使用しているものがあることに注意してください。たとえば、PDF Watermarkがある場合、Watermarkというフィールドを作成します。このフィールドをバッチ・ロード・ファイルに含めるには、他のカスタム・メタデータ・フィールドと同様に、それの前にxを付けます(例: xWatermark)。

4.2 バッチ・ロード・ファイルの準備

この項の項目は次のとおりです。

• バッチ・ロード・ファイルの準備について

• マッピング・ファイル

• 「バッチビルダー」ウィンドウからのバッチ・ロード・ファイルの作成

• マッピング・ファイルの作成

• コマンドラインからのバッチ・ロード・ファイルの作成

4.2.1 バッチ・ロード・ファイルの準備について

生成されるテキスト・ファイルがバッチ・ロード・ファイルの構文要件に従っていれば、希望する方法で、バッチ・ロード・ファイルを作成できます。ただし、バッチ・ローダーには、バッチ・ロード・ファイルを作成する際に役立つバッチビルダーというツールが用意されています。

• バッチビルダーは、指定したディレクトリにあるファイルに基づいて、バッチ・ロード・ファイルを作成します。バッチビルダーは、バッチ・ロード・ファイルを作成するすべてのサブディレクトリ全体を再帰的に読み取ります。

• マッピング・ファイルは、各ファイル・レコードのメタデータを決定する方法をバッチビルダーに説明します。バッチビルダーを使用して、カスタム・マッピング・ファイルを作成および保存できます。

• バッチビルダーは、スタンドアロンのユーティリティ・インタフェースまたはコマンドラインから実行できます。

• バッチビルダーは、コンテンツの外部コレクションを作成するために使用することもでき、これはコンテンツ・サーバー・データベース内ではなく別の検索コレクションに索引付けおよび格納されます。読取り専用の外部コレクションを設定でき、この場合、ユーザーは、コンテンツの検索はできますが、メタデータの更新やコンテンツの削除はできません。外部コンテンツが別のコンテンツ・サーバー・インスタンスにも含まれている場合に、このオプションをお薦めします。

バッチ・ローダー・ユーティリティを使用して、コンテンツ・サーバー・インスタンスで大量のファイルを同時に更新および挿入することを計画している場合は、バッチ・ロード・ファイルを作成する必要があります。バッチ・ロード・ファイルに含めることのできるオプション・パラメータの2つは、primaryOverrideFormatとalternateOverrideFormatです。ただし、これらのオプションは、IsOverrideFormat構成変数を有効にすると、バッチ・ロード・ファイルのパラメータとしてのみ動作します。この変数は、システム・プロパティ・ユーティリティを使用して設定できます。

4.2.2 マッピング・ファイル

マッピング・ファイルは、.hda拡張子を持つテキスト・ファイルで、コンテンツ・サーバー・インスタンスで使用されるデータ・ファイルのタイプで識別されます。

HDAファイル、LocalDataプロパティおよび結果セットの詳細は、『Oracle WebCenter Contentでの開発』のHDAファイルのエレメントに関する項を参照してください。

4.2.2.1 マッピング・ファイルのフォーマット

次の2つのうちの1つのフォーマットで、メタデータ・マッピングを定義できます。

• LocalData定義での名前/値のペアの場合、マッピング・ファイルは次のようになります。

  @Properties LocalData
  dDocName=<$filename$>.<$extension$>
  dInDate=<$filetimestamp$>
  @end
  

• BatchBuilderMapping ResultSetの場合、マッピング・ファイルは次のようになります。

  @ResultSet SpiderMapping
  2
  mapField
  mapValue
  dDocName
  <$filename$>.<$extension$>
  dInDate
  <$filetimestamp$>
  @end

4.2.2.2 マッピング・ファイルの値

マッピング・ファイルでは、次の値を使用できます。

値	説明	例
標準の文字列	すべてのファイルは、指定されたメタデータ値を持ちます。	dDocType=Document すべてのファイルは、Documentコンテンツ・タイプになります。
Idocスクリプト	任意のサポート済のIdocスクリプト。『Oracle WebCenter Contentでの開発』のIdocスクリプトのカスタム・スクリプト言語の概要に関する項を参照してください。	xLanguage=<$if strEquals(dir2, "EN")$>English<$elseif strEquals(dir2, "SP")$>Spanish<$else$>French<$endif$>
<$dir1$>, <$dir2$>	ファイルのパス内の指定したレベルのディレクトリ名。<$dir1$>は「ディレクトリ」フィールドで指定したルート・ディレクトリを参照し、<$dir2$>はその次のレベルのディレクトリを参照します。	dDocType=<$dir1$> dSecurityGroup=<$dir2$> dDocAccount=<$dir3$> ファイル・パスがf:/docs/public/sales/march.docで、「ディレクトリ」の値にf:/docsを指定した場合、値は次のようになります。 <$dir1$> = "docs" <$dir2$> = "public" <$dir3$> = "sales"
<$dUser$>	現在ログインしているユーザー。	dDocAuthor=<$dUser$> administratorがログインしている場合、<$dUser$>はadministratorになります。
<$extension$>	ファイルのファイル拡張子。	dDocTitle=<$filename$>.<$extension$> ファイル・パスがd:/salesdocs/sample.docの場合、<$extension$>はdocです。
<$filename$>	ファイルの名前です。	dDocName=<$filename$> ファイル・パスがd:/salesdocs/sample.docの場合、<$filename$>はsampleです。
<$filepath$>	ファイル名を含む、ファイルのディレクトリ・パス全体。	xPath=<$filepath$> ファイル・パスがc:/docs/public/acct/sample.docの場合、<$filepath$>はc:/docs/public/acct/sample.docです。
<$filesize$>	ファイルのサイズ(バイト単位)。	xFileSize=<$filesize$> 42KBのファイルの場合、<$filesize$>は43008になります。
<$filetimestamp$>	ファイルが最後に変更された日時。	dInDate=<$filetimestamp$> 最終変更日が2001年9月13日午後4時3分の場合、<$filetimestamp$>は、米国英語のロケールでは9/13/01 4:03 PMになります。
<$URL$>	物理ファイル・ルートおよび相対Webルートの値に基づいた、ファイルのURL。

4.2.3 「バッチビルダー」ウィンドウからのバッチ・ロード・ファイルの作成

「バッチビルダー」ウィンドウからバッチ・ロード・ファイルを作成するには:

1. バッチ・ローダー・ユーティリティを起動します。

   • Windows: 「スタート」→「プログラム」→「Content Server」→「instance_name」→「Utilities」→「Batchloader」を選択します。

   • UNIX: DomainHome/ucm/cs/bin/ディレクトリに移動し、シェル・ウィンドウで「./BatchLoader」と入力して、キーボードで[RETURN]キーを押します。

2. ログイン・ウィンドウで、コンテンツ・サーバー管理者のユーザー名およびパスワードを入力し、「OK」をクリックします。
3. 「バッチ・ローダー」ウィンドウで「オプション」を選択し、「バッチ・ファイルのビルド」をクリックします。
4. 「バッチビルダー」ウィンドウの「ディレクトリ」フィールドに、バッチ・ロード・ファイルに含めるファイルの場所を入力します。
5. 「バッチロード・ファイル」フィールドに、バッチ・ロード・ファイルのパスおよびファイル名を入力します。「参照」ボタンをクリックして、目的のディレクトリおよびファイルにナビゲートし、選択することができます。
6. マッピング・リストから、マッピング・ファイルを選択します。新規マッピング・ファイルの作成または既存のものを編集する場合は、「マッピング・ファイルの作成」を参照してください。
7. オプション:「ファイル・フィルタ」フィールドに、特定のファイルをバッチ・ロード・ファイルに含めたり除外するフィルタ設定を入力します。
8. オプション: 読取り専用の外部コレクションをバッチ・ロードするには、「外部」を選択し、外部コレクションのオプションを選択します。
9. 「ビルド」をクリックします。
10. ビルド・プロセスが完了したら、「OK」をクリックします。
11. バッチ・ロード・ファイルをテキスト・エディタで開き、ファイル・レコードを再確認します。
12. 現在のバッチ・ロード・ファイルの設定をデフォルトとして保存するには、「オプション」、「構成の保存」の順に選択します。

4.2.4 マッピング・ファイルの作成

マッピング・ファイルを作成するには:

1. 「バッチビルダー」ウィンドウを開きます。
2. 「マッピング」フィールドの横にある「編集」をクリックします。
3. バッチビルダー・マッピング・リスト・ウィンドウで、「追加」をクリックします。
4. 「バッチビルダー・マッピングの追加」ウィンドウで、マッピング・ファイルの名前と説明を入力し、「OK」をクリックします。
5. 「バッチビルダー・マッピングの編集」ウィンドウで、「追加」をクリックします。
6. 「バッチビルダー・マッピング・フィールドの追加/編集」ウィンドウに、定義するメタデータ・フィールド名を入力します。たとえば、「コンテンツID」フィールドに「dDocName」と入力し、「コメント」フィールドに「xComments」と入力します。
7. メタデータ・フィールドの値を入力します。

   • 任意の定数テキストおよびIdocスクリプトを「値」フィールドに直接入力します。たとえば、バッチ・ロード・ファイルのすべてのドキュメントのタイプに「Document」を設定するには、「フィールド」フィールドに「dDocType」と入力し、「値」フィールドに「Document」と入力します。『Oracle WebCenter Contentでの開発』のIdocスクリプトのカスタム・スクリプト言語の概要に関する項を参照してください。

   • 事前定義済の変数を「値」フィールドに追加するには、右列で変数を選択し、「<<」ボタンをクリックします。たとえば、セキュリティ・グループに各ドキュメントの第2レベルのディレクトリを設定するには、「フィールド」フィールドに「dSecurityGroup」と入力し、「値」フィールドに<$dir1$>変数を挿入します。

     注意:

     事前定義済の変数を選択する際には注意してください。多くのメタデータ・フィールドには、長さの制限があり、空白や句読点などの特定の文字を含めることができません。『Oracle WebCenter Contentのマネージメント』のコンテンツの管理に関する項を参照してください。

8. 「OK」をクリックします。
9. 定義するメタデータ・フィールドの数だけ、ステップ4から8までを繰り返します。
10. 「OK」をクリックして、変更を保存し、バッチビルダー・マッピングの編集ウィンドウを閉じます。

    マッピング・ファイルは、MapFileName.hdaという名前でIntradocDir/search/external/mapping/ディレクトリに保存されます。

11. 「閉じる」をクリックして、バッチビルダー・マッピング・リスト・ウィンドウを閉じます。

4.2.5 コマンドラインからのバッチ・ロード・ファイルの作成

BatchBuilderパラメータを、「バッチビルダー」ウィンドウから入力するのではなく、コマンドラインから入力することで、バッチ・ロード・ファイルを作成できます。コマンドラインからバッチ・ロード・ファイルを作成するには:

1. DomainHome/ucm/cs/bin/intradoc.cfgファイルをテキスト・エディタで開き、コンテンツ・サーバー・システム管理者のユーザー名がsysadminであることを示す次の行を追加します。

   BatchLoaderUserName=sysadmin
   

   これは、管理権限を持つユーザーのみがバッチ・ローダーおよびバッチビルダー・ユーティリティを実行する権限を持っているため、システム管理者としてシステムにログインするために必要です。

2. ファイルを保存して閉じます。
3. コマンドライン・ウィンドウを開き、DomainHome/ucm/cs/bin/ディレクトリに変更します。

   注意:

   コンテンツ・サーバー・インスタンスを実行しているのと同じオペレーティング・システム・アカウントを使用して、バッチビルダーを実行します。そうでない場合、権限の問題が発生するため、ソフトウェアはデータを処理しません。

4. 次のコマンドを入力します。

   • Windows:

     BatchLoader.exe -spider -q -ddirectory -mmappingfile -nbatchloadfile
     

   • UNIX:

     BatchLoader -spider -q -ddirectory -mmappingfile -nbatchloadfile
     

次のフラグは、バッチビルダーをコマンドラインから実行するBatchLoaderコマンドで使用できます。

フラグ	必須かどうか	説明
-spiderまたは/spider	あり	バッチビルダー・ユーティリティを実行します。
-qまたは/q	いいえ	バッチビルダーを、バックグラウンドで消音モードで実行します。(このフラグを使用せずにバッチビルダーをコマンドラインから実行すると、「バッチビルダー」ウィンドウが表示されます。)
-dまたは/d	あり	「ディレクトリ」フィールドの値。
-mまたは/m	あり	「マッピング」フィールドの値。
-nまたは/n	あり	「バッチロード・ファイル」フィールドの値。
-eまたは/e	いいえ	指定したファイルを除外します(「除外」チェック・ボックスを選択します)。
-iまたは/i	いいえ	指定したファイルを含めます(「除外」チェック・ボックスを選択解除します)。

4.2.5.1 Windowsの例

次の例は、バッチビルダーをWindowsのコマンドラインから実行する正しい構文を示しています。

• ディレクトリ = c:/myfiles

• マッピング・ファイル = MyMappingFile

• バッチ・ロード・ファイル = c:/batching/batchinsert.txt

• 除外するファイル = *.exeおよび*.zip

BatchLoader.exe -spider -q -dc:/myfiles -mMyMappingFile -nc:/batching/batchinsert.txt -eexe,zip

4.2.5.2 UNIXの例

次の例は、バッチビルダーをUNIXのコマンドラインから実行する正しい構文を示しています。

• ディレクトリ = /myfiles

• マッピング・ファイル = MyMappingFile

• バッチ・ロード・ファイル = /batching/batchinsert.txt

• 除外するファイル = index.htmおよびindex.html

BatchLoader -spider -q -d/myfiles -mMyMappingFile -n/batching/batchinsert.txt -eindex.htm,index.html

4.3 バッチ・ローダーの実行

この項の項目は次のとおりです。

• バッチ・ローダーの実行について

• 「バッチ・ローダー」ウィンドウからのバッチ・ロード

• コマンドラインからのバッチ・ロード

• IdcCommandユーティリティおよびリモート・アクセスの使用

• メタデータとしてのみのコンテンツのバッチ・ロード

• バッチ・ローダーの-consoleコマンドライン・スイッチ

• リダイレクトの追加

• バッチ・ロード・エラーの修正

4.3.1 バッチ・ローダーの実行について

バッチ・ローダーでは、コンテンツ・サーバー・インスタンスで大量のファイルを同時にチェックイン(挿入)、削除または更新するために、バッチ・ロード・ファイルの情報が使用されます。

• バッチ・ローダーは、スタンドアロンのユーティリティ・インタフェースまたはコマンドラインから実行できます。

• バッチ・ローダーの実行後に、コンテンツ・サーバー・インスタンスは、他のコンテンツ・アイテムの場合と同様に、Inbound Refineryインスタンスおよびインデクサを通じてファイルを処理します。

4.3.2 「バッチ・ローダー」ウィンドウからのバッチ・ロード

「バッチ・ローダー」ウィンドウを使用してコンテンツをバッチ・ロードするには:

1. 「バッチ・ローダー」ウィンドウを開きます。
2. 「参照」をクリックして、バッチ・ロード・ファイルにナビゲートし、選択します。
3. バッチ・ローダーが処理を停止するまでに発生してもよいエラーの数を変更するには、「許容最大エラー数」フィールドに数字を入力します。
4. ファイルを正常にチェックインまたは更新した後でハード・ドライブからファイルを削除するには、「チェックインが成功した後でファイルをクリーン・アップします。」を選択します。
5. バッチ・ロード中に失敗したファイル・レコードを含むテキスト・ファイルを作成するには、「失敗したリビジョン・クラスに対してエラー・ファイルを有効にします。」を選択します。
6. 「バッチ・ファイルをロードします。」をクリックして、バッチ・ローダー・プロセスを開始します。

   バッチ・ロード・プロセスが完了すると、「バッチ・ローダー」メッセージ・ウィンドウが開き、発生したエラー(ある場合)の数が示されます。

7. エラー・ファイルを有効化する場合、メッセージ・ボックスに表示されるファイル名を記録しておきます。
8. 「OK」をクリックします。
9. バッチ・ロードでの問題を修正します。
10. 現在のバッチ・ローダーの設定をデフォルトとして保存するには、「オプション」、「構成の保存」の順に選択します。

4.3.3 コマンドラインからのバッチ・ロード

バッチ・ローダー・パラメータを、「バッチ・ローダー」ウィンドウから入力するのではなく、コマンドラインから入力することで、コンテンツをバッチ・ロードできます。コマンドラインからバッチ・ローダーを実行するには:

1. DomainHome/ucm/cs/bin/intradoc.cfgファイルをテキスト・エディタで開き、コンテンツ・サーバー・システム管理者のユーザー名がsysadminであることを示す次の行を追加します。

   BatchLoaderUserName=sysadmin
   

   これは、管理権限を持つユーザーのみがバッチ・ローダー・ユーティリティを実行する権限を持っているため、システム管理者としてシステムにログインするために必要です。

2. ファイルを保存して閉じます。
3. コマンドライン・ウィンドウを開き、DomainHome/ucm/cs/bin/ディレクトリに移動します。

   注意:

   コンテンツ・サーバー・インスタンスを実行しているのと同じオペレーティング・システム・アカウントを使用して、バッチ・ローダーを実行します。そうでない場合、権限の問題が発生するため、ソフトウェアはファイルを処理しません。

4. 次のコマンドを入力します。

   • Windows:

     BatchLoader.exe -q -nbatchloadfile
     

   • UNIX:

     BatchLoader -q -nbatchloadfile
     

   バッチ・ローダーはバッチ・ロード・ファイルを処理しますが、メッセージ・ボックスは表示されません。

5. バッチ・ロードでの問題を修正します。

次のフラグは、コマンドラインからBatchLoaderコマンドで使用できます。

フラグ	必須かどうか	説明
-qまたは/q	いいえ	バッチ・ローダーを、バックグラウンドで消音モードで実行します。(このフラグを使用せずにバッチ・ローダーをコマンドラインから実行する場合、「バッチ・ローダー」ウィンドウが表示されます。)
-nまたは/n	あり	「バッチロード・ファイル」フィールドの値。
-console	いいえ	HTML Content Serverログおよびバッチ・ローダーを実行しているコンソール・ウィンドウに、すべてのアウトプットがエコーされます。詳細は、「バッチ・ローダーの-consoleコマンドライン・スイッチ」を参照してください。

4.3.3.1 Windowsの例

次の例は、バッチ・ロード・ファイルがc:/batching/batchinsert.txtである場合の、バッチ・ローダーをWindowsのコマンドラインから実行する正しい構文を示しています。

BatchLoader.exe -q -nc:/batching/batchinsert.txt

4.3.3.2 UNIXの例

次の例は、バッチ・ロード・ファイルが/batching/batchinsert.txtである場合の、バッチ・ローダーをUNIXのコマンドラインから実行する正しい構文を示しています。

BatchLoader -q -n/batching/batchinsert.txt

4.3.4 IdcCommandユーティリティおよびリモート・アクセスの使用

コンテンツ・サーバー・インスタンスを管理する際に、リモート・アクセスを使用する必要がある場合があります。これは、必ずしもリモート・ターミナル・アクセスが必要であるということではありません。ただし、リモートの場所からサーバーにコマンドを発行できるようにする必要があります。

リモート・アクセスとIdcCommandユーティリティを組み合せると、強力なツールセットとなり、インスタンスに大量のファイルを簡単にチェックインできるようになります。この機能を利用するには、発行コマンドにワークステーションを正しく設定して、バッチ・ロード・コマンドライン・ファイルでIdcCommandユーティリティを使用できるようにする必要があります。

この項の内容は次のとおりです。

• バッチ・ロード・コマンド・ファイル

• リモートのバッチ・ロードの準備

4.3.4.1 バッチ・ロード・コマンド・ファイル

バッチ・ロード・コマンド・ファイルには、ロードされる各ファイルのコマンドのセットが含まれています。大量のファイルをロードする場合、コマンド・ファイルが何百行にもなる可能性があります。編集ツールを使用すると、必要な多くの行を作成するタスクを単純化できます。たとえば、「リモートのバッチ・ロードの準備」の手順では、Microsoft Officeの編集およびメール・マージ機能を使用してバッチ・ロード・コマンド・ファイルを準備する方法を示しています。

次に、バッチ・ロード・コマンド・ファイルの例を示します。

@Properties LocalData
IdcService=CHECKIN_UNIVERSAL
doFileCopy=1
dDocTitle=thisfile
dDocType=Native
dSecurityGroup=Internal
dDocAuthor=sysadmin
primaryFile=filename
primaryFile:Path=pathtothefile/primaryfilename
xComments=Initial Check In
@end
<<EOD>>@Properties LocalData
IdcService=CHECKIN_UNIVERSAL
doFileCopy=1
dDocTitle=99.tif
dDocType=Native
dSecurityGroup=Internal
dDocAuthor=sysadmin

primaryFile=350.afp
primaryFile:path=/lofs/invoices/350.afp
xComments=Initial Check In
@end
<<EOD>>

4.3.4.2 リモートのバッチ・ロードの準備

リモートの場所からバッチ・ロードを実行できます。次の手順はMicrosoft Windowsオペレーティング・システム用に記載されたもので、主なステージは次のとおりです。

• ローカル・コンピュータの構成

• リモート・ワークステーションの構成のテスト

• バッチ・ロード・コマンド・ファイルの作成

• アップロードの実行

4.3.4.2.1 ローカル・コンピュータの構成

ローカル・コンピュータを構成するには:

1. Windowsエクスプローラを開きます。
2. 作業ディレクトリ(たとえばC:\working_dirなど)を作成します。
3. 作業ディレクトリには、アクセスしているコンテンツ・サーバー・インスタンスの1つ以上のディレクトリ(C:\working_dir\developmentおよびC:\working_dir\contributionなど)を作成します。これらのディレクトリは、DomainHomeNameと呼ばれます。
4. 各DonainHomeNameディレクトリに、cmdfilesサブディレクトリを作成します。
5. リモートのコンテンツ・サーバー・インスタンスで、MW_HOME\user_projects\domains\Domain_Name\ucm\csからそれぞれのDomainHomeName(この場合はC:\working_dir\development and C:\working_dir\contribution)に、次のディレクトリをコピーします。

   • working_dir\DomainHomeName\ucm\cs\bin

   • working_dir\DomainHomeName\ucm\cs\config

6. リモートのコンテンツ・サーバー・インスタンスから、次のディレクトリ(およびそのファイル)を作業ディレクトリにコピーします。

   • working_dir\idc\bin

   • working_dir\idc\components

     (CSDmsおよびNativeOsUtilsコンポーネント・ファイルをコピーすれば十分です)

   • working_dir\idc\config

   • working_dir\idc\jlib

   • working_dir\idc\resources\core\lang

   • working_dir\idc\resources\core\table

   • working_dir\idc\resources\core\config

7. テキスト・エディタを使用して、DomainHomeName\ucm\cs\bin\intradoc.cfgファイルをローカル・システム上で開き、ディレクトリ構造に合うようにIntradocDir構成変数を更新します。例:

   IntradocDir=working_dir\DomainHomeName\ucm\cs,
   IdcHomeDir=working_dir\idc
   WeblayoutDir=working_dir\DomainHomeName\ucm\cs\weblayout
   

8. テキスト・エディタを使用して、working_dir\DomainHomeName\ucm\cs\config\config.cfgファイルをローカル・システム上で開き、次の設定が正しいことを確認します。

   IntradocServerPort=4444
   IntradocServerHostName=HostMachineName
   

9. リモートのコンテンツ・サーバー・インスタンスで、システム・プロパティ・ユーティリティを使用して、ローカル・コンピュータのIPアドレスをセキュリティ・フィルタに追加します。
10. リモートのコンテンツ・サーバー・インスタンスを再起動します。

4.3.4.2.2 リモート・ワークステーションの構成のテスト

リモート・ワークステーションの構成をテストするには:

1. cmdfilesディレクトリで、pingservertest.hdaという名前のファイルを作成し、次の行を追加します。

   @Properties LocalData
   IdcService=PING_SERVER
   @end
   

2. コマンド・プロンプトを開き、作業binディレクトリに変更します(たとえば、cd C:\working_dir\development\bin)。
3. 次のコマンドを発行します。

   IdcCommand -f ..\cmdfiles\pingservertest.hda -u sysadmin -l ..\pingservertest.log -c server
   

4. 出力内容を確認します。成功した場合、サーバーから次のメッセージが表示されます。

   3/24/04: Success executing service PING_SERVER.
   You have completed your setup for remote commands.

4.3.4.2.3 バッチ・ロード・コマンド・ファイルの作成

この手順では、Microsoft Officeの編集およびメール・マージ機能を使用して、バッチ・ロード・コマンド・ファイルを作成します。バッチ・ロード・コマンド・ファイルを作成するには:

1. 次のように、ディレクトリの内容をリストするファイルを作成します。

   1. コマンド・プロンプトを開き、ロードするファイルを表すルート・ディレクトリに変更します。

   2. 出力内容をファイルにリダイレクトする次のコマンドを使用して、ファイル・リストを作成します。

      dir /s /b > filelisting.txt
      

   3. filelisting.txtファイルを確認します。それは次のようになります。

      V:\policies\ADMIN\working_dir_Admin\AbbreviationList.doc
      V:\policies\ADMIN\working_dir_Admin\Abbreviations.doc
      V:\policies\ADMIN\working_dir_Admin\AbsencePres.doc
      V:\policies\ADMIN\working_dir_Admin\AdmPatientCare.doc
      V:\policies\ADMIN\working_dir_Admin\AdmRounds.doc
      V:\policies\ADMIN\working_dir_Admin\AdverseEvents.doc
      V:\policies\ADMIN\working_dir_Admin\ArchivesPermanent.doc
      V:\policies\ADMIN\working_dir_Admin\ArchivesRetrieval.doc
      V:\policies\ADMIN\working_dir_Admin\ArchivesStandardReq.doc

      注意:

      バッチ・ロードを処理する際、バッチ・ロード・コマンド・ファイル内のprimaryFile文によって示されるサーバー上に、ファイルが存在する必要がある点に注意することが重要です。ファイルのディレクトリをサーバーとローカル・システムにマップする場合は、同じ文字を使用することが最適です。または、ファイルのディレクトリをサーバーに一時的にコピーできます。

2. 次のように、ファイル・リストを編集して、ファイル名およびタイトル・データを作成します。

   1. filelisting.txtファイルをExcelで開きます。

   2. 「置換」を使用して、ファイル名のみ残っているすべてのディレクトリ情報を削除します。また、filelisting.txtの行を検索し、削除します。

   3. 列A(ファイル名が格納されている)を列Bにコピーします。この例では、ファイル名はタイトルにも使用されており、列Bはタイトルになります。

   4. 「置換」を使用して、列Bの名前からファイル拡張子を削除します。

   5. 新しく1行目を挿入し、最初の列にfilename、2番目の列にtitleと入力します。

   6. ファイルを保存します。

3. 次のように、メール・マージ機能を使用して、ファイル・リストから.hdaファイルを作成します。

   1. Wordアプリケーションを開き、バッチ・ロード・コマンドのセットを使用して新規ドキュメントを作成します。次の例は、基本的なバッチ・ロード・コマンドを示しています。バッチ・ロード・コマンドを作成する際には、構成設定を一致させる必要があります。

      @Properties LocalData
      IdcService=CHECKIN_UNIVERSAL
      doFileCopy=1
      dDocTitle=
      dDocType=Native
      dSecurityGroup=Internal
      dDocAccount=Policy/Admin
      dDocAuthor=sysadmin
      primaryFile=d:/temp/working_dir_Admin/
      xComments=Initial Check In
      @end
      <<EOD>>
      

   2. 「Tools」、「Letters and Mailing」、「Mail Merge Wizard」の順に選択し、ウィザードを進みます。filelisting.txtファイルをメール・マージへの入力として使用するものを次から選択します。

      • レター・ドキュメント(ステップ1)

      • 現在のドキュメント(ステップ2)

      • 既存のリスト(ステップ3)、Excelスプレッドシートをデータ・ソースとして選択します。

      • 追加の項目(ステップ4)、タイトルおよびファイル名のフィールドを、次のように表示されるよう、Wordドキュメントに配置します。

        @Properties LocalData
        IdcService=CHECKIN_UNIVERSAL
        doFileCopy=1
        dDocTitle="title"
        dDocType=Native
        dSecurityGroup=Internal
        dDocAccount=Policy/Admin
        dDocAuthor=sysadmin
        primaryFile=d:/temp/working_dir_Admin/"filename"
        xHistory=Initial Check In
        @end
        <<EOD>>
        

   3. メール・マージを終了し(ステップ5および6)、ページ当たり1つのマージ・レコードを含む新規Wordドキュメントが作成されます。

   4. 文字を編集し、すべてを選択し、置換機能を使用してすべてのセクション区切りを削除します。

   5. ファイルを、拡張子がhdaのプレーン・テキスト・ファイルとして、/cmdfilesディレクトリに保存します(たとえばfilelisting.hda)

4.3.4.2.4 バッチ・ロードのアップロードの実行

アップロードを実行するには:

1. コマンド・プロンプトを開きます。
2. 作業binディレクトリにナビゲートします。
3. 次のコマンドを発行します。

   IdcCommand -f ../cmdfiles/filelisting.hda -u sysadmin -l ../filelisting.log -c server
   

   ファイルはコンテンツ・サーバー・リポジトリにチェックインされ、各ファイルがチェックインされる際に、コマンド・ウィンドウにメッセージが表示されます。

4.3.5 メタデータとしてのみのコンテンツのバッチ・ロード

バッチ・ローダーを使用して実行するアクションに応じて、特定のフィールドがバッチ・ロード・ファイルで必須になります。既存のコンテンツ・アイテムのメタデータのみを更新している場合、バッチ・ロード・ファイルの「プライマリ・ファイル」フィールドは必須ではありません。詳細は、「更新の要件」を参照してください。

ただし、コンテンツをコンテンツ・サーバー・インスタンスにメタデータとしてのみロード(挿入アクション)する場合、「プライマリ・ファイル」フィールドはバッチ・ロード・ファイルで必須になります。このフィールドはインポートで無視されますが、バッチ・ローダーではこれを定義することが要求されます。「プライマリ・ファイル」フィールドが見つからない場合、次のような(または類似した)エラーが表示されます。

レコード番号<number>を確認してください。バッチローダー: 必須フィールドprimaryFileが存在しないので<record>をチェックインできません。

コンテンツをメタデータとしてのみバッチ・ロードするには、次の手順を実行します。

1. 次のように、コンテンツ・サーバー・インスタンスのconfig.cfgファイルを開きます。

   IntradocDir/config/config.cfg

2. 次の構成変数を追加します。

   createPrimaryMetaFile=true
   AllowPrimaryMetaFile=true
   

3. config.cfgファイルを保存して閉じます。
4. バッチ・ロード・ファイルで、各レコードに対して次のフィールドを追加します。

   primaryFile=
   createPrimaryMetaFile=true
   

   primaryFileフィールドが空白のままであることは許容されることに注意してください。このフィールドは無視されますが、含める必要があります。

5. バッチ・ローダーの手順またはコマンドラインの手順を使用して、コンテンツのバッチ・ロードを続行します。詳細は、「「バッチ・ローダー」ウィンドウからのバッチ・ロード」または「コマンドラインからのバッチ・ロード」を参照してください。

4.3.6 バッチ・ローダーの-consoleコマンドライン・スイッチ

-consoleスイッチをバッチ・ローダー・コマンドラインに追加することによって、HTMLコンテンツ・サーバー・ログおよびバッチ・ローダーを実行しているコンソール・ウィンドウに、すべてのアウトプットがエコーされます。または、オペレーティング・システムのリダイレクトを使用して、出力を別のログ・ファイルに送信できます。

注意:

-consoleスイッチは、標準的なWindowsコマンドライン構文に従っていません(ただし、これは、以降のバージョンで修正される可能性があります)。/console構文ではなく、通常はUNIXに関連付けられている-console構文を使用する必要があります。他のほとんどのコマンドライン・ユーティリティについては、両方の構文が両方のプラットフォームで機能します。

コマンドラインの例

• Windowsのコマンドライン:

  BatchLoader.exe -console -q -nc:/batching/batchinsert.txt
  

• UNIXのコマンドライン:

  BatchLoader -console -q -n/u2/apps/batching/batchinsert.txt

出力例

Processed 1 of 4 record.
Processed 2 of 4 records.
Processed 3 of 4 records.
Processed 4 of 4 records.
Done processing batch file 'c:/batching/batchinsert.txt'. Out of 4 records processed, 4 succeeded and 0 errors occurred.

4.3.7 リダイレクトの追加

コマンドラインでリダイレクト・シンボルを使用して、バッチ・ローダーの出力を別のログ・ファイルに送信できます。シンボルは、UNIXとWindowsの両方で機能します。デフォルトでは、-consoleスイッチは、バッチ・ローダーの出力をstderrに送信します。出力を別のファイルにリダイレクトするには、特別なリダイレクト・シンボル2>を使用します。

次の例では、各コマンドは、すべてを1行に入力する必要があります。

• Windowsのリダイレクトを含むコマンドライン:

  BatchLoader.exe -console -q -nc:/batching/batchinsert.txt 2> batchlog.txt
  

• UNIXのリダイレクトを含むコマンドライン:

  BatchLoader -console -q -n/u2/apps/batching/batchinsert.txt 2>
  /logs/CSbatchload.log

4.3.8 バッチ・ロード・エラーの修正

バッチ・ロード中に発生したエラーを修正するには:

1. 「管理」、「ログ・ファイル」、「Content Serverログ」の順に選択します。
2. コンテンツ・サーバーのログ・ファイルで、Type列のErrorという語句を調べます。
3. 説明を読んで、問題を判別します。
4. 次のファイルのうちの1つで、エラーを修正します。

   • バッチ・ロード・ファイル。

   • 失敗したコンテンツのエラー・ファイル。(このオプションは、「バッチ・ローダー」ウィンドウでそれが有効になっている場合にのみ使用できます。)エラー・ファイルは、バッチ・ロード・ファイル名にいくつかの数字が追加された名前で、バッチ・ロード・ファイルと同じディレクトリにあります。

     注意:

     バッチ・ロード・ファイル全体が返される場合、すでにチェックインされたコンテンツ・アイテムは、通常は失敗します。これが発生するのは、既存のコンテンツ・アイテムのリリース日が挿入しようとするものと同じになるためです。

図4-4 コンテンツ・サーバーのログ・ファイルの例

「図4-4 コンテンツ・サーバーのログ・ファイルの例」の説明

4.4 バッチ・ローダーのパフォーマンスの最適化

この項では、バッチ・ローダーのパフォーマンスを向上するために使用できる基本的なガイドラインを示します。次の提案は、大量のコンテンツ・アイテムをチェックインする際に、バッチ・ロードのパフォーマンスの潜在的な低下を最小限にすることができます。多くの場合、バッチ・ロードの適切なチューニングにより、遅いサーバーを大幅に高速化できます。

バッチ・ロードの低速化を最小限にするには、次のバッチ・ローダー調整を実装してみます。

• Inbound Refineryの停止(『Oracle WebCenter Contentのマネージメント』のOracle WebCenter Content ServerおよびInbound Refineryインスタンスの開始および停止に関する項を参照)やリポジトリ・マネージャの自動更新サイクル機能の一時停止など、他のアクティビティを一時的に無効にします。

• バッチ・ロード中のデータベース使用率を分析し、データベース問合せオプティマイザに役立てます。データベースには、データベース問合せをより効率的にするのに役立つ、組込みオプティマイザ・ユーティリティがあります。ただし、オプティマイザの効率を最大にするには、表とそれに関連する索引の物理特性に関する統計を、更新または再作成する必要があります。これらの特性には、レコード数、ページ数および平均レコード長などがあります。オプティマイザは、これらの統計を使用してデータにアクセスします。

  各データベースには、統計の更新や再作成プロセスを呼び出すのに使用できる独自のコマンドがあります。次に例を示します。

  • Oracleの場合、ANALYZE TABLE COMPUTE STATISTICSコマンドを使用します。

  • SQL Serverの場合、CREATE STATISTICS文を使用します。

  • DB2の場合、RUNSTATSコマンドを使用します。

4.5 ベスト・プラクティス事例

この事例では、非常に低速のロード・バッチのパフォーマンス、およびこの状況を診断および修正するために行った手順について説明します。この情報は、基礎となる問題を特定し、バッチ・ロードのパフォーマンスの問題を解決する際のモデルとしての役割を果たします。

• 背景情報

• 事前トラブルシューティング

• 解決策

4.5.1 背景情報

ユーザーは、AIXサーバー上で実行しているコンテンツ・サーバー・インスタンスに27,000コンテンツ・アイテムをロードしようとしていました。DB2データベースは、別のAIXサーバー上で実行していました。コンテンツ・アイテムには、ネイティブ・ファイルとしてTIFファイル、およびWeb表示可能ファイルとして対応するPDFファイルが含まれていました。Inbound Refineryはネイティブ・ファイルからサムネイルを生成しました。

最初は、バッチ・ロード中のパフォーマンスは許容可能なもので、挿入時間が1秒以内でした。しかし、数千コンテンツ・アイテムをロードした後で、パフォーマンスが低下し始めました。コンテンツ・アイテムのロードに数秒かかるようになり、最終的には、コンテンツ・アイテム当たりのロード時間が10秒以上になりました。

4.5.2 事前トラブルシューティング

バッチ・ロード・の実行中、コンテンツ・サーバー・インスタンスには問題がないと思われました。十分なメモリーがあり、CPU使用率は低く(5%未満)、ディスクのボトルネックもありませんでした。Inbound Refineryサーバーはビジーでしたが、許容できる速度でサムネイルを処理していました。

データベース・サーバーに次の2つの問題が見つかりました。

• 2つのプロセスが交代でデータベースを更新していました。1つ目のプロセスの実行中、2つ目のプロセスは、1つ目のプロセスのデータベース・ロックが解除されるのを待機していました。1つ目のプロセスが完了すると、2つ目のプロセスが実行され、その間、1つ目のプロセスは待機していました。この実行/待機のサイクルのプロセスは、次のとおりです。

  • コンテンツ・アイテムの挿入後にデータベース表を更新している実際のバッチ・ロード・プロセス。

  • コンテンツ・サーバー・インスタンスはデータベース表を更新しており、サムネイルが完了したという通知を受信した後で、ステータスがGENWWWからDONEに変更されます。

  この2つのプロセスは、同じコンテンツ・アイテムを更新していないため、互いに競合する必要がありません。DB2がロック・エスカレーションを実行し、単一の行ではなくデータベース・ページ全体をロックするようになっているため、2つのプロセスがお互いをロックしていたと思われます。

• 両方のプロセスによって、大量の表領域スキャンが実行されていました。

4.5.3 解決策

次の2ステップの解決策を使用しました。

1. Inbound Refineryを停止し、ステータス更新プロセスによって、バッチ・ロード・プロセスとの競合が発生しないようにしました。完了したサムネイルからのコンテンツ・アイテムのバックログが2000件増加されたため、パフォーマンスが向上しました。

2. すべてのコンテンツ・サーバー・データベース表に、RUNSTATSコマンドを発行し、表統計を更新しました。これにより、バッチ・ロードのパフォーマンスが大幅に向上しました。挿入時間は1秒以内に戻り、バッチ・ロードが短時間で完了しました。最初の22,000コンテンツ・アイテムの挿入には21時間かかりました。表統計の更新後は、残りの5000コンテンツ・アイテムは13分で挿入されました。