| Oracle® Fusion Middleware Oracle WebCenter Contentの管理 11g リリース1 (11.1.1) B72425-03 |
|
 前 |
 次 |
この項では、バッチ・ローダー・ユーティリティを使用して、Oracle WebCenter Content Serverインスタンスで大量のファイルを同時にチェックイン(挿入)、削除および更新する方法を説明します。
この章の項目は次のとおりです。
大量のファイルのバッチ・ロードは、バッチ・ローダー・ユーティリティを使用して自動化することで、時間と労力を削減できます。バッチ・ローダーを使用する場合の例を次に示します。
WebCenter Contentソフトウェアを購入したばかりで、データベースに存在するメタデータを含むすべての既存のファイルをチェックインします。
コンテンツ・サーバー・リポジトリにチェックインされたドキュメントがあり、新規カスタム・メタデータ・フィールドを作成したばかりです。バッチ・ローダーを使用して、新規メタデータ・フィールドに指定する値を、既存の各コンテンツ・アイテムに追加できます。
特定の大量のファイルをシステムから削除します。
|
注意: バッチ・ローダー・ユーティリティがOracle WebLogic Serverインスタンスを使用して正しく機能するには、JDBC接続設定を構成する必要があります。第3.5.2項を参照してください。 |
バッチ・ローダーは、バッチ・ロード・ファイルで指定したアクションを実行します。このファイルは、バッチ・ローダーに実行するアクションと、バッチ内の各コンテンツ・アイテムに割り当てるメタデータを指示するテキスト・ファイルです。
この項の項目は次のとおりです。
バッチ・ロード・ファイルは、実行するアクションまたは個々のコンテンツ・アイテムに対するメタデータ(あるいはその両方)を指定する名前と値のペアのセットである、ファイル・レコードで構成されています。
|
重要: フィールド名およびパラメータは、大文字と小文字が区別されます。これらは、次の項で表示されているとおりに、バッチ・ロード・ファイルに表示される必要があります。たとえば、 |
各ファイル・レコードは、<<EOD>>(end of data)マーカーで終了します。
行頭にあるポンド記号(#)に続く空白は、コメントを示します。コメント記号の後には、空白を続ける必要があります。たとえば、# 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>>
バッチ・ロードの有効なアクションには、挿入、削除および更新があります。
ファイルにアクションが指定されていない場合、システムは更新を実行しようとします。
各ファイル・レコードには1つのアクションのみ存在しますが、同じバッチ・ロード・ファイルに異なるアクションを持つファイル・レコードが存在する可能性があります。
各アクションのロジック・プロセスは異なります。
挿入アクションでは、新規ファイルをコンテンツ・サーバー・リポジトリにチェックインします。図4-1は、挿入アクションを示しています。
コンテンツID (dDocName)がコンテンツ・サーバー・データベースに存在しない場合は、新規のファイルが作成されます。
コンテンツID (dDocName)がコンテンツ・サーバー・データベースに存在し、リビジョン(dRevLabel)が指定されていない場合は、新規のリビジョンが作成されます。
コンテンツID (dDocName)および指定したリビジョン(dRevLabel)がコンテンツ・サーバー・データベースに存在する場合、アクションは実行されません。
次の表では、挿入アクションが正常に動作するために必要なフィールドが定義されています。
|
注意: バッチ・ロードされたリビジョンは、アクティブ・ワークフローの基準を満たしている場合でも、ワークフローを入力しません。 |
フィールド長: フィールドで許可された最大文字数。
継承: 次のレコードにこのフィールドが含まれない場合、このフィールドの値は前のレコードから引き継がれます。
|
重要: カスタム・メタデータ・フィールドは、必須フィールドとして定義した場合、挿入アクションの際にも定義する必要があります。 |
| 必須項目 | フィールド長 | 継承 | 定義 |
|---|---|---|---|
|
Action=insert |
該当なし |
あり |
ファイルを挿入するコマンド。 Actionの語は大文字と小文字が区別され、最初は大文字にする必要があります。 |
|
dDocName |
30 |
なし |
「コンテンツID」という名前のメタデータ・フィールド。 |
|
dDocType |
30 |
あり |
「タイプ」という名前のメタデータ・フィールド。 |
|
dDocTitle |
80 |
なし |
「タイトル」という名前のメタデータ・フィールド。 |
|
dDocAuthor |
30 |
あり |
「作成者」という名前のメタデータ・フィールド。 |
|
dSecurityGroup |
30 |
あり |
「セキュリティ・グループ」という名前のメタデータ・フィールド。 |
|
primaryFile |
該当なし |
該当なし |
「プライマリ・ファイル」という名前のメタデータ・フィールド。プライマリ・ファイル名は、完全パスまたはファイル名そのものになります。ファイル名のみが指定されている場合、ファイルの場所は次のように決定されます。
デフォルトでは、プライマリ・ファイル名は80文字を超えることはできません(このうち、拡張子に使用できるのは最大8文字のみです)。 |
|
dInDate |
該当なし |
なし |
「リリース日」という名前のメタデータ・フィールド。
|
|
<<EOD>> |
該当なし |
該当なし |
ファイル・レコードのデータの終端を示します。 |
次のコード・フラグメントは、ファイルを挿入するためのバッチ・ロード・ファイルの構文を示しています。次の例では、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>>
削除アクションでは、既存のファイルの1つまたはすべてのリビジョンを、コンテンツ・サーバー・リポジトリから削除します。指定したコンテンツID (dDocName)がコンテンツ・サーバー・データベースに存在しない場合、アクションは実行されません。図4-2は、削除アクションを示しています。
次の表では、削除アクションが正常に動作するために必要なフィールドが定義されています。
| 必須項目 | 定義 |
|---|---|
|
Action=delete |
ファイルを削除するコマンド。 Actionの語は大文字と小文字が区別され、最初は大文字にする必要があります。 |
|
dDocName |
「コンテンツID」という名前のメタデータ・フィールド。 |
|
<<EOD>> |
ファイル・レコードのデータの終端を示します。 |
更新アクションでは、既存のコンテンツ・アイテムを更新します。ファイル・レコードに存在する項目およびシステムに存在するコンテンツに応じて、次のアクションのうちの1つが発生します。
既存のコンテンツ・アイテムの新規リビジョンが作成されます。
既存のファイルのメタデータが更新されます。
新規コンテンツ・アイテムが挿入されます(Action=insertが実行されます)。
|
注意: バッチ・ロードされたリビジョンは、アクティブ・ワークフローの基準を満たしている場合でも、ワークフローを入力しません。 |
次のシナリオのうち1つが発生すると、新規リビジョンが作成されます。
| シナリオ | コンテンツID (dDocName) | リビジョン(dRevLabel) | バッチ・ロード・ファイル内のリリース日(dInDate) |
|---|---|---|---|
|
シナリオ1 |
コンテンツ・サーバー・インスタンスに存在します。 |
バッチ・ロード・ファイルで指定されません。 |
システム内のファイルの最新リビジョンのリリース日の後。 |
|
シナリオ2 |
コンテンツ・サーバー・インスタンスに存在します。 |
バッチ・ロード・ファイルで指定されますが、コンテンツ・サーバー・インスタンスに存在しません。 |
システム内のファイルの最新リビジョンのリリース日の後。 |
次の表では、更新アクションが正常に動作するために必要なフィールドが定義されています。
| 必須項目 | フィールド長 | 継承 | 定義 |
|---|---|---|---|
|
Action=update |
該当なし |
あり |
ファイルを更新するコマンド。
|
|
dDocName |
30 |
なし |
「コンテンツID」という名前のメタデータ・フィールド。 |
|
dDocType |
30 |
あり |
「タイプ」という名前のメタデータ・フィールド。 |
|
dDocTitle |
80 |
なし |
「タイトル」という名前のメタデータ・フィールド。 |
|
dDocAuthor |
30 |
あり |
「作成者」という名前のメタデータ・フィールド。 |
|
dSecurityGroup |
30 |
あり |
「セキュリティ・グループ」という名前のメタデータ・フィールド。 |
|
primaryFile |
該当なし |
該当なし |
「プライマリ・ファイル」という名前のメタデータ・フィールド。 メタデータのみが更新されている場合、primaryFileフィールドは必須ではありませんが、dRevLabelは必須です。 オプションのdRevLabelフィールドが指定され、コンテンツ・サーバー・インスタンスに存在するリビジョン・ラベルと一致する場合、primaryFileフィールドは必須ではなく、そのリビジョンで指定されたプライマリ・ファイルが使用されます。 dRevLabelは必須フィールドではありませんが、primaryFileが存在しない場合、dRevLabelが必須フィールドになる点に注意することが重要です。 プライマリ・ファイル名は、完全パスまたはファイル名そのものになります。ファイル名のみが指定されている場合、ファイルの場所は次のように決定されます。
|
|
dInDate |
該当なし |
なし |
「リリース日」という名前のメタデータ・フィールド。
|
|
<<EOD>> |
該当なし |
該当なし |
ファイル・レコードのデータの終端を示します。 |
この例では、次のメタデータを持つ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>>
この例では、次のメタデータを持つ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>>
次の表は、バッチ・ロード・ファイル内のファイル・レコードで使用できるオプション・パラメータを示しています。
バッチ・ロード・ファイルでは、コンテンツ・アイテムのチェックインに割り当てられたプライマリ・フォーマットおよび代替フォーマットをオーバーライドするために、2つの方法があります。
primaryFile:formatパラメータの値を指定、またはalternateFile:formatパラメータの値を指定、あるいはその両方。ただし、primaryOverrideFormatパラメータまたはalternateOverrideFormatパラメータを使用して、これらの値をオーバーライドできます。コンポーネントを特定のタイプのチェックインで特定のフォーマットにしたり、別々のフォーマットにする特定のアプリケーション機能がいくつかのコンポーネントに存在するようにすることも可能です。
primaryOverrideFormatパラメータの値を指定、またはalternateOverrideFormatパラメータの値を指定、あるいはその両方。ただし、これらは、IsOverrideFormat構成変数を有効にする場合にバッチ・ロード・ファイルのパラメータとしてのみ機能します。この方法を使用すると、primaryFile:formatパラメータおよびalternateFile:formatパラメータに設定する値をオーバーライドすることに注意してください。
| オプション・パラメータ | 定義 |
|---|---|
|
dRevLabel |
「リビジョン」という名前のメタデータ・フィールド。 最大フィールド長は10文字です。 値は整数であるか、システム・プロパティ設定で設定されたメジャー/マイナー・リビジョンのラベル・シーケンスに準拠している必要があります。 |
|
dDocAccount |
「アカウント」という名前のメタデータ・フィールド。 最大フィールド長は30文字です。 このフィールドは、次のファイル・レコードに継承されません。 アカウントが有効になっていない場合は、このフィールドを指定しないでください。 アカウントが有効になっていて、このフィールドが指定されていない場合、dDocAccountは空の値に設定されます。 |
|
xComments |
「コメント」という名前のメタデータ・フィールド。最大フィールド長は255文字です。 |
|
dOutDate |
「有効期限」という名前のメタデータ・フィールド。
時間情報はオプションです。時間を指定する場合、 |
|
primaryFile:path |
ファイルの場所を指定します。 このパラメータでは、次の構文が使用されます。
|
|
primaryFile:format |
プライマリ・ファイルに使用するファイル形式を指定します。このファイル形式は、ファイルのファイル拡張子によって指定されたもの、および このパラメータでは、次の構文が使用されます。
|
|
alternateFile |
「代替ファイル」という名前のメタデータ・フィールド。代替ファイル名は、完全パスまたはファイル名そのものになります。ファイル名のみが指定されている場合、ファイルの場所は次のように決定されます。
|
|
alternateFile:path |
代替ファイルの場所を指定します。 このパラメータでは、次の構文が使用されます。
|
|
alternateFile:format |
代替ファイルに使用するファイル形式を指定します。このファイル形式は、ファイルのファイル拡張子によって指定されたもの、および このパラメータでは、次の構文が使用されます。
|
|
webViewableFile |
Web表示可能ファイル名は、完全パスまたはファイル名そのものになります。
|
|
webViewableFile:path |
Web表示可能ファイルの場所を指定します。 このパラメータでは、次の構文が使用されます。
|
|
webViewableFile:format |
Web表示可能ファイルに使用するファイル形式を指定します。このファイル形式は、ファイルのファイル拡張子によって指定されたもの、および このパラメータでは、次の構文が使用されます。
|
|
primaryOverrideFormat |
プライマリ・ファイルに使用するファイル形式を指定します。このファイル形式は、ファイルのファイル拡張子によって指定されたものをオーバーライドします。このオプションは、 |
|
alternateOverrideFormat |
代替ファイルに使用するファイル形式を指定します。このファイル形式は、ファイルのファイル拡張子によって指定されたものをオーバーライドします。このオプションは、 |
|
SetFileDir |
プライマリ・ファイルおよび代替ファイルがあるディレクトリを指定します。このフィールドは、次のファイル・レコードに継承されます。 |
構成マネージャに定義されている任意のカスタム・メタデータ・フィールドを、ファイル・レコードに含めることができます。
カスタム・メタデータ・フィールドは、必須フィールドとして定義した場合、挿入アクションや更新アクションの際に定義する必要があります。
カスタム・メタデータ・フィールドが必須フィールドではないが、空白であってもそれにデフォルト値がある場合、そのデフォルト値は、バッチ・ロード・ファイルで指定されていない場合は使用されます。
カスタム・メタデータ・フィールドの値を指定する際には、フィールド名の前にxを付けます。たとえば、Locationというカスタム・メタデータ・フィールドがある場合、バッチ・ロード・ファイル・エントリはxLocation=valueになります。
アドオン製品には、カスタム・メタデータ・フィールドを使用しているものがあることに注意してください。たとえば、PDF Watermarkがある場合、Watermarkというフィールドを作成します。このフィールドをバッチ・ロード・ファイルに含めるには、他のカスタム・メタデータ・フィールドと同様に、それの前にxを付けます(例: xWatermark)。
この項の項目は次のとおりです。
生成されるテキスト・ファイルがバッチ・ロード・ファイルの構文要件に従っていれば、希望する方法で、バッチ・ロード・ファイルを作成できます。ただし、バッチ・ローダーには、バッチ・ロード・ファイルを作成する際に役立つバッチビルダーというツールが用意されています。
バッチビルダーは、指定したディレクトリにあるファイルに基づいて、バッチ・ロード・ファイルを作成します。バッチビルダーは、バッチ・ロード・ファイルを作成するすべてのサブディレクトリ全体を再帰的に読み取ります。
マッピング・ファイルは、各ファイル・レコードのメタデータを決定する方法をバッチビルダーに説明します。バッチビルダーを使用して、カスタム・マッピング・ファイルを作成および保存できます。
バッチビルダーは、スタンドアロンのユーティリティ・インタフェースまたはコマンドラインから実行できます。
バッチビルダーは、コンテンツの外部コレクションを作成するために使用することもでき、これはコンテンツ・サーバー・データベース内ではなく別の検索コレクションに索引付けおよび格納されます。読取り専用の外部コレクションを設定でき、この場合、ユーザーは、コンテンツの検索はできますが、メタデータの更新やコンテンツの削除はできません。外部コンテンツが別のコンテンツ・サーバー・インスタンスにも含まれている場合に、このオプションをお薦めします。
バッチ・ローダー・ユーティリティを使用して、コンテンツ・サーバー・インスタンスで大量のファイルを同時に更新および挿入することを計画している場合は、バッチ・ロード・ファイルを作成する必要があります。バッチ・ロード・ファイルに含めることのできるオプション・パラメータの2つは、primaryOverrideFormatとalternateOverrideFormatです。ただし、これらのオプションは、IsOverrideFormat構成変数を有効にすると、バッチ・ロード・ファイルのパラメータとしてのみ動作します。この変数は、システム・プロパティ・ユーティリティを使用して設定できます。
マッピング・ファイルは、.hda拡張子を持つテキスト・ファイルで、コンテンツ・サーバー・インスタンスで使用されるデータ・ファイルのタイプで識別されます。
HDAファイル、LocalDataプロパティおよびResultSetsの詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentでの開発』を参照してください。
次の2つのうちの1つのフォーマットで、メタデータ・マッピングを定義できます。
LocalData定義での名前/値のペアの場合、マッピング・ファイルは次のようになります。
@Properties LocalData dDocName=<$filename$>.<$extension$> dInDate=<$filetimestamp$> @end
BatchBuilderMapping ResultSetの場合、マッピング・ファイルは次のようになります。
@ResultSet SpiderMapping 2 mapField mapValue dDocName <$filename$>.<$extension$> dInDate <$filetimestamp$> @end
マッピング・ファイルでは、次の値を使用できます。
| 値 | 説明 | 例 |
|---|---|---|
|
標準の文字列 |
すべてのファイルは、指定されたメタデータ値を持ちます。 |
すべてのファイルは、Documentコンテンツ・タイプになります。 |
|
Idocスクリプト |
任意のサポート済のIdocスクリプト。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentでの開発』を参照してください。 |
|
|
|
ファイルのパス内の指定したレベルのディレクトリ名。 |
dDocType=<$dir1$> dSecurityGroup=<$dir2$> dDocAccount=<$dir3$> ファイル・パスが
|
|
|
現在ログインしているユーザー。 |
dDocAuthor=<$dUser$>
|
|
|
ファイルのファイル拡張子。 |
dDocTitle=<$filename$>.<$extension$> ファイル・パスが |
|
|
ファイルの名前。 |
dDocName=<$filename$> ファイル・パスが |
|
|
ファイル名を含む、ファイルのディレクトリ・パス全体。 |
ファイル・パスが |
|
|
ファイルのサイズ(バイト単位)。 |
xFileSize=<$filesize$> 42KBのファイルの場合、 |
|
|
ファイルが最後に変更された日時。 |
dInDate=<$filetimestamp$> 最終変更日が2001年9月13日午後4時3分の場合、 |
|
|
物理ファイル・ルートおよび相対Webルートの値に基づいた、ファイルのURL。 |
「バッチビルダー」ウィンドウからバッチ・ロード・ファイルを作成するには:
バッチ・ローダー・ユーティリティを起動します。
Windows: 「スタート」、「プログラム」、「コンテンツ・サーバー」、instance_name、「ユーティリティ」、「バッチローダー」の順に選択します。
UNIX: DomainHome/ucm/cs/bin/ディレクトリに移動し、シェル・ウィンドウで「./BatchLoader」と入力して、キーボードで[RETURN]キーを押します。
ログイン・ウィンドウで、コンテンツ・サーバー管理者のユーザー名およびパスワードを入力し、「OK」をクリックします。
「バッチ・ローダー」ウィンドウで「オプション」を選択し、「バッチ・ファイルのビルド」をクリックします。
「バッチビルダー」ウィンドウの「ディレクトリ」フィールドに、バッチ・ロード・ファイルに含めるファイルの場所を入力します。
「バッチロード・ファイル」フィールドに、バッチ・ロード・ファイルのパスおよびファイル名を入力します。「参照」ボタンをクリックして、目的のディレクトリおよびファイルにナビゲートし、選択することができます。
マッピング・リストから、マッピング・ファイルを選択します。新規マッピング・ファイルの作成または既存のものの編集を行う場合は、第4.2.4項を参照してください。
オプション:「ファイル・フィルタ」フィールドに、特定のファイルをバッチ・ロード・ファイルに含めたり除外するフィルタ設定を入力します。
オプション: 読取り専用の外部コレクションをバッチ・ロードするには、「外部」を選択し、外部コレクションのオプションを選択します。
「ビルド」をクリックします。
ビルド・プロセスが完了したら、「OK」をクリックします。
バッチ・ロード・ファイルをテキスト・エディタで開き、ファイル・レコードを再確認します。
現在のバッチ・ロード・ファイルの設定をデフォルトとして保存するには、「オプション」、「構成の保存」の順に選択します。
マッピング・ファイルを作成するには:
「バッチビルダー」ウィンドウを開きます。
「マッピング」フィールドの横にある「編集」をクリックします。
バッチビルダー・マッピング・リスト・ウィンドウで、「追加」をクリックします。
「バッチビルダー・マッピングの追加」ウィンドウで、マッピング・ファイルの名前と説明を入力し、「OK」をクリックします。
「バッチビルダー・マッピングの編集」ウィンドウで、「追加」をクリックします。
「バッチビルダー・マッピング・フィールドの追加/編集」ウィンドウに、定義するメタデータ・フィールド名を入力します。たとえば、「コンテンツID」フィールドに「dDocName」と入力し、「コメント」フィールドに「xComments」と入力します。
メタデータ・フィールドの値を入力します。
任意の定数テキストおよびIdocスクリプトを「値」フィールドに直接入力します。たとえば、バッチ・ロード・ファイルのすべてのドキュメントのタイプに「Document」を設定するには、「フィールド」フィールドに「dDocType」と入力し、「値」フィールドに「Document」と入力します。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentでの開発』を参照してください。
事前定義済の変数を「値」フィールドに追加するには、右列で変数を選択し、「<<」ボタンをクリックします。たとえば、セキュリティ・グループに各ドキュメントの第2レベルのディレクトリを設定するには、「フィールド」フィールドに「dSecurityGroup」と入力し、「値」フィールドに<$dir1$>変数を挿入します。
|
注意: 事前定義済の変数を選択する際には注意してください。多くのメタデータ・フィールドには、長さの制限があり、空白や句読点などの特定の文字を含めることができません。『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のコンテンツの管理に関する項を参照してください。 |
「OK」をクリックします。
「OK」をクリックして、変更を保存し、「バッチビルダー・マッピングの編集」ウィンドウを閉じます。
マッピング・ファイルは、MapFileName.hdaという名前でIntradocDir/search/external/mapping/ディレクトリに保存されます。
「閉じる」をクリックして、バッチビルダー・マッピング・リスト・ウィンドウを閉じます。
BatchBuilderパラメータを、「バッチビルダー」ウィンドウから入力するのではなく、コマンドラインから入力することで、バッチ・ロード・ファイルを作成できます。コマンドラインからバッチ・ロード・ファイルを作成するには:
DomainHome/ucm/cs/bin/intradoc.cfgファイルをテキスト・エディタで開き、コンテンツ・サーバー・システム管理者のユーザー名がsysadminであることを示す次の行を追加します。
BatchLoaderUserName=sysadmin
これは、管理権限を持つユーザーのみがバッチ・ローダーおよびバッチビルダー・ユーティリティを実行する権限を持っているため、システム管理者としてシステムにログインするために必要です。
ファイルを保存して閉じます。
コマンドライン・ウィンドウを開き、DomainHome/ucm/cs/bin/ディレクトリに変更します。
|
注意: コンテンツ・サーバー・インスタンスを実行しているのと同じオペレーティング・システム・アカウントを使用して、バッチビルダーを実行します。そうでない場合、権限の問題が発生するため、ソフトウェアはデータを処理しません。 |
次のコマンドを入力します。
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のコマンドラインから実行する正しい構文を示しています。
ディレクトリ = c:/myfiles
マッピング・ファイル = MyMappingFile
バッチ・ロード・ファイル = c:/batching/batchinsert.txt
除外するファイル = *.exeおよび*.zip
BatchLoader.exe -spider -q -dc:/myfiles -mMyMappingFile -nc:/batching/batchinsert.txt -eexe,zip
この項の項目は次のとおりです。
バッチ・ローダーでは、コンテンツ・サーバー・インスタンスで大量のファイルを同時にチェックイン(挿入)、削除または更新するために、バッチ・ロード・ファイルの情報が使用されます。
バッチ・ローダーは、スタンドアロンのユーティリティ・インタフェースまたはコマンドラインから実行できます。
バッチ・ローダーの実行後に、コンテンツ・サーバー・インスタンスは、他のコンテンツ・アイテムの場合と同様に、Inbound Refineryインスタンスおよびインデクサを通じてファイルを処理します。
「バッチ・ローダー」ウィンドウを使用してコンテンツをバッチ・ロードするには:
「バッチ・ローダー」ウィンドウを開きます。
「参照」をクリックして、バッチ・ロード・ファイルにナビゲートし、選択します。
バッチ・ローダーが処理を停止するまでに発生してもよいエラーの数を変更するには、「許容最大エラー数」フィールドに数字を入力します。
ファイルを正常にチェックインまたは更新した後でハード・ドライブからファイルを削除するには、「チェックインが成功した後でファイルをクリーン・アップします。」を選択します。
バッチ・ロード中に失敗したファイル・レコードを含むテキスト・ファイルを作成するには、「失敗したリビジョン・クラスに対してエラー・ファイルを有効にします。」を選択します。
「バッチ・ファイルをロードします。」をクリックして、バッチ・ローダー・プロセスを開始します。
バッチ・ロード・プロセスが完了すると、「バッチ・ローダー」メッセージ・ウィンドウが開き、発生したエラー(ある場合)の数が示されます。
エラー・ファイルを有効化する場合、メッセージ・ボックスに表示されるファイル名を記録しておきます。
「OK」をクリックします。
バッチ・ロードでの問題を修正します。
現在のバッチ・ローダーの設定をデフォルトとして保存するには、「オプション」、「構成の保存」の順に選択します。
バッチ・ローダー・パラメータを、「バッチ・ローダー」ウィンドウから入力するのではなく、コマンドラインから入力することで、コンテンツをバッチ・ロードできます。コマンドラインからバッチ・ローダーを実行するには:
DomainHome/ucm/cs/bin/intradoc.cfgファイルをテキスト・エディタで開き、コンテンツ・サーバー・システム管理者のユーザー名がsysadminであることを示す次の行を追加します。
BatchLoaderUserName=sysadmin
これは、管理権限を持つユーザーのみがバッチ・ローダー・ユーティリティを実行する権限を持っているため、システム管理者としてシステムにログインするために必要です。
ファイルを保存して閉じます。
コマンドライン・ウィンドウを開き、DomainHome/ucm/cs/bin/ディレクトリに移動します。
|
注意: コンテンツ・サーバー・インスタンスを実行しているのと同じオペレーティング・システム・アカウントを使用して、バッチ・ローダーを実行します。そうでない場合、権限の問題が発生するため、ソフトウェアはファイルを処理しません。 |
次のコマンドを入力します。
Windows:
BatchLoader.exe -q -nbatchloadfile
UNIX:
BatchLoader -q -nbatchloadfile
バッチ・ローダーはバッチ・ロード・ファイルを処理しますが、メッセージ・ボックスは表示されません。
バッチ・ロードでの問題を修正します。
次のフラグは、コマンドラインからBatchLoaderコマンドで使用できます。
| フラグ | 必須? | 説明 |
|---|---|---|
|
-qまたは/q |
なし |
バッチ・ローダーを、バックグラウンドで消音モードで実行します。(このフラグを使用せずにバッチ・ローダーをコマンドラインから実行する場合、「バッチ・ローダー」ウィンドウが表示されます。) |
|
-nまたは/n |
あり |
「バッチロード・ファイル」フィールドの値。 |
|
-console |
なし |
HTML Content Serverログおよびバッチ・ローダーを実行しているコンソール・ウィンドウに、すべてのアウトプットがエコーされます。詳細は、第4.3.6項を参照してください。 |
次の例は、バッチ・ロード・ファイルがc:/batching/batchinsert.txtである場合の、バッチ・ローダーをWindowsのコマンドラインから実行する正しい構文を示しています。
BatchLoader.exe -q -nc:/batching/batchinsert.txt
コンテンツ・サーバー・インスタンスを管理する際に、リモート・アクセスを使用する必要がある場合があります。これは、必ずしもリモート・ターミナル・アクセスが必要であるということではありません。ただし、リモートの場所からサーバーにコマンドを発行できるようにする必要があります。
リモート・アクセスと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オペレーティング・システム用に記載されたもので、主なステージは次のとおりです。
ローカル・コンピュータの構成
リモート・ワークステーションの構成のテスト
バッチ・ロード・コマンド・ファイルの作成
アップロードの実行
ローカル・コンピュータを構成するには:
Windowsのエクスプローラを開きます。
作業ディレクトリ(たとえばC:\working_dirなど)を作成します。
作業ディレクトリには、アクセスしているコンテンツ・サーバー・インスタンスの1つ以上のディレクトリ(C:\working_dir\developmentおよびC:\working_dir\contributionなど)を作成します。これらのディレクトリは、DomainHomeNameと呼ばれます。
各DonainHomeNameディレクトリに、cmdfilesサブディレクトリを作成します。
リモートのコンテンツ・サーバー・インスタンスで、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
リモートのコンテンツ・サーバー・インスタンスから、次のディレクトリ(およびそのファイル)を作業ディレクトリにコピーします。
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
テキスト・エディタを使用して、DomainHomeName\ucm\cs\bin\intradoc.cfgファイルをローカル・システム上で開き、ディレクトリ構造に合うようにIntradocDir構成変数を更新します。次に例を示します。
IntradocDir=working_dir\DomainHomeName\ucm\cs, IdcHomeDir=working_dir\idc WeblayoutDir=working_dir\DomainHomeName\ucm\cs\weblayout
テキスト・エディタを使用して、working_dir\DomainHomeName\ucm\cs\config\config.cfgファイルをローカル・システム上で開き、次の設定が正しいことを確認します。
IntradocServerPort=4444
IntradocServerHostName=HostMachineName
リモートのコンテンツ・サーバー・インスタンスで、システム・プロパティ・ユーティリティを使用して、ローカル・コンピュータのIPアドレスをセキュリティ・フィルタに追加します。
リモートのコンテンツ・サーバー・インスタンスを再起動します。
リモート・ワークステーションの構成をテストするには:
cmdfilesディレクトリで、pingservertest.hdaという名前のファイルを作成し、次の行を追加します。
@Properties LocalData IdcService=PING_SERVER @end
コマンド・プロンプトを開き、作業binディレクトリに変更します(たとえば、cd C:\working_dir\development\bin)。
次のコマンドを発行します。
IdcCommand -f ..\cmdfiles\pingservertest.hda -u sysadmin -l ..\pingservertest.log -c server
出力内容を確認します。成功した場合、サーバーから次のメッセージが表示されます。
3/24/04: Success executing service PING_SERVER. You have completed your setup for remote commands.
この手順では、Microsoft Officeの編集およびメール・マージ機能を使用して、バッチ・ロード・コマンド・ファイルを作成します。バッチ・ロード・コマンド・ファイルを作成するには:
次のように、ディレクトリの内容をリストするファイルを作成します。
コマンド・プロンプトを開き、ロードするファイルを表すルート・ディレクトリに変更します。
出力内容をファイルにリダイレクトする次のコマンドを使用して、ファイル・リストを作成します。
dir /s /b > filelisting.txt
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文によって示されるサーバー上に、ファイルが存在する必要がある点に注意することが重要です。ファイルのディレクトリをサーバーとローカル・システムにマップする場合は、同じ文字を使用することが最適です。または、ファイルのディレクトリをサーバーに一時的にコピーできます。 |
次のように、ファイル・リストを編集して、ファイル名およびタイトル・データを作成します。
filelisting.txtファイルをExcelで開きます。
「置換」を使用して、ファイル名のみ残っているすべてのディレクトリ情報を削除します。また、filelisting.txtの行を検索し、削除します。
列A(ファイル名が格納されている)を列Bにコピーします。この例では、ファイル名はタイトルにも使用されており、列Bはタイトルになります。
「置換」を使用して、列Bの名前からファイル拡張子を削除します。
新しく1行目を挿入し、最初の列にfilename、2番目の列にtitleと入力します。
ファイルを保存します。
次のように、メール・マージ機能を使用して、ファイル・リストから.hdaファイルを作成します。
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>>
「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>>
メール・マージを終了し(ステップ5および6)、ページ当たり1つのマージ・レコードを含む新規Wordドキュメントが作成されます。
文字を編集し、すべてを選択し、置換機能を使用してすべてのセクション区切りを削除します。
ファイルを、拡張子がhdaのプレーン・テキスト・ファイルとして、/cmdfilesディレクトリに保存します(たとえばfilelisting.hda)
バッチ・ローダーを使用して実行するアクションに応じて、特定のフィールドがバッチ・ロード・ファイルで必須になります。既存のコンテンツ・アイテムでメタデータのみを更新している場合、「プライマリ・ファイル」フィールドはバッチ・ロードで必須ではありません。詳細は、第4.1.5.1項を参照してください。
ただし、コンテンツをコンテンツ・サーバー・インスタンスにメタデータとしてのみロード(挿入アクション)する場合、「プライマリ・ファイル」フィールドはバッチ・ロード・ファイルで必須になります。このフィールドはインポートで無視されますが、バッチ・ローダーではこれを定義することが要求されます。「プライマリ・ファイル」フィールドが見つからない場合、次のような(または類似した)エラーが表示されます。
レコード番号<number>を確認してください。バッチローダー: 必須フィールドprimaryFileが存在しないので<record>をチェックインできません。
コンテンツをメタデータとしてのみバッチ・ロードするには、次の手順を実行します。
次のように、コンテンツ・サーバー・インスタンスのconfig.cfgファイルを開きます。
IntradocDir/config/config.cfg
次の構成変数を追加します。
createPrimaryMetaFile=true AllowPrimaryMetaFile=true
config.cfgファイルを保存して閉じます。
バッチ・ロード・ファイルで、各レコードに対して次のフィールドを追加します。
primaryFile= createPrimaryMetaFile=true
primaryFileフィールドが空白のままであることは許容されることに注意してください。このフィールドは無視されますが、含める必要があります。
バッチ・ローダーの手順またはコマンドラインの手順を使用して、コンテンツのバッチ・ロードを続行します。詳細は、第4.3.2項または第4.3.3項を参照してください。
-consoleスイッチをバッチ・ローダー・コマンドラインに追加することによって、HTMLコンテンツ・サーバー・ログおよびバッチ・ローダーを実行しているコンソール・ウィンドウに、すべてのアウトプットがエコーされます。または、オペレーティング・システムのリダイレクトを使用して、出力を別のログ・ファイルに送信できます。
|
重要:
|
コマンドラインの例
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.
コマンドラインでリダイレクト・シンボルを使用して、バッチ・ローダーの出力を別のログ・ファイルに送信できます。シンボルは、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
バッチ・ロード中に発生したエラーを修正するには:
「管理」、「ログ・ファイル」、「Content Serverログ」の順に選択します。
コンテンツ・サーバーのログ・ファイルで、Type列のErrorという語句を調べます。
説明を読んで、問題を判別します。
次のファイルのうちの1つで、エラーを修正します。
バッチ・ロード・ファイル。
失敗したコンテンツのエラー・ファイル。(このオプションは、「バッチ・ローダー」ウィンドウでそれが有効になっている場合にのみ使用できます。)エラー・ファイルは、バッチ・ロード・ファイル名にいくつかの数字が追加された名前で、バッチ・ロード・ファイルと同じディレクトリにあります。
|
ヒント: バッチ・ロード・ファイル全体が返される場合、すでにチェックインされたコンテンツ・アイテムは、通常は失敗します。これが発生するのは、既存のコンテンツ・アイテムのリリース日が挿入しようとするものと同じになるためです。 |
この項では、バッチ・ローダーのパフォーマンスを向上するために使用できる基本的なガイドラインを示します。次の提案は、大量のコンテンツ・アイテムをチェックインする際に、バッチ・ロードのパフォーマンスの潜在的な低下を最小限にすることができます。多くの場合、バッチ・ロードの適切なチューニングにより、遅いサーバーを大幅に高速化できます。
バッチ・ロードの低速化を最小限にするには、次のバッチ・ローダー調整を実装してみます。
Inbound Refineryの停止(『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』を参照)、およびRepository Managerの自動更新サイクル機能の一時停止など、他のアクティビティを一時的に無効化します。
バッチ・ロード中のデータベース使用率を分析し、データベース問合せオプティマイザに役立てます。データベースには、データベース問合せをより効率的にするのに役立つ、組込みオプティマイザ・ユーティリティがあります。ただし、オプティマイザの効率を最大にするには、表とそれに関連する索引の物理特性に関する統計を、更新または再作成する必要があります。これらの特性には、レコード数、ページ数および平均レコード長などがあります。オプティマイザは、これらの統計を使用してデータにアクセスします。
各データベースには、統計の更新や再作成プロセスを呼び出すのに使用できる独自のコマンドがあります。次に例を示します。
Oracleの場合、ANALYZE TABLE COMPUTE STATISTICSコマンドを使用します。
SQL Serverの場合、CREATE STATISTICS文を使用します。
DB2の場合、RUNSTATSコマンドを使用します。
この事例では、非常に低速のロード・バッチのパフォーマンス、およびこの状況を診断および修正するために行った手順について説明します。この情報は、基礎となる問題を特定し、バッチ・ロードのパフォーマンスの問題を解決する際のモデルとしての役割を果たします。
ユーザーは、AIXサーバー上で実行しているコンテンツ・サーバー・インスタンスに27,000コンテンツ・アイテムをロードしようとしていました。DB2データベースは、別のAIXサーバー上で実行していました。コンテンツ・アイテムには、ネイティブ・ファイルとしてTIFファイル、およびWeb表示可能ファイルとして対応するPDFファイルが含まれていました。Inbound Refineryはネイティブ・ファイルからサムネイルを生成しました。
最初は、バッチ・ロード中のパフォーマンスは許容可能なもので、挿入時間が1秒以内でした。しかし、数千コンテンツ・アイテムをロードした後で、パフォーマンスが低下し始めました。コンテンツ・アイテムのロードに数秒かかるようになり、最終的には、コンテンツ・アイテム当たりのロード時間が10秒以上になりました。
バッチ・ロード・の実行中、コンテンツ・サーバー・インスタンスには問題がないと思われました。十分なメモリーがあり、CPU使用率は低く(5%未満)、ディスクのボトルネックもありませんでした。Inbound Refineryサーバーはビジーでしたが、許容できる速度でサムネイルを処理していました。
データベース・サーバーに次の2つの問題が見つかりました。
2つのプロセスが交代でデータベースを更新していました。1つ目のプロセスの実行中、2つ目のプロセスは、1つ目のプロセスのデータベース・ロックが解除されるのを待機していました。1つ目のプロセスが完了すると、2つ目のプロセスが実行され、その間、1つ目のプロセスは待機していました。この実行/待機のサイクルのプロセスは、次のとおりです。
コンテンツ・アイテムの挿入後にデータベース表を更新している実際のバッチ・ロード・プロセス。
コンテンツ・サーバー・インスタンスはデータベース表を更新しており、サムネイルが完了したという通知を受信した後で、ステータスがGENWWWからDONEに変更されます。
この2つのプロセスは、同じコンテンツ・アイテムを更新していないため、互いに競合する必要がありません。DB2がロック・エスカレーションを実行し、単一の行ではなくデータベース・ページ全体をロックするようになっているため、2つのプロセスがお互いをロックしていたと思われます。
両方のプロセスによって、大量の表領域スキャンが実行されていました。
次の2ステップの解決策を使用しました。
Inbound Refineryを停止し、ステータス更新プロセスによって、バッチ・ロード・プロセスとの競合が発生しないようにしました。完了したサムネイルからのコンテンツ・アイテムのバックログが2000件増加されたため、パフォーマンスが向上しました。
すべてのコンテンツ・サーバー・データベース表に、RUNSTATSコマンドを発行し、表統計を更新しました。これにより、バッチ・ロードのパフォーマンスが大幅に向上しました。挿入時間は1秒以内に戻り、バッチ・ロードが短時間で完了しました。最初の22,000コンテンツ・アイテムの挿入には21時間かかりました。表統計の更新後は、残りの5000コンテンツ・アイテムは13分で挿入されました。
