| Oracle® WebCenter Content Content Serverシステム管理者ガイド 11g リリース1 (11.1.1) B65037-02 |
|
 前 |
 次 |
この章では、Oracle WebCenter Content Server(コンテンツ・サーバー)のシステム・プロセスを継続的に管理する際の概念およびタスクについて説明します。内容は次のとおりです。
コンテンツ・サーバー・インスタンスを起動、停止および再起動する方法は、複数あります。どの方法を選択するかは、要件、認可、および実行するタスクに応じて異なります。たとえば、コンポーネントの有効化や無効化のタイミングなど、コンテンツ・サーバー・インスタンスに特定の構成変更を行う場合、コンテンツ・サーバー・インスタンスを再起動する必要があります。次の方法があります。
Oracle WebLogic Server管理コンソール
Oracle WebLogic Serverスクリプト
Oracle Enterprise Manager Fusion Middleware Control
|
注意: 以前のリリースでは、コンテンツ・サーバー・インスタンスの起動、停止および再起動に、コンテンツ・サーバーの管理サーバーを使用できました。他の機能は管理サーバーで管理できますが、この機能は11g リリース1(11.1.1)時点で移行されました。 |
手順については、次のトピックで説明しています。
コンテンツ・サーバー・インスタンスは、Oracle WebLogic ServerドメインのOracle WebCenter Content(WebCenter Content)サーバー上にインストールおよびデプロイする処理中に、最初に起動します。コンテンツ・サーバーの構成設定の変更時に、インスタンスの停止後に起動する場合など、別の時点でコンテンツ・サーバー・インスタンスを起動することが必要な場合があります。
コンテンツ・サーバー管理者は、コンテンツ・サーバー・インスタンスを使用してWebCenter Content Serverを管理する管理権限を持つ必要があるため、Oracle WebLogic Server管理コンソールを使用できます。コンテンツ・サーバー・インスタンスを使用してWebCenter Content Serverを起動するには、ノード・マネージャを構成し、実行している必要があります。
Oracle WebLogic Server管理コンソールを使用してコンテンツ・サーバーを起動するには、次の手順を実行します。
管理コンソール・ドメイン構造のナビゲーション・バーで、「環境」、「サーバー」の順に選択します。
「サーバーのサマリー」セクションの「変換」タブで、コンテンツ・サーバー・インスタンスのWebCenter Content Serverの名前を選択します。
「server_nameの設定」セクションで、「制御」タブをクリックします。
「サーバーのステータス」領域で、「起動」をクリックします。
詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Serverインスタンスの起動および停止に関する項を参照してください。
スクリプトを使用して、Oracle WebLogicサーバー上のアクションを迅速に実行できます。 アプリケーションの管理対象サーバーを起動する前に、Oracle WebLogic Serverドメインの管理サーバーを起動する必要があります。
次の例では、ソフトウェアのインストール・プロセスの一部としてコンテンツ・サーバー・インスタンスを事前に起動していることを前提としています。詳細は、Oracle WebCenter Contentインストレーション・ガイドの管理サーバーの起動および管理対象サーバーの起動に関する説明を参照してください。
|
注意: 次のスクリプト・コマンドは、WebCenter Content Serverを含むOracle WebLogic Server管理対象サーバー、および管理コンソールを含むOracle WebLogic Server管理サーバーを制御します。Oracle WebLogic Server管理サーバーを起動または停止しない場合、コンテンツ・サーバー・インスタンスを起動するための別の方法を使用します。 |
コンテンツ・サーバーをスクリプトを使用して起動するには、次の手順を実行します。
次のように、Oracle WebLogic Server管理コンソールを起動するスクリプトを実行してから、コンテンツ・サーバー・インスタンスを含むWebCenter Content Server(この例ではUCM_server1)を使用してOracle WebLogic Server管理対象サーバーを起動するスクリプトを実行します。
Windowsスクリプト:
MW_HOME\user_projects\domains\DOMAIN_HOME\bin\startWebLogic.sh MW_HOME\user_projects\domains\DOMAIN_HOME\bin\startManagedWebLogic.sh UCM_server1
UNIXスクリプト:
MW_HOME/user_projects/domains/DOMAIN_HOME/bin/startWebLogic.sh MW_HOME/user_projects/domains/DOMAIN_HOME/bin/startManagedWebLogic.sh UCM_server1
スクリプトに関する詳細は、『Oracle Fusion Middleware WebLogic Scripting Tool・コマンド・リファレンス』を参照してください。
管理者は、Oracle Enterprise Manager Fusion Middleware Controlを使用して、コンテンツ・サーバー・インスタンスを含むWebCenter Content Serverを実行しているOracle WebLogic Serverドメインなどの複数のドメインを管理できます。コンテンツ・サーバー・インスタンスを起動するこの方法によって、コンテンツ・サーバー・インスタンスがデプロイされるWebCenter Contentドメインに関する情報にアクセスすることもできます。
Fusion Middleware Controlを使用してコンテンツ・サーバーを起動するには、次の手順を実行します。
Fusion Middleware Controlのナビゲーション・ツリーで、適切なドメイン名(UCM_ucm_domainなど)を展開します。
「Oracle WebCenter Content」、「コンテンツ」、「コンテンツ・サーバー」の順に展開します。
コンテンツ・サーバー・インスタンス名(Oracle Universal Content Management - Content Server (UCM_server1)など)を選択します。コンテンツ・サーバー・インスタンスのホーム・ページが表示されます。
「コンテンツ・サーバー」メニューから、「制御」を選択し、次に「起動」を選択します。コンテンツ・サーバー・インスタンスが起動します。
詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Serverインスタンスの起動および停止に関する項を参照してください。
サーバー・コンポーネントの有効化や無効化などの構成を変更する場合など、様々な理由でコンテンツ・サーバー・インスタンスを停止できます。
コンテンツ・サーバー管理者は、コンテンツ・サーバー・インスタンスを管理する管理権限を持つ必要があるため、Oracle WebLogic Server管理コンソールを使用できます。コンテンツ・サーバー・インスタンスを使用してWebCenter Content Serverを停止するには、ノード・マネージャを構成し、実行している必要があります。
Oracle WebLogic Server管理コンソールを使用してコンテンツ・サーバーを停止するには、次の手順を実行します。
管理コンソール・ドメイン構造のナビゲーション・バーで、「環境」、「サーバー」の順に選択します。
「サーバーのサマリー」セクションの「変換」タブで、コンテンツ・サーバー・インスタンスのWebCenter Content Serverの名前を選択します。
「server_nameの設定」セクションで、「制御」タブをクリックします。
「サーバーのステータス」領域で、「停止」をクリックします。
詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Serverインスタンスの起動および停止に関する項を参照してください。
スクリプトを使用して、Oracle WebLogicサーバー上のアクションを迅速に実行できます。
|
注意: 次のスクリプト・コマンドは、WebCenter Content Serverを含むOracle WebLogic Server管理対象サーバー、および管理コンソールを含むOracle WebLogic Server管理サーバーを制御します。Oracle WebLogic Server管理サーバーを起動または停止しない場合、コンテンツ・サーバー・インスタンスを停止するための別の方法を使用します。 |
コンテンツ・サーバーをスクリプトを使用して停止するには、次の手順を実行します。
Oracle WebLogic Server管理対象サーバー上で、コンテンツ・サーバー・インスタンスを含むWebCenter Content Server(この例ではUCM_server1)を停止するスクリプトを実行します。次に、必要に応じて、Oracle WebLogic Server管理コンソールを停止する次のスクリプトを実行します。
Windowsスクリプト:
MW_HOME\user_projects\domains\DOMAIN_HOME\bin\stopManagedWebLogic.sh UCM_server1 MW_HOME\user_projects\domains\DOMAIN_HOME\bin\stopWebLogic.sh
UNIXスクリプト:
MW_HOME/user_projects/domains/DOMAIN_HOME/bin/stopManagedWeblogic.sh UCM_server1 MW_HOME/user_projects/domains/DOMAIN_HOME/bin/stopWebLogic.sh
スクリプトに関する詳細は、『Oracle Fusion Middleware WebLogic Scripting Tool・コマンド・リファレンス』を参照してください。
管理者は、Oracle Enterprise Manager Fusion Middleware Controlを使用して、コンテンツ・サーバー・インスタンスを含むWebCenter Content Serverを実行しているOracle WebLogic Serverドメインなどの複数のドメインを管理できます。コンテンツ・サーバー・インスタンスを停止するこの方法によって、コンテンツ・サーバー・インスタンスがデプロイされるWebCenter Contentドメインに関する情報にアクセスすることもできます。
Fusion Middleware Controlを使用してコンテンツ・サーバーを停止するには、次の手順を実行します。
Fusion Middleware Controlのナビゲーション・ツリーで、適切なドメイン名(UCM_ucm_domainなど)を展開します。
「Oracle WebCenter Content」、「コンテンツ」、「コンテンツ・サーバー」の順に展開します。
コンテンツ・サーバー・インスタンス名(Oracle Universal Content Management - Content Server (UCM_server1)など)を選択します。コンテンツ・サーバー・インスタンスのホーム・ページが表示されます。
「コンテンツ・サーバー」ページの「コンテンツ・サーバー」メニューから、「制御」の次に、「停止...」を選択します。コンテンツ・サーバー・インスタンスが停止します。
詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Serverインスタンスの起動および停止に関する項を参照してください。
サーバー・コンポーネントの有効化や無効化などの構成を変更する場合など、様々な理由でコンテンツ・サーバー・インスタンスを再起動できます。
コンテンツ・サーバー管理者は、コンテンツ・サーバー・インスタンスを管理する管理権限を持つ必要があるため、Oracle WebLogic Server管理コンソールを使用できます。コンテンツ・サーバー・インスタンスを使用してWebCenter Content Serverを停止および起動するには、ノード・マネージャを構成し、実行している必要があります。
Oracle WebLogic Server管理コンソールを使用してコンテンツ・サーバーを再起動するには、次の手順を実行します。
管理コンソール・ドメイン構造のナビゲーション・バーで、「環境」、「サーバー」の順に選択します。
「サーバーのサマリー」セクションの「変換」タブで、コンテンツ・サーバー・インスタンスのWebCenter Content Serverの名前を選択します。
「server_nameの設定」セクションで、「制御」タブをクリックします。
「サーバーのステータス」領域で、「停止」をクリックします。
コンテンツ・サーバー・インスタンスが停止していることを確認してから、「起動」をクリックします。
詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Serverインスタンスの起動および停止に関する項を参照してください。
スクリプトを使用して、Oracle WebLogicサーバー上のアクションを迅速に実行できます。
|
注意: 次のスクリプト・コマンドは、WebCenter Content Serverを含むOracle WebLogic Server管理対象サーバー、および管理コンソールを含むOracle WebLogic Server管理サーバーを制御します。Oracle WebLogic Server管理サーバーを起動または停止しない場合、コンテンツ・サーバー・インスタンスを再起動するための別の方法を使用します。 |
コンテンツ・サーバーをスクリプトを使用して再起動するには、次の手順を実行します。
WebCenter Content(この例ではUCM_server1)を含むOracle WebLogic Server管理対象サーバーを停止するスクリプトを実行します。次に、必要に応じて、Oracle WebLogic Server管理サーバーを停止するスクリプトを実行します。サーバーが停止すると、適切な場合、Oracle WebLogic Server管理サーバーを起動するスクリプトを実行してから、最後にWebCenter Contentを含むOracle WebLogic Server管理対象サーバーを起動するスクリプトを実行します。
Windowsスクリプト:
MW_HOME\user_projects\domains\DOMAIN_HOME\bin\stopManagedWeblogic.sh UCM_server1 MW_HOME\user_projects\domains\DOMAIN_HOME\bin\stopWeblogic.sh MW_HOME\user_projects\domains\DOMAIN_HOME\bin\startWeblogic.sh MW_HOME\user_projects\domains\DOMAIN_HOME\bin\startManagedWeblogic.sh UCM_server1
UNIXスクリプト:
MW_HOME/user_projects/domains/DOMAIN_HOME/bin/stopManagedWeblogic.sh UCM_server1 MW_HOME/user_projects/domains/DOMAIN_HOME/bin/stopWeblogic.sh MW_HOME/user_projects/domains/DOMAIN_HOME/bin/startWeblogic.sh MW_HOME/user_projects/domains/DOMAIN_HOME/bin/startManagedWeblogic.sh UCM_server1
スクリプトに関する詳細は、『Oracle Fusion Middleware WebLogic Scripting Tool・コマンド・リファレンス』を参照してください。
管理者は、Oracle Enterprise Manager Fusion Middleware Controlを使用して、コンテンツ・サーバー・インスタンスを含むWebCenter Contentを実行しているOracle WebLogic Serverドメインなどの複数のドメインを管理できます。コンテンツ・サーバー・インスタンスを停止および起動するこの方法によって、コンテンツ・サーバー・インスタンスがデプロイされるWebCenter Contentドメインに関する情報にアクセスすることもできます。
Fusion Middleware Controlを使用してコンテンツ・サーバーを再起動するには、次の手順を実行します。
ナビゲーション・ツリーで、適切なドメイン名(UCM_ucm_domainなど)を展開します。
「Oracle WebCenter Content」、「コンテンツ」、「コンテンツ・サーバー」の順に展開します。
コンテンツ・サーバー・インスタンス名(Oracle Universal Content Management - Content Server (UCM_server1)など)を選択します。コンテンツ・サーバー・インスタンスのホーム・ページが表示されます。
「コンテンツ・サーバー」ページの「コンテンツ・サーバー」メニューから、「制御」の次に、「停止...」を選択します。
コンテンツ・サーバー・インスタンスが停止していることを確認します。
「コンテンツ・サーバー」ページの「コンテンツ・サーバー」メニューから、「制御」の次に、「起動」を選択します。コンテンツ・サーバー・インスタンスが起動します。
詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Serverインスタンスの起動および停止に関する項を参照してください。
実行中のコンテンツ・サーバー・インスタンスにアクセスするには、Webブラウザを起動し、次のURLを入力します。
http://managedServerHost:managedServerPort/cs
managedServerHostには、コンテンツ・サーバー・インスタンスがインストールされたWebCenter ContentドメインのOracle WebLogic Server管理対象サーバーをホストするコンピュータの名前を指定します。managedServerPortには、コンテンツ・サーバー・インスタンスがインストールされたWebCenter ContentドメインのOracle WebLogic Server管理対象サーバーのリスニング・ポート番号を指定します。
Oracle WebLogic Serverの管理者ユーザー名とパスワードでログインします。コンテンツ・サーバー・インスタンスを含むWebCenter Contentのデフォルトのポート番号は、16200です。例:
http://myHost.example.com:16200/cs
この項には次のトピックが含まれます:
コンテンツ・サーバーの管理サーバーは、コンテンツ・サーバー・インスタンスのシステム全体の設定を構成できるWebページの集まりです。管理サーバーを使用する場合、次の制限に注意してください。
管理サーバーにアクセスするには、システム管理者またはsysmanagerロールを持つユーザーとしてログインする必要があります。
管理サーバーを使用してコンテンツ・サーバー・インスタンスを管理するには、ローカル・ファイル・システム上でインスタンスにアクセスできる必要があります。リモート・インスタンスがインストールされたドライブは、ローカル・ドライブにマップまたはマウントする必要があります。
管理サーバーは、このサーバーが管理するコンテンツ・サーバー・インスタンスと同じファイル・システム上で実行される必要があります。
11g リリース1(11.1.1)より前は、コンテンツ・サーバー・インスタンスの起動、停止および再起動に、管理サーバーを使用できました。デフォルトでは、Oracle WebLogic Server管理コンソールまたはFusion Middleware Controlによって、これらの機能を管理するようになりました。3.1項「コンテンツ・サーバーの起動、停止および再起動」を参照してください。
コンテンツ・サーバーの管理サーバーのJava出力を表示するには、次の手順を実行します。
「管理サーバー」ページを表示します。
「サーバー出力の表示」リンクをクリックします。
管理サーバーの出力画面が表示されます。
出力メッセージをリフレッシュするには、「リフレッシュ」をクリックします。出力メッセージをクリアするには、「クリア」をクリックします。
Content Server管理アプリケーションを、アプレットとして、またはスタンドアロン・モードで実行できます。スタンドアロン・モードでアプリケーションを実行するには、データベース接続の追加構成が必要になります。
Content Server管理アプリケーションには、コンテンツ・サーバー・インスタンスにアクセス可能な任意のWebブラウザからアプレットとして実行できるものがあります。アプレットは、リモート管理に役立ちます。
|
注意: バッチ・ローダー、コンポーネント・ウィザード、システム・プロパティおよびContent Serverアナライザの各ユーティリティは、アプレットとして実行できず、セキュリティ上の理由から、これらは、コンテンツ・サーバー・インスタンスがデプロイされているコンピュータから、スタンドアロン・モードで実行する必要があります。詳細は、「スタンドアロン・モードでの管理アプリケーションの実行」を参照してください。 アプリケーションのスタンドアロン・バージョンで使用可能な機能の一部は、アプレット・バージョンでは使用できません。詳細は、各アプリケーションのドキュメントを参照してください。 |
管理アプリケーションをJava対応のブラウザ内でJavaアプレットとして実行するには、次の手順に従ってください。
ブラウザ・ウィンドウを開きます。
コンテンツ・サーバー・インスタンスに管理者としてログインします。
「管理」を選択します。
「管理アプレット」を選択します。
アプレットのリストから管理アプリケーションを選択します。
コンテンツ・サーバー管理のJavaアプリケーションには、コンテンツ・サーバー・インスタンスがデプロイされているコンピュータからスタンドアロン・モードで実行できるものがあります。構成マネージャやリポジトリ・マネージャなどの一部のアプリケーションは、Webブラウザを使用してアクセスするアプレットと同じです。システム・プロパティやバッチ・ローダーなどの一部のアプリケーションは、スタンドアロン・モードでのみ実行できます。
アプリケーションのスタンドアロン版を実行することによって、ブラウザ・アプレットよりセキュリティが強力になり、パスワードをWebやネットワークで捕捉またはコピーされないように送信できるようになります。
|
重要: Content Server管理アプリケーションをスタンドアロン・モードで実行するには、Oracle WebLogic Serverでアプリケーションを認証してシステム・データベースへのJDBC接続を確立し、Oracle WebLogic Serverのデータベース接続情報にアクセスするための追加構成が必要です。「スタンドアロン・モード用のシステム・データベース・プロバイダの構成」および「スタンドアロン・モード用の外部データベース・プロバイダの構成」を参照してください。 スタンドアロン・アプリケーションが、認証にデジタル証明書を使用するSSL対応のデータベースに接続する必要がある場合は、信頼できるソースをチェックする際にそのアプリケーションが使用する標準Javaキー・ストアに、ルートCA証明書をインポートする必要があります。構成の詳細は、Oracle WebCenter Contentインストレーション・ガイドを参照してください。 |
スタンドアロン・モードでのみ実行できるContent Server管理アプリケーションおよびユーティリティは、WebCenter Contentを含むOracle WebLogic Serverドメインおよびコンテンツ・サーバー・インスタンスで実行するための特定の構成が必要です。アプリケーションでOracle WebLogic Serverユーザーを認証し、Oracle WebLogic Serverシステム・データベースへのJDBC接続を設定するように標準の(カスタマイズされていない)Oracle WebLogic Server接続の構成を変更する必要があります。
Oracle WebLogic Serverシステム・データベース接続を構成するには、次の手順を実行します。
システム管理者として、VNC(またはputtyやXmingなどの類似したツール)を使用して、DOMAIN_HOME/ucm/cs/binディレクトリにナビゲートします。例:
MW_HOME/user_projects/domains/ucm_domain/ucm/cs/bin
./SystemPropertiesを実行します。「システム・プロパティ」ウィンドウが表示されます。
「パス」タブでは、「データベース・ドライバ・クラスパスの指定」チェックボックスがデフォルトで選択されるため、「データベース・ドライバ・クラスパス」フィールドに、システム・データベースのJDBCドライバへのパスを入力する必要があります。Enterprise Content Managementのインストールで、Oracleドライバojdbc6dms.jarが、次のディレクトリに指定されます。
MW_HOME/oracle_common/modules/oracle.jdbc_11.1.1/ojdbc6dms.jar
「データベース」タブで、システム・データベースに対して必要なすべてのJDBC接続情報(データベース・タイプ、データベース・ユーザー名、データベース・ユーザー・パスワードなど)をフィールドに入力します。
「OK」をクリックします。
これで、スタンドアロン・アプリケーションを実行できます。たとえば、コンテンツ・サーバー・インスタンスで作成した管理者ユーザーとして、./BatchLoaderを実行します。
バッチ・ローダー・ユーティリティなど、スタンドアロン・モードのみで実行するアプリケーションを処理するコンテンツ・サーバー・インスタンスの場合、システム・データベースまたは外部データベース・プロバイダに対してJDBCドライバを構成する必要があります。コンテンツ・サーバー・スタンドアロン・アプリケーションをサポートするために、SQL ServerおよびDB2データベース用のOracle Fusion Middleware DataDirect JDBCドライバを使用できます。システム・プロパティ・ユーティリティを使用して、構成情報を入力できます。
システム管理者として、コンテンツ・サーバー・インスタンスのbinディレクトリから、./SystemPropertiesを実行します。
UNIXのパス:
DOMAIN_HOME/ucm/cs/bin/SystemProperties
Windowsのパス:
DOMAIN_HOME\ucm\cs\bin\SystemProperties
システム・プロパティ・ユーティリティが起動されます。
「システム・プロパティ」ページで、「データベース」タブをクリックすると、適切なドライバを選択し、接続文字列、ユーザー名およびパスワードを入力することができます。
クラスパスやドライバ名を入力する必要はありません。また、jarファイルをコピーする必要もありません。
Oracle WebLogic Server管理コンソールで、JDBC接続文字列およびユーザー名情報を検索できます。管理コンソールにログインし、「サービス」、「データ・ソース」、CSDS(またはURMDS)、「接続プール」の順に選択します。「接続プール」タブでは、接続文字列は「URL」フィールドにあり、ユーザー名は「プロパティ」フィールドにあります。セキュリティ上の理由から、パスワードは表示されません。
「データベース」タブで、適切なドライバを「JDBC (Java Database Connectivity) の使用」で選択し、接続文字列を入力します。
Microsoft SQL Serverの場合、「DataDirect SQL Server JDBCドライバ」を選択し、次の形式の接続文字列を入力します。
jdbc:weblogic:sqlserver://database_hostname:database_port_number;databaseName=database_name
IBM DB2の場合、「DataDirect DB2 JDBCドライバ」を選択し、次の形式の接続文字列を入力します。
jdbc:weblogic:db2://database_hostname:database_port_number;databaseName=database_name
データベースのユーザー名とパスワードを「JDBCユーザー名」および「JDBCユーザー・パスワード」フィールドに入力します。
「OK」をクリックします。
コンテンツ・サーバー・インスタンスを再起動します。
スタンドアロン・アプリケーションがOracle WebLogic Serverのデータ・ソースのシステム・データベース・プロバイダを使用せずにJDBCを使用してデータベースに直接接続できるように、コンテンツ・サーバー・インスタンスに外部データベース・プロバイダを作成できます。
スタンドアロン・アプリケーションでOracleTextSearch機能を使用するには、JDBC接続情報を含むように外部データベース・プロバイダを構成する必要があります。
デフォルトでは、受信プロバイダの構成にJDBC DriverおよびJDBC Connection Stringの値は含まれていません。これらの値を追加する必要がありますが、既存のプロバイダの名前は変更できないため、プロバイダ名を変更しないように注意してください。プロバイダ名を変更するには、プロバイダを削除して、再度追加する必要があります。
Content Server管理アプリケーションをUNIXオペレーティング・システム上でスタンドアロン・モードで実行するには、次の手順に従います。
DomainHome/ucm/cs/bin/ディレクトリにナビゲートします。実行可能なアプリケーションが一覧表示されます。
/application_nameと入力します。application_nameは、実行可能ファイルの名前です。アプリケーションが一覧表示されない場合は、IntradocAppアプリケーションへのパラメータとしてアプリケーション名を入力できます。次に例を示します。
DomainHome/bin/intradocApp workflow
[Enter]を押します。
コンポーネント・ウィザードおよびシステム・プロパティを除くすべてのアプリケーションでは、ログイン画面が表示されます。コンポーネント・ウィザードおよびシステム・プロパティでは、アプリケーションのメイン画面が表示されます。
管理者のログイン名とパスワードを入力します。
「OK」をクリックします。
アプリケーションのメイン画面が表示されます。
Content Server管理アプリケーションをWindowsオペレーティング・システム上でスタンドアロン・モードで実行するには、次の手順に従います。
Windowsの「スタート」メニューからアプリケーションまたはユーティリティを選択します。
管理アプリケーションを実行するには、「スタート」メニューから「プログラム」、「Oracle WebCenter Content Server」、コンテンツ・サーバー・インスタンスの順に選択し、対象のアプリケーションを選択します。
管理ユーティリティを実行するには、「スタート」メニューから「プログラム」、「Oracle WebCenter Content Server」、「ユーティリティ」の順に選択し、対象のユーティリティを選択します。
コンポーネント・ウィザードおよびシステム・プロパティを除くすべてのアプリケーションでは、ログイン画面が表示されます。コンポーネント・ウィザードおよびシステム・プロパティでは、アプリケーションのメイン画面が表示されます。ログイン画面またはアプリケーション画面が表示されるまで数秒かかることがあります。または、画面が他のウィンドウで隠れている場合があります。
管理者のログイン名とパスワードを入力します。
「OK」をクリックします。
アプリケーションのメイン画面が表示されます。
IdcShellツールを使用すると、管理者はコマンド・ラインからIdocスクリプトを実行できます。Idocスクリプトは、独自のサーバー側スクリプト言語です。
IdcShellツールには、追加のIdocスクリプト関数(表3-1を参照)、および一部の動的HTML定義(表3-2を参照)も含まれており、コンテンツ・サーバー・インスタンスやInbound Refineryインスタンスを管理する場合に役立ちます。
IdcShellツールにはヘルプが組み込まれており、次のコマンドを実行してアクセスできます。
bin/IdcShell "include shell_help"
この項の内容は次のとおりです。
この項では、コンテンツ・サーバー・システムの大量のファイルを同時にチェックイン(挿入)、削除または更新する、バッチ・ローダー・ユーティリティの使用方法について説明します。バッチ・ローダーでバッチ・ロード処理を自動化することによって、時間と労力を省くことができます。バッチ・ローダーを使用する場合の例を次に示します。
コンテンツ・サーバー・ソフトウェアを購入したばかりで、データベースに存在するメタデータを含むすべての既存のファイルをチェックインします。
コンテンツ・サーバー・リポジトリにチェックインされたドキュメントがあり、新規カスタム・メタデータ・フィールドを作成したばかりです。バッチ・ローダーを使用して、新規メタデータ・フィールドに指定する値を、既存の各コンテンツ・アイテムに追加できます。
特定の大量のファイルをシステムから削除します。
|
注意: バッチ・ローダー・ユーティリティがOracle WebLogic Serverインスタンスを使用して正しく機能するには、JDBC接続設定を構成する必要があります。3.4.2項「スタンドアロン・モードでの管理アプリケーションの実行」を参照してください。 |
バッチ・ローダーは、実行するアクションおよびバッチ内の各コンテンツ・アイテムのメタデータが説明されているテキスト・ファイルであるバッチ・ロード・ファイルで指定したアクションを実行します。
バッチ・ロード・ファイルは、実行するアクションおよびバッチ内で各コンテンツ・アイテムに割り当てるメタデータをバッチ・ローダーに知らせるテキスト・ファイルです。
この項の内容は次のとおりです。
バッチ・ロード・ファイルは、実行するアクションまたは個々のコンテンツ・アイテムに対するメタデータ(あるいはその両方)を指定する名前と値のペアのセットである、ファイル・レコードで構成されています。
|
重要: フィールド名およびパラメータは、大文字と小文字が区別されます。これらは、次の項で表示されているとおりに、バッチ・ロード・ファイルに表示される必要があります。たとえば、dDocNameは、ddocname、dDocnameまたはDDOCNAMEと同じではありません。 |
各ファイル・レコードは、<<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つのアクションのみ存在しますが、同じバッチ・ロード・ファイルに異なるアクションを持つファイル・レコードが存在する可能性があります。
各アクションのロジック・プロセスは異なります。
挿入アクションでは、新規ファイルをコンテンツ・サーバー・リポジトリにチェックインします。コンテンツID(dDocName)がコンテンツ・サーバー・データベースにすでに存在する場合、アクションは実行されません。図3-1は、挿入アクションを示しています。
次の表では、挿入アクションが正常に動作するために必要なフィールドが定義されています。
|
注意: バッチ・ロードされたリビジョンは、アクティブ・ワークフローの基準を満たしている場合でも、ワークフローを入力しません。 |
フィールド長: フィールドで許可された最大文字数。
継承: 次のレコードにこのフィールドが含まれない場合、このフィールドの値は前のレコードから引き継がれます。
|
重要: カスタム・メタデータ・フィールドは、必須フィールドとして定義した場合、挿入アクションの際にも定義する必要があります。 |
| 必須項目 | フィールド長 | 継承 | 定義 |
|---|---|---|---|
|
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)がコンテンツ・サーバー・データベースに存在しない場合、アクションは実行されません。図3-2は、削除アクションを示しています。
次の表では、削除アクションが正常に動作するために必要なフィールドが定義されています。
| 必須項目 | 定義 |
|---|---|
|
Action=delete |
ファイルを削除するコマンド。 Actionの語は大文字と小文字が区別され、最初は大文字にする必要があります。 |
|
dDocName |
「コンテンツID」という名前のメタデータ・フィールド。 |
|
<<EOD>> |
ファイル・レコードのデータの終端を示します。 |
更新アクションでは、既存のコンテンツ・アイテムを更新します。ファイル・レコードに存在する項目およびシステムに存在するコンテンツに応じて、次のアクションのうちの1つが発生します。
既存のコンテンツ・アイテムの新規リビジョンが作成されます。
既存のファイルのメタデータが更新されます。
新規コンテンツ・アイテムが挿入されます(Action=insertが実行されます)。
|
注意: バッチ・ロードされたリビジョンは、アクティブ・ワークフローの基準を満たしている場合でも、ワークフローを入力しません。 |
次のシナリオのうち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が必須フィールドになる点に注意することが重要です。 プライマリ・ファイル名は、完全パスまたはファイル名そのものになります。ファイル名のみが指定されている場合、ファイルの場所は次のように決定されます。
|
|
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文字です。 値は、整数であるか、「システム・プロパティ」設定で作成された「メジャー・リビジョンのラベル・シーケンス」または「マイナー・リビジョンのラベル・シーケンス」に従っている必要があります(4.1.2項「一般オプションの構成」を参照してください)。 |
|
dDocAccount |
「アカウント」という名前のメタデータ・フィールド。 最大フィールド長は30文字です。 このフィールドは、次のファイル・レコードに継承されません。 アカウントが有効になっていない場合は、このフィールドを指定しないでください。 アカウントが有効になっていて、このフィールドが指定されていない場合、dDocAccountは空の値に設定されます。 |
|
xComments |
「コメント」という名前のメタデータ・フィールド。最大フィールド長は255文字です。 |
|
dOutDate |
「有効期限」という名前のメタデータ・フィールド。 dOutDateは、バッチ・ローダーを実行しているユーザーのロケールの日付フォーマットを使用する必要があります。たとえば、米国英語の日付フォーマットは 時間情報はオプションです。時間を指定する場合、 |
|
primaryFile:path |
ファイルの場所を指定します。primaryFile:pathの値が指定されている場合、その値はprimaryFileパラメータに指定した値をオーバーライドします。ただし、primaryFile:pathの値は、ファイル変換フォーマットを決定するのに使用されません。primaryFile:pathの値が指定されていない場合、場所はprimaryFileの値から決定されます。 このパラメータでは、次の構文が使用されます。 primaryFile:path=complete_path |
|
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パラメータの値が指定されている場合はその値から決定されます。そうでない場合、デフォルトでは、primaryFileの値は計算に使用されます。 このパラメータでは、次の構文が使用されます。 webViewableFile:path=complete_path |
|
webViewableFile:format |
Web表示可能ファイルに使用するファイル・フォーマットを指定します。このファイル・フォーマットは、ファイルのファイル拡張子によって指定されたもの、およびwebViewableFileパラメータに指定した値をオーバーライドします。webViewableFile:formatの値が指定されていない場合、ファイル・フォーマットはwebViewableFileパラメータの値が指定されている場合はその値のファイル拡張子から決定されます。そうでない場合、デフォルトでは、primaryFileの値は計算に使用されます。 このパラメータでは、次の構文が使用されます。 alternateFile:format=application/conversion_type |
|
primaryOverrideFormat |
プライマリ・ファイルに使用するファイル・フォーマットを指定します。このファイル・フォーマットは、ファイルのファイル拡張子によって指定されたものをオーバーライドします。このオプションは、IsOverrideFormat構成変数を有効にする場合にパラメータとしてのみ機能します。この変数は、システム・プロパティ・アプリケーションでフォーマットのオーバーライドを許可を選択することで設定できます。しかし、そのかわりに、primaryFile:formatパラメータを使用することをお薦めします。 |
|
alternateOverrideFormat |
代替ファイルに使用するファイル・フォーマットを指定します。このファイル・フォーマットは、ファイルのファイル拡張子によって指定されたものをオーバーライドします。このオプションは、IsOverrideFormat構成変数を有効にする場合にパラメータとしてのみ機能します。この変数は、システム・プロパティ・アプリケーションでフォーマットのオーバーライドを許可を選択することで設定できます。しかし、そのかわりに、alternateFile:formatパラメータを使用することをお薦めします。 |
|
SetFileDir |
プライマリ・ファイルおよび代替ファイルがあるディレクトリを指定します。このフィールドは、次のファイル・レコードに継承されます。 |
構成マネージャに定義されている任意のカスタム・メタデータ・フィールドを、ファイル・レコードに含めることができます。
カスタム・メタデータ・フィールドは、必須フィールドとして定義した場合、挿入アクションや更新アクションの際に定義する必要があります。
カスタム・メタデータ・フィールドが必須フィールドではないが、空白であってもそれにデフォルト値がある場合、そのデフォルト値は、バッチ・ロード・ファイルで指定されていない場合は使用されます。
カスタム・メタデータ・フィールドの値を指定する際には、フィールド名の前にxを付けます。たとえば、Locationというカスタム・メタデータ・フィールドがある場合、バッチ・ロード・ファイル・エントリはxLocation=valueになります。
アドオン製品には、カスタム・メタデータ・フィールドを使用しているものがあることに注意してください。たとえば、PDF Watermarkがある場合、Watermarkというフィールドを作成します。このフィールドをバッチ・ロード・ファイルに含めるには、他のカスタム・メタデータ・フィールドと同様に、それの前にxを付けます(つまり、xWatermarkになります)。
この項の内容は次のとおりです。
生成されるテキスト・ファイルがバッチ・ロード・ファイルの構文要件に従っていれば、希望する方法で、バッチ・ロード・ファイルを作成できます。ただし、バッチ・ローダーには、バッチ・ロード・ファイルを作成する際に役立つバッチビルダーというツールが用意されています。
バッチビルダーは、指定したディレクトリにあるファイルに基づいて、バッチ・ロード・ファイルを作成します。バッチビルダーは、バッチ・ロード・ファイルを作成するすべてのサブディレクトリ全体を再帰的に読み取ります。
マッピング・ファイルは、各ファイル・レコードのメタデータを決定する方法をバッチビルダーに説明します。バッチビルダーを使用して、カスタム・マッピング・ファイルを作成および保存できます。
スタンドアロン・アプリケーション・インタフェースまたはコマンドラインから、バッチビルダーを実行できます。
バッチビルダーは、コンテンツの外部コレクションを作成するために使用することもでき、これはコンテンツ・サーバー・データベース内ではなく別の検索コレクションに索引付けおよび格納されます。読取り専用の外部コレクションを設定でき、この場合、ユーザーは、コンテンツの検索はできますが、メタデータの更新やコンテンツの削除はできません。外部コンテンツが別のコンテンツ・サーバー・インスタンスにも含まれている場合に、このオプションをお薦めします。
マッピング・ファイルは、.hda拡張子を持つテキスト・ファイルで、コンテンツ・サーバー・インスタンスで使用されるデータ・ファイルのタイプで識別されます。
HDAファイル、LocalDataプロパティおよびResultSetの詳細は、『Oracle WebCenter Content Content Server開発者ガイド』を参照してください。
次の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 WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。 |
|
|
|
ファイルのパス内の指定したレベルのディレクトリ名。 |
dDocType=<$dir1$> dSecurityGroup=<$dir2$> dDocAccount=<$dir3$> ファイル・パスが「f:/docs/public/sales/march.doc」で、「ディレクトリ」の値に「f:/docs」を指定した場合、値は次のようになります。
|
|
|
現在ログインしているユーザー。 |
dDocAuthor=<$dUser$> 「administrator」がログインしている場合、 |
|
|
ファイルのファイル拡張子。 |
dDocTitle=<$filename$>.<$extension$> ファイル・パスが「d:/salesdocs/sample.doc」の場合、 |
|
|
ファイルの名前。 |
dDocName=<$filename$> ファイル・パスが「d:/salesdocs/sample.doc」の場合、 |
|
|
ファイル名を含む、ファイルのディレクトリ・パス全体。 |
ファイル・パスが「c:/docs/public/acct/sample.doc」の場合、 |
|
|
ファイルのサイズ(バイト単位)。 |
xFileSize=<$filesize$> 42KBのファイルの場合、 |
|
|
ファイルが最後に変更された日時。 |
dInDate=<$filetimestamp$> 最終変更日が2001年9月13日午後4時3分の場合、 |
|
|
物理ファイル・ルートおよび相対Webルートの値に基づいた、ファイルのURL。 |
「バッチビルダー」画面からバッチ・ロード・ファイルを作成するには、次の手順を実行します。
次のように、バッチローダー・ユーティリティを起動します。
Windowsオペレーティング・システムの場合:
「スタート」、「プログラム」、「コンテンツ・サーバー」、instance_name、「ユーティリティ」、「バッチローダー」の順に選択します。
UNIXオペレーティング・システムの場合:
DomainHome/ucm/cs/binディレクトリに移動し、シェル・ウィンドウで「BatchLoader」と入力して、[RETURN]キーを押します。
ログイン画面が表示されます。
コンテンツ・サーバー管理者のユーザー名およびパスワードを入力し、「OK」をクリックします。
「バッチ・ローダー」画面が表示されます。
「オプション」の次に、「バッチ・ファイルのビルド」を選択します。
「バッチビルダー」画面が表示されます。
「ディレクトリ」フィールドに、バッチ・ロード・ファイルに含めるファイルの場所を入力します。
「バッチロード・ファイル」フィールドに、バッチ・ロード・ファイルのパスおよびファイル名を入力します。「参照」ボタンをクリックして、目的のディレクトリおよびファイルにナビゲートし、選択することができます。
マッピング・リストから、マッピング・ファイルを選択します。新規マッピング・ファイルの作成または既存のものの編集を行う場合は、3.6.2.4項「マッピング・ファイルの作成」を参照してください。
オプション: 「ファイル・フィルタ」フィールドに、特定のファイルをバッチ・ロード・ファイルに含めたり除外したりするフィルタ設定を入力します。
オプション: 読取り専用の外部コレクションをバッチ・ロードするには、「外部」を選択し、外部コレクションのオプションを選択します。
「ビルド」をクリックします。
ビルド・プロセスが完了したら、「OK」をクリックします。
バッチ・ロード・ファイルをテキスト・エディタで開き、ファイル・レコードを再確認します。
現在のバッチ・ロード・ファイルの設定をデフォルトとして保存するには、「オプション」、「構成の保存」の順に選択します。
マッピング・ファイルを作成するには、次の手順を実行します。
「バッチビルダー」画面を表示します。
「マッピング」フィールドの横にある「編集」をクリックします。
バッチビルダー・マッピング・リスト画面が表示されます。
「追加」をクリックします。
バッチビルダー・マッピングの追加画面が表示されます。
マッピング・ファイルの名前および説明を入力して、「OK」をクリックします。
バッチビルダー・マッピングの編集画面が表示されます。
「追加」をクリックします。
定義するメタデータ・フィールドの名前を入力します。たとえば、「コンテンツID」フィールドに「dDocName」と入力し、「コメント」フィールドに「xComments」と入力します。
メタデータ・フィールドの値を入力します。
任意の定数テキストおよびIdocスクリプトを「値」フィールドに直接入力します。、たとえば、バッチ・ロード・ファイルのすべてのドキュメントのタイプに「Document」を設定するには、「フィールド」フィールドに「dDocType」と入力し、「値」フィールドに「Document」と入力します。詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。
事前定義済の変数を「値」フィールドに追加するには、右列で変数を選択し、「<<」ボタンをクリックします。たとえば、セキュリティ・グループに各ドキュメントの第2レベルのディレクトリを設定するには、「フィールド」フィールドに「dSecurityGroup」と入力し、「値」フィールドに<$dir1$>変数を挿入します。
|
注意: 事前定義済の変数を選択する際には注意してください。多くのメタデータ・フィールドには、長さの制限があり、空白や句読点などの特定の文字を含めることができません。詳細は、Oracle WebCenter Content Content Serverアプリケーション管理者ガイドのリポジトリ・コンテンツの管理に関する説明を参照してください。 |
「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 and *.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 Oracle WebCenter Content Serverログおよびバッチ・ローダーを実行しているコンソール・ウィンドウに、すべての出力がエコーされます。詳細は、3.6.3.6項「バッチ・ローダーの-consoleコマンドライン・スイッチ」を参照してください。 |
次の例は、バッチ・ロード・ファイルが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 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サブディレクトリを作成します。
リモートのコンテンツ・サーバー・インスタンスで、Middleware\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
リモートのコンテンツ・サーバー・インスタンスから、次のディレクトリ(およびそのファイル)を作業ディレクトリにコピーします。
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
リモートのコンテンツ・サーバー・インスタンスで、SystemsPropertiesユーティリティを使用して、ローカル・コンピュータの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行目を挿入し、最初の列に「ファイル名」、2番目の列に「タイトル」と入力します。
ファイルを保存します。
次のように、メール・マージ機能を使用して、ファイル・リストから.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)
次のように、アップロードを実行します。
コマンド・プロンプトを開きます。
作業binディレクトリにナビゲートします。
次のコマンドを発行します。
IdcCommand -f ../cmdfiles/filelisting.hda -u sysadmin -l ../filelisting.log -c server
ファイルはコンテンツ・サーバー・リポジトリにチェックインされ、各ファイルがチェックインされる際に、コマンド・ウィンドウにメッセージが表示されます。
バッチ・ローダーを使用して実行するアクションに応じて、特定のフィールドがバッチ・ロード・ファイルで必須になります。既存のコンテンツ・アイテムでメタデータのみを更新している場合、primaryFileフィールドはバッチ・ロードで必須ではありません。3.6.1.5.1項「更新の要件」を参照してください。
ただし、コンテンツをコンテンツ・サーバー・インスタンスにメタデータとしてのみロード(挿入アクション)する場合、primaryFileフィールドはバッチ・ロード・ファイルで必須になります。このフィールドはインポートで無視されますが、バッチ・ローダーではこれを定義することが要求されます。primaryFileフィールドが見つからない場合、次のような(または類似した)エラーが表示されます。
レコード番号<number>を確認してください。バッチローダー: 必須フィールドprimaryFileが存在しないので<record>をチェックインできません。
コンテンツをメタデータとしてのみバッチ・ロードするには、次の手順を実行します。
次のように、コンテンツ・サーバー・インスタンスのconfig.cfgファイルを開きます。
IntradocDir/config/config.cfg
次の構成変数を追加します。
createPrimaryMetaFile=true AllowPrimaryMetaFile=true
config.cfgファイルを保存して閉じます。
バッチ・ロード・ファイルで、各レコードに対して次のフィールドを追加します。
primaryFile= createPrimaryMetaFile=true
primaryFileフィールドが空白のままであることは許容されることに注意してください。このフィールドは無視されますが、含める必要があります。
バッチ・ローダーの手順またはコマンドラインの手順を使用して、コンテンツのバッチ・ロードを続行します。3.6.3.2項「「バッチ・ローダー」画面からのバッチ・ロード」または3.6.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
バッチ・ロード中に発生したエラーを修正するには、次の手順を実行します。
Oracle WebCenter Content Serverログを開きます。「管理」、「ログ・ファイル」、「Content Serverログ」の順に選択します。
「タイプ」列から、「Error」という単語を探します。
説明を読んで、問題を判別します。
次のファイルのうちの1つで、エラーを修正します。
バッチ・ロード・ファイル。
失敗したコンテンツのエラー・ファイル。(このオプションは、「バッチ・ローダー」画面でそれが有効になっている場合にのみ使用できます。)エラー・ファイルは、バッチ・ロード・ファイル名にいくつかの数字が追加された名前で、バッチ・ロード・ファイルと同じディレクトリにあります。
|
ヒント: バッチ・ロード・ファイル全体が返される場合、すでにチェックインされたコンテンツ・アイテムは、通常は失敗します。これが発生するのは、既存のコンテンツ・アイテムのリリース日が挿入しようとするものと同じになるためです。 |
この項では、バッチ・ローダーのパフォーマンスを向上するのに使用できる基本的なガイドラインを示します。次の提案は、大量のコンテンツ・アイテムをチェックインする際に、バッチ・ロードのパフォーマンスの潜在的な低下を最小限にすることができます。多くの場合、バッチ・ロードの適切なチューニングにより、遅いサーバーを大幅に高速化できます。
バッチ・ロードの低速化を最小限にするには、次のバッチ・ローダー調整を実装してみます。
Inbound Refineryの停止(『Oracle WebCenter Content Conversion管理者ガイド』を参照)、およびリポジトリ・マネージャの自動更新サイクル機能の一時停止など、他のアクティビティを一時的に無効化します。A.1.3.1項「リポジトリ・マネージャ: 「インデクサ」タブ」を参照してください。
バッチ・ロード中のデータベース使用率を分析し、データベース問合せオプティマイザに役立てます。データベースには、データベース問合せをより効率的にするのに役立つ、組込みオプティマイザ・ユーティリティがあります。ただし、オプティマイザの効率を最大にするには、表とそれに関連する索引の物理特性に関する統計を、更新または再作成する必要があります。これらの特性には、レコード数、ページ数および平均レコード長などがあります。オプティマイザは、これらの統計を使用してデータにアクセスします。
各データベースには、統計の更新や再作成プロセスを呼び出すのに使用できる独自のコマンドがあります。例:
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分で挿入されました。
効果的なトラブルシューティングは、有益で詳細な情報を利用できるかどうかに左右されます。コンテンツ・サーバー製品は、トラブルシューティング・プロセスで役立つ様々な情報のソースを提供します。
この項の内容は次のとおりです。
コンテンツ・サーバー・インスタンスにより、ステータス情報およびエラーがログ・ファイルに格納されます。ログ・ファイルは、システム・イベントをその発生日時とともに登録するのに使用されます。これは、詳細ロギングがオンになっている場合は特に、トラブルシューティングの際に有益なツールとなります。ログは、特定のイベントが発生したことを示すだけではなく、エラーや問題を引き起こすイベントの連鎖に関する重要な手がかりも提供します。
OracleログAPIを使用して、Oracle WebLogic Server管理コンソールによって制御されたログにも、情報が取得されます。WebCenter Contentインタフェースを使用して、これらのログにアクセスできます。詳細は、2.6項「コンテンツ・サーバーのログ情報の表示」を参照してください。
この項の内容は次のとおりです。
コンテンツ・サーバー・インスタンス関連のログ・ファイルには、次の特性があります。
最初のステータス、エラーまたはリカバリ不能なエラーが発生した際に、1日に1回のみ作成されます。
空のログ・ファイルは生成されません。
各ログ・ファイルには、次の列があります。
タイプ: ログ・エントリを求められるインシデントの種類(情報、エラーまたは致命的)を指定します。
時間: ログ・エントリが発生した日時を示します。
説明: 発生したインシデントを説明します。
ログ・ファイルは標準的なHTMLページで、コンテンツ・サーバー・インスタンスごとに保持されます。ログは、回転するファイル名形式で、最大30ファイルまで保持されます。31番目のファイルが作成されると、最も古いものが削除されます。そのため、コンテンツ・サーバーのログ・ファイル名は、生成された日付と関係がありません。ログ・ファイルで特定の日付を検索するには、ブラウザで索引ファイルを表示し、その日付のリンクを選択します。ファイル名は、ブラウザのステータス・バー(有効な場合)に表示されます。
|
ヒント: ログ・ファイル・ページをブックマークします。これを行うと、コンテンツ・サーバー・インスタンスが使用できない場合でも、問題のトラブルシューティングに役立ちます。また、コンテンツ・サーバー・インスタンスが使用できない場合に見つけられるように、構成ファイルがある場所を理解しておいてください。 |
コンテンツ・サーバー・インスタンスのログ・ファイルには、通常、「管理」トレイの「ログ・ファイル」フォルダからアクセスします。
|
注意: ログ・ファイルを表示できるように、コンテンツ・サーバー・インスタンスに管理者としてログインする必要があります。 |
なんらかの理由で「管理」トレイからログ・ファイルを表示できない場合でも、コンテンツ・サーバー・インスタンスのファイル・システム上でそれにアクセスすることもできます。ログ・ファイルは次の場所にあります。
コンテンツ・サーバー・ログは、日時別にリストされます。1日に1ファイルが生成されます。エントリは、イベントの発生に従って終日にわたりファイルに追加されます。
情報: 基本的なステータス情報を表示します。たとえば、サーバーが準備完了して待機中である場合、ステータス情報が記録されます。
エラー: 発生してもソフトウェアの機能が停止しないエラーを表示します。たとえば、ユーザーが、アクセスが許可されていないセキュリティ保護された情報をリクエストすると、エラーが記録されます。
致命的: 発生するとソフトウェアの機能が停止するエラーを表示します。たとえば、コンテンツ・サーバー・インスタンスがデータベースにアクセスできない場合、致命的エラーが記録されます。
コンテンツ・サーバー・ログを開くには
サーバー・ログを開くには、次の手順を実行します。
コンテンツ・サーバー・インスタンスに、必ず管理者としてログインするようにしてください。
「管理」ページか「管理」トレイの「ログ・ファイル」フォルダで、「Content Serverログ」をクリックします。
「Content Serverログ」画面が表示されます。
表示するログの日時に対応するリンクを選択します。
アーカイバ・ログには、インポート、エクスポートおよびレプリケーションに関する情報が表示されます。アーカイバ・ログは、日時別にリストされます。最初の「アーカイバ」情報ステータス、致命的エラーまたはエラーが発生した際に、1日に1回生成されます。
次のアーカイバ・ログ・エントリのタイプが生成されます。
情報: 基本的なステータス情報を表示します。たとえば、エクスポートおよびインポートが開始および終了する際に、ステータス情報が記録されます。
エラー: 発生してもソフトウェアの機能が停止しないユーザー/管理エラーを表示します。たとえば、エクスポートしようとするコンテンツ・アイテムのファイル情報がない場合、エラーが記録されます。
致命的: 発生するとソフトウェアの機能が停止するエラーを表示します。たとえば、コンテンツ・サーバー・インスタンスがデータベースにアクセスできない場合、致命的エラーが記録されます。接続文字列、ユーザー名およびパスワードを確認します。
アーカイバ・ログを開くには
コンテンツ・サーバー・インスタンスに、必ず管理者としてログインするようにしてください。
「管理」ページか「管理」トレイの「ログ・ファイル」フォルダにある、「アーカイバ・ログ」リンクをクリックします。
「アーカイバ・ログ」画面が表示されます。
ログの日時に対応するリンクを選択します。
各アクションのタイプ、日時および説明を示している表が表示されます。これには、アーカイブを作成したコンテンツ・サーバー・インスタンスの名前も含まれます。
WebCenter Contentシステムでは、コンテンツ・サーバー・インスタンスの構成情報を表示する「構成情報」ページが提供されており、問題のトラブルシューティングやOracleサポート組織で作業する際に役立ちます。このページにアクセスするには、「管理」、「構成」の順に選択して、インスタンスを選択します。詳細を表示するには、各構成情報のタイプのリンクをクリックします。
次の構成情報があります。
サーバー名
バージョン
クラス・ローダー
インスタンス・ディレクトリ
データベース・タイプ
データベース・バージョン
HTTPサーバー・アドレス
メール・サーバー
検索エンジン名
索引エンジン名
インストール済の機能の数
有効なコンポーネントの数
無効なコンポーネントの数
自動採番接頭辞
アカウントを使用
NTLMセキュリティは有効です
読取り特権を持つユーザーである場合にコピーを許可する
元のコントリビュータにのみチェックアウトを許可する
Javaバージョン
|
注意: オプションには、ソフトウェアのインストール中に指定されるものもありますが、「システム・プロパティ」ユーティリティを使用して設定されるものもあります。 |
WebCenter Contentシステムでは、コンテンツ・サーバー・インスタンスの「システム監査情報」ページが提供されており、問題のトラブルシューティングやサーバーのパフォーマンスの調整の際に役立ちます。このページにアクセスするには、「管理」、「システム監査情報」の順に選択します。
「システム監査情報」ページには、次の情報のタイプがあります。
「システム監査情報」ページの「一般的な情報」セクションで提供されるものは、次のとおりです。
受信するリクエストの数が多すぎるかどうかに関する情報。受信するリクエストの数が多すぎる場合、ロード・パフォーマンスに関する電子メールがシステム管理者に送信されます。
システムのメモリー・キャッシュに関する情報。メモリー不足に関するエラーのトラブルシューティングに役立ちます。また、ユーザー数とデータ量が多いコンテンツ・サーバー・インスタンスを実行しているときに重要となる情報です。
現在実行中のJavaスレッドに関する情報。この情報はエラーの原因を特定する場合に有用です。
データベース・アクティビティに関する情報。
監査メッセージのリスト。
詳細を表示するには、構成情報のタイプのページでリンクをクリックします。
「システム監査情報」ページの「ローカライズ情報」セクションで提供される情報は、次のとおりです。
文字列キー・カウント
ローカライズ・システムが文字列索引を使用しているかどうか
ローカライズ・テスト実行時間
ローカライズ・テスト1秒当たりの参照
「システム監査情報」ページの「トレース・セクション情報」セクションでは、コンテンツ・サーバー・インスタンス内のトレースを有効にし、セクションごとにアクティブ化できます。アクティブなセクションのトレースが、サーバー出力ページに表示されます。セクション・トレースは、サーバーのどのセクションが問題の原因となっているかを特定する場合、または特定のセクションの詳細を表示するときに便利です。
トレースするセクションを追加するには、「アクティブなセクション」フィールドに対象セクションをカンマ区切りリストの形式で付加します。「トレース・セクション情報」ヘッダーの横にある「情報」アイコンをクリックすると、トレースに使用できるセクションのリストが簡単な説明とともに表示されます。ワイルド・カード文字*がサポートされているため、schema*と指定すると、接頭辞schemaで始まるすべてのセクションをトレースできます。
トレース・セクションの中には、詳細出力をサポートするものもあります。詳細出力をサポートするアクティブなセクションについて詳細なトレースを確認する場合は、「完全な詳細トレース」を有効にします。詳細は、3.7.5項「トレース」を参照してください。
|
重要: 「トレース・セクション情報」で設定するすべてのオプションは、「保存」を有効にして「更新」をクリックしていない場合は、コンテンツ・サーバー・インスタンスを再起動する際に失われます。 |
コンテンツ・サーバー・インスタンスは、簡単にアクセスするために様々なアイテムをキャッシュします。「システム監査情報」ページの「キャッシュ情報」セクションには、次の3つの主なキャッシュの現在の情報が表示されます。
検索キャッシュ: 現在実行中の検索の数、現在キャッシュにある実行済の検索の数、およびキャッシュが空になるタイミングに関する情報。これらの詳細は、検索関連の問題のトラブルシューティングの際に役立ちます。
スキーマ・キャッシュ: 現在キャッシュにあるスキーマ・アイテムの詳細。
バッファ: キャッシュ内のJavaオブジェクトおよび各オブジェクトが使用しているメモリーの数に関する情報で、システム監査の一般的な情報セクションのメモリー情報に反映されます。この情報は、メモリー・リークやその他のメモリーの問題の原因となるオブジェクトを特定する際に役立ちます。
詳細を表示するには、このページでキャッシュ情報のタイプのリンクをクリックします。
「システム監査情報」ページの「構成エントリ情報」セクションで提供される情報は、次のとおりです。
環境キーの数
上書きされた構成値の数
無視された設定の数
削除された設定の数
詳細を表示するには、このページで構成エントリ情報のタイプのリンクをクリックします。
「システム監査情報」ページのコンポーネント・レポート情報のセクションでは、コンテンツ・サーバー・インスタンスのコンポーネントに関する次の情報が提供されます。
場所: インスタンス内のコンポーネントのパス名
バージョン: 日付、ビルドおよびリビジョン
ステータス: コンポーネントの現在のステータス(「ロードされました」または「スキップ済」)
理由: コンポーネント・ステータスの説明
コンポーネントに関する詳細を表示するには、このページでコンポーネント名のリンクをクリックします。
サーバー出力ページでは、コンテンツ・サーバー・インスタンスのコンソール出力が表示されます。これは、DomainHome/ucm/cs/data/trace/classname.logファイルにある情報と同じです。これには、「システム監査のトレース・セクション情報」で監査のトレースのために選択したすべてのセクションに関する情報が含まれています。サーバー出力ページにアクセスするには、「システム監査情報」ページで「サーバー出力の表示」をクリックします。
スケジュールされたジョブは、システム・コンポーネントでスケジュールされたイベントの一部として実行されます。「スケジュールされたジョブの管理」インタフェースを使用して、コンテンツ・サーバー・インスタンスでスケジュールされたジョブに関する情報を監視できます。
「管理」を選択します。
「スケジュールされたジョブの管理」を選択します。
その後、「アクティブなスケジュールされたジョブ」を選択します。
「アクティブなスケジュールされたジョブ」画面に、スケジュールされた各ジョブの、ジョブ名、ジョブの説明、処理日と処理時刻、現在のステータスおよび使用可能なアクションが表示されます。
「アクション」をクリックして、スケジュールされたジョブの次のアクションのいずれかを選択します。
情報: スケジュールされたジョブの情報画面を表示します。
取消: スケジュールされたジョブを取り消します。
編集: スケジュールされたジョブを編集します。
削除: スケジュールされたジョブを削除します。
「情報」をクリックして、スケジュールされたジョブの情報画面を表示します。
「管理」を選択します。
「スケジュールされたジョブの管理」を選択します。
「スケジュールされたジョブの履歴」を選択します。
「スケジュールされたジョブの履歴」画面に、スケジュールされた各ジョブの、ジョブ名、説明、最終処理日、プロセス・ステータスおよびアクションが表示されます。
「管理」を選択します。
「スケジュールされたジョブの管理」を選択します。
「アクティブなスケジュールされたジョブ」または「スケジュールされたジョブの履歴」のいずれかを選択し、特定のジョブの「情報」をクリックして、情報を表示します。
ジョブ名、説明、カテゴリ、例外の親ジョブ、初期ユーザー、キュー・タイプ、スケジュール・タイプ、現在の状態、優先度、間隔、開始トークン、進行状況ステータス、作成日、更新日、プロセス日付、最終処理日および最終処理ステータスが表示されます。
編集可能なスケジュールされたジョブの情報画面を表示するには、「アクティブなスケジュールされたジョブ」画面の「アクション」メニューから「編集」を選択します。
コンテンツ・サーバーのトレースをアクティブ化して、トラブルシューティングおよびシステム・パフォーマンスの最適化に非常に役立つ詳細なシステム情報を表示できます。
サーバー全体のトレースは、システム全体のアクティビティを表示するのに使用します。サーバー全体のトレースをアクティブ化する方法は2つあります。
「管理」インタフェースからトレースをアクティブ化するには、次の手順を実行します。
「管理」を選択します。
「システム監査情報」を選択します。
詳細出力をサポートするアクティブなセクションについて詳細なトレースを確認するには、「完全な詳細トレース」を有効にします。
トレースをアクティブ化するように指定します。
「更新」をクリックします。
「サーバー出力の表示」をクリックします。
|
ヒント: トレース・オプションは、システムを再起動する際に失われます。コンテンツ・サーバー・インスタンスの再起動後に設定を確実に保持するには、「保存」を有効にしてから「更新」をクリックします。 |
アプレットからトレースをアクティブ化するには、次の手順を実行します。
管理アプレットを起動します。
「オプション」の次に、「トレース」を選択します。
「サーバー・トレース」を選択します。
アクティブ化するトレースまたはすべてを選択し、「OK」をクリックします。
次のトレース・オプションが使用できます。コンポーネントを追加する場合、追加のトレース・セクションをリストに表示できます。
applet: このトレースには、構成マネージャやユーザー管理など、初期化されたアプレットからの結果セットが含まれます。
archiver: このトレースでは、アーカイバ・データ・ファイルの読取りと書込み、および、アクティビティの開始および終了時刻など、アーカイブ・アクティビティに関する情報が提供されます。
archiverlocks: このトレースでは、開始時刻など、アーカイブ・アクティビティ中にファイルに適用されるロックに関する情報が提供されます。
chunkedrequest: このトレースでは、大きいリクエストが小さいリクエストにチャンク化される際に作成されるメッセージおよびヘッダーが表示されます。
docprofile: このトレースでは、コンテンツ・プロファイルの計算、具体的には、どのフィールドがラベルであるか、非表示であるかなどを決定するルールの評価が表示されます。
encoding: このトレースでは、発生したエンコーディング変換およびエンコーディングが発生したアクティビティに関する情報が提供されます。
filelock: このトレースでは、発生する衝突およびタイムアウトに焦点を絞ったディレクトリに適用される短期のシステム・ロック(たとえばアーカイブなどのアクティビティ中)に関する情報が表示されます。
filelonglock: このトレースでは、システムが設定した長期のロックの作成、削除および保守に関する情報が表示されます。
filequeue: このトレースでは、ファイル・キューのアクセスに関する情報が表示されます。
indexer: このトレースでは、索引の更新のために実行されるステップ、および各ステップの経過時間など、データベースの更新時に発生する索引機能に関する情報が表示されます。
indexermonitor: このトレースでは、開始および終了時間など、自動索引アクティビティの要約が提供されます。
indexerprocess: このトレースでは、手動で起動した索引プロセスに関する情報が表示され、プロセスが正常に終了したかどうかが示されます。
localization: このトレースでは、ローカライズの使用状況およびアクティビティに関する情報が表示されます。
mail: このトレースでは、コンテンツ・サーバー・インスタンスによって送信されるメールについて説明します。
pagecreation: このトレースでは、サーバー・スレッド、およびページの生成にかかる時間など、表示されるページの作成に関する情報が表示されます。
requestaudit: このトレースでは、リクエストの経過時間、および作成されたリクエストの数など、サービス・リクエストに関するサマリー・レポートが提供されます。
scheduledevents: このトレースでは、毎時または日次のバックグラウンドのスケジュール化されたイベントのリストが提供されます。
schema: このトレースでは、スキーマのパブリッシュ(.jsファイルとしてパブリッシュされた表およびビュー)、およびキャッシュ(コンテンツ・サーバー・メモリーにキャッシュされた表)に関する情報が提供されます。
searchquery: このトレースでは、検索に使用されるフィールド、および結果のソート順など、最近の検索に関する情報が表示されます。
socketrequests: このトレースでは、ソケット・リクエストの日時とスレッド番号、およびリクエスト中のアクションが表示されます。
system: このトレースでは、システムのソケット・リクエストおよびレスポンスなど、内部システム・メッセージが表示されます。
systemdatabase: このトレースでは、実行された問合せ、索引の更新、使用されたスレッド、および開始時間など、データベース・アクティビティに関する情報が提供されます。
transfermonitor: このトレースでは、アーカイバおよびバッチ・ファイル転送アクティビティに関する情報が表示されます。
userstorage: このトレースでは、アクセス中に実行されたアクションなど、外部ユーザー・リポジトリのアクセスについて説明します。
workflow: このトレースでは、ドキュメント・タイトルおよびリビジョン番号など、ワークフローで処理されるコンテンツ・アイテム上のメタデータのリストが表示されます。
|
注意: 国際的なサポートを促進するため、ほとんどのトレース・メッセージは英語で出力され、翻訳されていません。 |
環境パッケージャは診断ツールです。それは、必要な状態ディレクトリ、ログ・ファイル、および他のコンポーネントやリソースのディレクトリのzipファイルを作成します。
環境zipファイルを作成するには、次の手順を実行します。
コンテンツ・サーバーに管理者としてログインしていることを確認します。
「管理」、「環境パッケージャ」の順に選択します。「環境パッケージャ」ページが表示されます。
パッケージ化する環境の部分を選択します。
環境zipファイルを作成する準備が完了したら、「パッケージングの起動」をクリックします。
zipファイルの作成中は、zipファイルへのリンクとともにメッセージが表示されます。パッケージング・プロセスは数分かかる場合があります。プロセスが完了するまでは、zipファイルのリンクは使用できません。
|
注意: パッケージ化されたzipの名前は、server_environment_*.zipになります。コンテンツ・サーバー・インスタンスがパッケージ化されたzipファイルを作成している間、それはIntradocDir/vault/~tempにあります。zipファイルの作成が完了すると、それはIntradocDir/weblayout/groups/secure/logs/envに移動します。 |
Content Serverアナライザ・アプリケーションによって、ファイル・システム、データベースおよび検索索引など、コンテンツ・サーバー・リポジトリ・コンポーネントの整合性を確認できます。また、リポジトリ・コンポーネントで検出された問題をシステム管理者が修正する場合にも役立ちます。
Content Serverアナライザを使用すると、システム管理者は次のことができます。
コンテンツ・サーバーの3つの重要なデータベース表(Revisions、DocumentsおよびDocMeta)の間の同期化の精度を確認します。
dRevClassIDフィールドおよびdDocNameフィールドが、すべてのリビジョンのコンテンツ・アイテム間で整合性がとれていることを確認します。
ファイル・システム(ネイティブ・ファイル・リポジトリおよびWeb表示可能ファイル・リポジトリ)に重複ファイルや欠落したファイルがあるかどうかを判別します。
検索索引とファイル・システム間の整合性の精度を確認します。
検索索引とRevisionsデータベース表間の整合性の精度を確認します。
ファイル・システムに必要なすべてのファイルが含まれていることを確認します。
重複ファイルを、ログ/ディレクトリに移動することによって、コンテンツ・サーバー・リポジトリから永久または一時的に削除します。
コンテンツ・サーバー・リポジトリにコンテンツ・アイテムの状態で、一般的なレポートを作成します。
Content Serverアナライザの起動方法は、オペレーティング・システムに応じて異なります。
Windowsオペレーティング・システムの場合:
「スタート」、「Oracle Content Server」、Instance_Name、「Content Serverアナライザ」の順に選択します。
UNIXオペレーティング・システムの場合:
DomainHome/ucm/cs/binディレクトリにナビゲートし、Content Serverアナライザ・プログラムを実行します。
次の項では、Content Serverアナライザのタスクについて説明します。
Content Serverアナライザを表示するには、次の方法のうちの1つを使用します。
Windowsオペレーティング・システムの場合:
「スタート」、「プログラム」、「コンテンツ・サーバー」、instance_name、「ユーティリティ」、「Content Serverアナライザ」の順に選択します。
UNIXオペレーティング・システムの場合:
DomainHome/ucm/cs/binディレクトリに変更し、シェル・ウィンドウで「IdcAnalyze」と入力して、[RETURN]を押します。
Content Serverアナライザ・アプリケーションが表示されます。
logs/ディレクトリは、Content Serverアナライザのデフォルトのロギング・ディレクトリです。解析の出力ファイルはこのディレクトリに書き込まれ、ファイル・システムの解析プロセス中に検出される追加のファイルもここに転送できます。オプションで、必要に応じて、デフォルトのlogs/ディレクトリの名前およびパスを変更できます。
アナライザのログ・ディレクトリの名前およびパスをカスタマイズするには、次の手順を実行します。
「Content Serverアナライザ」の「構成」タブで、「Analyzerのログ・ディレクトリ」フィールドにカーソルを置きます。
目的のディレクトリ・パスを入力します。
次の解析プロセス中、Content Serverアナライザによって、DomainHome/ucm/cs/bin/ディレクトリ階層内に指定したディレクトリが自動的に作成されます。
「Content Serverアナライザ」の「構成」タブで、必要なオプションを選択およびアクティブ化します(対応するチェック・ボックスをチェックします)。
「解析の開始」をクリックします。
|
注意: Content Serverアナライザを初めて実行した場合、logs/ディレクトリの出力ファイルは自動的に作成されます。その後の解析プロセスでは、既存のログ・ファイルを上書きしてよいかを尋ねる確認メッセージが表示されます。 |
「はい」をクリックして、既存のログ・ファイルを上書きします。
「Content Serverアナライザ」の「進行状況」タブが自動的に表示されます。
|
注意: 「いいえ」をクリックした場合、解析プロセスは終了し、Content Serverアナライザを再度実行する前に、logs/ディレクトリからファイルを手動で削除するよう求められます。 |
選択したすべての解析プロセスが終了すると、完了メッセージが表示されます。
「OK」をクリックします。
結果は、「進行状況」タブのコンソール領域に表示されます。
「RevClassIDのチェック」および「データベースのクリーン」オプションは、データベース列の整合性をチェックするのに使用されます。使用可能なオプションによって、コンテンツ・アイテムのリビジョン情報を格納するのに使用される3つの表(DocMeta、DocumentsおよびRevisions)を調査できます。Revisions表で見つからない追加のエントリについて、DocMetaファイルを調査します。同様に、Revisions表のエントリに対応するのに十分なエントリがあることを確認するために、Documents表を調査します。
|
注意: 「データベースのチェック」オプションが選択されている場合のみ、「RevClassIDのチェック」および「データベースのクリーン」オプションはアクティブ化され、選択可能になります。 |
コンテンツ・サーバー・データベースを分析するには、次の手順を実行します。
「Content Serverアナライザ」の「構成」タブで、適用可能なオプションを選択します。
「解析の開始」をクリックします。
結果は、「Content Serverアナライザ」の「進行状況」タブのコンソール領域に表示されます。解析手順の詳細は、3.7.7.3項「解析プロセスの起動」を参照してください。
「検索索引のチェック」およびcsIDCAnalyzeCleanIndexオプションは、索引に属するすべてのドキュメントが正しくリストされていることを確認するために、Revisions表のエントリをチェックするのに使用されます。また、検索索引に重複エントリがないことを確認するために、チェックを実行できます。
|
注意: 「検索索引のチェック」オプションが選択されている場合のみ、csIDCAnalyzeCleanIndexオプションはアクティブ化され、選択可能になります。 |
コンテンツ・サーバー検索索引を分析するには、次の手順を実行します。
「Content Serverアナライザ」の「構成」タブで、適用可能なオプションを選択します。
「解析の開始」ボタンをクリックします(解析手順の詳細は、3.7.7.3項「解析プロセスの起動」を参照してください)。
結果は、「Content Serverアナライザ」の「進行状況」タブのコンソール領域に表示されます。
「ファイル・システムのチェック」、「削除」、「安全な削除」および「追加ファイルのチェック」オプションは、ファイル・システム(Webレイアウト・ファイル・リポジトリおよびボールト・ファイル・リポジトリ)の整合性をチェックするのに使用されます。データベース内の情報を使用すると、これらのオプションによって、Revisions表内のすべてのファイルにはファイル・システムのアイテムに対応している正確なエントリが格納されていることを確認できます。ボールト・ファイル・リポジトリおよびWebレイアウト・ファイル・リポジトリ内で追加ファイルを検索するために、チェックを実行することもできます。
|
注意: 「ファイル・システムのチェック」オプションが選択されている場合のみ、「削除」、「安全な削除」および「追加ファイルのチェック」オプションはアクティブ化され、選択可能になります。 |
コンテンツ・サーバー・ファイル・システム(ボールト・ファイル・リポジトリおよびWebレイアウト・ファイル・リポジトリ)を分析するには、次の手順を実行します。
「Content Serverアナライザ」の「構成」タブで、適用可能なオプションを選択します。
「解析の開始」をクリックします。
結果は、「Content Serverアナライザ」の「進行状況」タブのコンソール領域に表示されます。解析手順の詳細は、3.7.7.3項「解析プロセスの起動」を参照してください。
「解析の開始」ボタンをクリックすると、「Content Serverアナライザ」の「進行状況」タブが自動的に表示されます。進行状況バーには、Content Serverアナライザが選択された分析オプションの処理を完了したタイミングが表示されます。次のイメージは、部分的に終了した分析を示しています。
解析プロセスが完了すると、結果は「進行状況」タブのコンソール領域に表示されます。結果は、選択した分析オプションに応じて異なります。次のコンソール領域のイメージは、データベース、検索索引およびファイル・システムのオプションを選択した場合の結果を示しています。
Content Serverアナライザによって生成されるステータス・レポートでは、リポジトリ内のコンテンツ・アイテムに関する統計が提供されます。ステータス・レポートの出力は、「進行状況」タブのコンソール領域に表示されます。
ステータス・レポートを生成するには、次の手順を実行します。
「Content Serverアナライザ」の「構成」タブで、「レポートの生成」を選択します。
「解析の開始」をクリックします。
解析プロセスが完了すると、「Content Serverアナライザ」の「進行状況」タブのコンソール領域に、標準的な解析結果の直後にステータス・レポート情報が表示されます。
コンテンツ・サーバー・インスタンスでは、設定すると適切な診断情報をもたらすデバッグ構成変数も提供されます。構成変数はIsDevelopmentEnvironmentという名前で、インストール中およびコンテンツ・サーバー・インスタンスの更新時に、コンテンツ・サーバー・インスタンスの構成ファイル(IntradocDir/config/config.cfg)に設定されます。このエントリによって、次のことが行われます。
コンテンツ・サーバー・インスタンスをデバッグ・モードで実行する必要があるかどうかを定義します。
スクリプト・エラーのトレースを有効にします。サービス・コールへのパラメータとして使用する場合、表示されるページの下部にスクリプト・エラー情報を追加できます。
別のデバッグ構成変数は、AlwaysReportErrorPageStackTraceという名前です。この変数を設定すると、エラーが発生するたびに、コンテンツ・サーバーのユーザー・インタフェースを表示しているブラウザに、スタック・トレースが報告されます。
|
注意: 詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。 |
スタック・トレースによって、コンテンツ・サーバー・インスタンス内で現在実行中のスレッドがわかります。これは、スレッドに関する情報を提供する有益なトラブルシューティング・ツールで、コンテンツ・サーバーの処理を監視できます。
コンテンツ・サーバー・インスタンスの現在のスタック・トレースを開始する手順は、Oracle WebLogic Serverのドキュメントを参照してください。
