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

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

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

バッチ・ロードについて

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

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

ノート:

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

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

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

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

ノート:

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

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

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

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

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

挿入の要件

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

ノート:

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

挿入の例

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

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

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

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

削除の要件

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

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

削除の例

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

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

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

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

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

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

更新の要件

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

必須項目 フィールド長 継承 定義
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>> 該当なし 該当なし ファイル・レコードのデータの終端を示します。

更新の例1

この例では、次のメタデータを持つ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>>

更新の例2

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

コンテンツ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>>

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

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

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

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

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

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

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

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

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

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

マッピング・ファイル

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

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

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

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

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

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

値 説明 例
標準の文字列 すべてのファイルは、指定されたメタデータ値を持ちます。 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$>は、English-USロケールでは9/13/01 4:03 PMになります。
<$URL$> 物理ファイル・ルートおよび相対Webルートの値に基づいた、ファイルのURL。  

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

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

  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. 現在のバッチ・ロード・ファイルの設定をデフォルトとして保存するには、「オプション」、「構成の保存」の順に選択します。

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

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

  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. 「閉じる」をクリックして、バッチビルダー・マッピング・リスト・ウィンドウを閉じます。

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

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 なし 指定したファイルを含めます(「除外」チェック・ボックスを選択解除します)。

Windowsの例

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

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

UNIXの例

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

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

バッチ・ローダーの実行

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

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

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

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

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

  1. 「バッチ・ローダー」ウィンドウを開きます。

  2. 「参照」をクリックして、バッチ・ロード・ファイルにナビゲートし、選択します。

  3. バッチ・ローダーが処理を停止するまでに発生してもよいエラーの数を変更するには、「許容最大エラー数」フィールドに数字を入力します。

  4. ファイルを正常にチェックインまたは更新した後でハード・ドライブからファイルを削除するには、「チェックインが成功した後でファイルをクリーン・アップします。」を選択します。

  5. バッチ・ロード中に失敗したファイル・レコードを含むテキスト・ファイルを作成するには、「失敗したリビジョン・クラスに対してエラー・ファイルを有効にします。」を選択します。

  6. 「バッチ・ファイルのロード」をクリックして、バッチ・ローダー・プロセスを開始します。

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

  7. エラー・ファイルを有効化する場合、メッセージ・ボックスに表示されるファイル名を記録しておきます。

  8. 「OK」をクリックします。

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

  10. 現在のバッチ・ローダーの設定をデフォルトとして保存するには、「オプション」、「構成の保存」の順に選択します。

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

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

  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コマンドライン・スイッチ」を参照してください。

Windowsの例

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

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

UNIXの例

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

BatchLoader -q -n/batching/batchinsert.txt

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

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

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

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

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

バッチ・ロード・コマンド・ファイルには、ロードされる各ファイルのコマンドのセットが含まれています。大量のファイルをロードする場合、コマンド・ファイルが何百行にもなる可能性があります。編集ツールを使用すると、必要な多くの行を作成するタスクを単純化できます。たとえば、「リモートのバッチ・ロードの準備」の手順では、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>>

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

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

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

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

  1. Windowsエクスプローラを開きます。

  2. 作業ディレクトリ(たとえば、C:\working_dir)を作成します。

  3. 作業ディレクトリには、アクセスしているコンテンツ・サーバー・インスタンスの1つ以上のディレクトリ(C:\working_dir\developmentおよびC:\working_dir\contributionなど)を作成します。これらのディレクトリは、DomainHomeNameと呼ばれます。

  4. 各DomainHomeNameディレクトリに、cmdfilesサブディレクトリを作成します。

  5. リモートのコンテンツ・サーバー・インスタンスで、MW_HOME\user_projects\domains\Domain_Name\ucm\csからそれぞれのDomainHomeName(この場合はC:\working_dir\developmentおよび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. リモートのコンテンツ・サーバー・インスタンスを再起動します。

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

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

  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.
バッチ・ロード・コマンド・ファイルの作成

この手順では、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)

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

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

  1. コマンド・プロンプトを開きます。

  2. 作業binディレクトリにナビゲートします。

  3. 次のコマンドを発行します:

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

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

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

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

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

Please check record number <number>. BatchLoader: unable to check in '<record>' because the required field 'primaryFile' is missing.

コンテンツをメタデータとしてのみバッチ・ロードするには:

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

    IntradocDir/config/config.cfg

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

    createPrimaryMetaFile=true
AllowPrimaryMetaFile=true

  3. config.cfgファイルを保存して閉じます。

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

    primaryFile=
createPrimaryMetaFile=true

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

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

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

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

ノート:

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

コマンドラインの例

サンプル出力

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.

リダイレクトの追加

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

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

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

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

  1. 「管理」、「ログ・ファイル」、「Content Serverログ」の順に選択します。

  2. コンテンツ・サーバーのログ・ファイルで、Type列のErrorという語句を調べます。

  3. 説明を読んで、問題を判別します。

  4. 次のファイルのうちの1つで、エラーを修正します。

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

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

      ノート:

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

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

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

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

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

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

背景情報

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

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

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

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

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

解決策

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

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

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