13 Inbound Refineryを追加するためのドメインの拡張

エンタープライズ・デプロイメント・ドメインを拡張してInbound Refineryソフトウェアを含めるために、特定のタスクを実行する必要があります。

• Inbound Refineryを使用するためのドメインの拡張
  この項では、Inbound Refineryソフトウェアを含めて既存のエンタープライズ・デプロイメント・ドメインを拡張する手順を説明します。
• Inbound Refinery用の構成後タスクおよび検証タスクの実行
  Inbound Refineryソフトウェアを含めてドメインを拡張した後、次の構成後タスクと検証タスクを行うことを考慮してください。
• Inbound Refinery管理対象サーバーの構成
  Inbound Refinery管理対象サーバーの構成を初期化するには、その管理対象サーバーに一度だけHTTP経由でアクセスする必要があります。これは、管理対象サーバーのリスニング・アドレスで直接実行できます。Inbound RefineryインスタンスはHTTPサーバーの後方に配置する必要があります。
• Inbound Refinery管理対象サーバーの構成の検証
  作成したInbound Refinery管理対象サーバーが正しく構成されているかどうかを確認するには、コンテンツ・サーバーにログインし、変換に有効と認識された拡張子を持つファイルが正しく変換されることを確認して、構成を検証します。

13.1 Inbound Refineryを使用するためのドメインの拡張

この項では、Inbound Refineryソフトウェアを含めて既存のエンタープライズ・デプロイメント・ドメインを拡張する手順を説明します。

• 構成ウィザードの起動
  
• ドメインを拡張するために構成ウィザード画面へ移動
  

13.1.1 構成ウィザードの起動

構成ウィザードを起動する手順は次のとおりです。

1. WebLogic Serverコンソールから、このドメイン拡張により変更される管理対象サーバーを停止します。影響を受けない管理対象サーバーはオンラインのままです。
2. 変更するすべての管理対象サーバーについて、管理対象サーバーの停止が完了していることを確認します。
3. すべての管理対象サーバーが安定した状態になったら、管理サーバーを停止します。
4. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

   cd ORACLE_HOME/oracle_common/common/bin
   ./config.sh

13.1.2 ドメインを拡張するために構成ウィザード画面へ移動

トポロジのドメインを更新して構成するには、この項の手順に従います。

注意:

この項で説明する手順を使用して、既存のドメインを拡張することもできます。この手順の説明では要件が満たされない場合は、その要件に応じた選択を行うか、サポート・ドキュメントで追加の詳細を参照してください。

ドメインを作成して構成するためのタスクは次のとおりです。

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、作成した初期管理サーバー・ドメイン・ホームの完全なパスを表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「構成タイプ」に関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

• Oracle Universal Content Management - Inbound Refinery - 12.2.1.2.0 [wccontent]

  Infrastructureテンプレート、WebCenter PortalテンプレートおよびWebCenter Contentテンプレートは、初期ドメインの作成および更新に使用されたため、すでに選択されています。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「テンプレート」に関する項を参照してください。

タスク3   GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で「次へ」をクリックします。

タスク4   JDBC接続のテスト

「次へ」をクリックして続行します。

タスク5   拡張構成の選択

トポロジのドメイン構成を完了するには、「拡張構成」画面で次のオプションを選択する必要があります。

トポロジ

タスク6   管理対象サーバーの構成

「管理対象サーバー」画面で、サーバーのリストに新しい管理対象サーバーが表示されます。

次のタスクを実行して、デフォルトの管理対象サーバーを変更して2つ目の管理対象サーバーを作成します。

1. デフォルトの管理対象サーバーの名前をWLS_IBR1に変更します。

2. 「追加」をクリックして新しい管理対象サーバーを作成し、そのサーバーにWLS_IBR2と名前を付けます。

   ヒント:

   ここで推奨するサーバー名がこのドキュメント全体で使用されます。別の名前を選択した場合は、必要に応じて置き換えてください。

3. 次の表の情報を使用して、各管理対象サーバーの残りの列を入力します。

表13-1 各Oracle Inbound Refineryサーバーで必要な値

サーバー名	リスニング・アドレス	リスニング・ポート	SSLの有効化	SSLリスニング・ポート	サーバー・グループ
WLS_IBR1	WCCHOST1	16250	いいえ	無効	IBR-MGD-SVR
WLS_IBR2	WCCHOST2	16250	いいえ	無効	IBR-MGD-SVR

ヒント:

「管理対象サーバー」画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の管理対象サーバーに関する項を参照してください。

タスク7   クラスタの構成

このタスクでは、Oracle Inbound Refineryソフトウェアのターゲットにすることができる管理対象サーバーのクラスタを作成します。

「クラスタ」画面を使用して、新しいクラスタを作成します。

1. 「追加」ボタンをクリックします。

2. 「クラスタ名」フィールドでIBR_Serversを指定します。

3. 「動的サーバー・グループ」ドロップダウン・リストで、「未指定」を選択します。

4. 「次へ」をクリックして次の画面に進みます。

注意:

デフォルトでは、クラスタ内のサーバー・インスタンスは、ユニキャストを使用して相互に通信します。マルチキャストを使用するようにクラスタの通信を変更する場合は、『Oracle WebLogic Serverクラスタの管理』のユニキャストかマルチキャストかを選択する際の考慮事項に関する項を参照してください。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「クラスタ」に関する項を参照してください。

タスク8   サーバー・テンプレートの割当て

「次へ」をクリックして次の画面に進みます。

タスク9   動的サーバーの構成

静的クラスタとして残すクラスタについて、すべての動的サーバー・オプションが無効になっていることを確認します。

1. この画面の「動的クラスタ」、「計算済リスニング・ポート」および「計算済マシン名」チェック・ボックスの選択が解除されていることを確認します。

2. 「サーバー・テンプレート」で「未指定」が選択されていることを確認します。

3. 「次へ」をクリックします。

タスク10   クラスタへの管理対象サーバーの割当て

「サーバーのクラスタへの割当」画面を使用して、WLS_IBR1およびWLS_IBR2を新規クラスタIBR_Serversに割り当てます。

1. 「クラスタ」ペインで、サーバーを割り当てるクラスタ(ここではIBR_Servers)を選択します。

2. 「サーバー」ペインで、次のいずれかの操作を実行して、WLS_IBR1をIBR_Serversに割り当てます。

   • WLS_IBR1管理対象サーバーを1回クリックして選択し、右矢印をクリックして「クラスタ」ペインで選択されているクラスタの下に移動します。

   • WLS_IBR1をダブルクリックして、クラスタ・ペインで選択されているクラスタの下に移動します。

3. 同じ手順を繰り返して、WLS_IBR2をIBR_Serversに割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのクラスタへの割当」に関する項を参照してください。

タスク11   Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期インフラストラクチャ・メインの作成中に定義されているため、9991のままにします。

注意:

Coherenceライセンス情報については、Oracle Fusion Middlewareライセンス情報のOracle Coherenceに関する項を参照してください。

タスク12 既存のマシンの検証

「Unixマシン」タブで、初期インフラストラクチャ・ドメインの作成時に作成したマシンの名前を確認します。

「次へ」をクリックします。

タスク13   マシンへのサーバーの割当て

「サーバーのマシンへの割当」画面を使用して、作成したばかりのOracle Inbound Refinery管理対象サーバーを、ドメイン内の対応するマシンに割り当てます。

WLS_IBR1をWCCHOST1、WLS_IBR2をWCCHOST2に割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのマシンへの割当」に関する項を参照してください。

タスク14   仮想ターゲットの確認

「次へ」をクリックして次の画面に進みます。

タスク15   パーティションの確認

「次へ」をクリックして次の画面に進みます。

タスク16   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、ドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。

「更新」をクリックして、ドメインの拡張を実行します。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

タスク17   ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

• ドメインの場所

• 管理サーバーURL

どちらの項目も後で必要になるため、メモしておく必要があります。ドメインの場所は、ノード・マネージャと管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、URLは管理サーバーへのアクセスで必要になります。

「終了」をクリックして、構成ウィザードを閉じます。

タスク18   管理サーバーの起動

管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。

13.2 Inbound Refinery用の構成後タスクおよび検証タスクの実行

Inbound Refineryソフトウェアを含めてドメインを拡張した後、次の構成後タスクと検証タスクを行うことを考慮してください。

• Inbound Refineryのドメイン構成の更新の伝播
  
• ドメイン解凍後のNodeManager構成の更新
  ドメインの拡張時に、MSERVER_HOMEのnodemanager.propertiesファイルがASERVER_HOMEのnodemanager.propertiesファイルの一部の値で上書きされることがあります。具体的には、ListenAddressまたはCustomIdentityAlias (あるいはその両方)の値がリセットされる場合があります。
• 既存の管理対象サーバーの再起動と検証
  
• uploadおよびstageディレクトリの絶対パスへの変更
  ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。
• Inbound Refinery管理対象サーバーの起動
  

13.2.1 Inbound Refineryのドメイン構成の更新の伝搬

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。Inbound Refinery管理対象サーバーにドメイン構成を伝播する手順は次のとおりです。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのapplicationsディレクトリのバックアップ・コピーを作成します。
2. 次のpackコマンドをWCCHOST1で実行し、テンプレート・パックを作成します。

   cd ORACLE_COMMON_HOME/common/bin
   
   ./pack.sh -managed=true 
             -domain=ASERVER_HOME 
             -template=/full_path/edgdomaintemplateExtIBR.jar 
             -template_name=edgdomain_templateIBR

   この例では、次のとおりです。

   • ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

   • full_pathを、ドメイン・テンプレートjarファイルを作成する場所の完全なパスに置き換えます。ドメイン・テンプレートjarファイルをコピーまたは解凍する場合は、この場所を参照する必要があります。ORACLE_HOME以外の共有ボリュームを選択するか、/tmp/に書き込み、そのファイルをサーバー間で手動でコピーすることをお薦めします。

     テンプレートJARファイルの完全なパスを、packコマンドの-template引数の一部として指定する必要があります。

     SHARED_CONFIG_DIR/domains/template_filename.jar

   • edgdomaintemplateExtIBR.jarは、作成するJARファイルのサンプル名です。これには、Oracle HTTP Serverインスタンスの構成ファイルなどのドメイン構成ファイルが含まれます。

   • edgdomain_templateIBRは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

3. 次のunpackコマンドをWCPHOST1で実行して、前の手順で作成したテンプレートをMSERVER_HOMEディレクトリに伝播します。

   cd ORACLE_COMMON_HOME/common/bin
   
   ./unpack.sh -domain=MSERVER_HOME 
               -template=/full_path/edgdomaintemplateExtIBR.jar 
               -app_dir=APPLICATION_HOME 
               -overwrite_domain=true
   

   この例では、次のとおりです。

   • MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

   • edgdomaintemplateIBR.jarは、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートのディレクトリ・パスおよび名前です。

   • 管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍する場合は、-overwrite_domain=true引数が必要です。

     上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

   • APPLICATION_HOMEを、ローカル記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。

   ヒント:

   packおよびunpackコマンドの詳細は、Oracle Fusion Middleware PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

4. パック済のJARファイルへのフルパスが他のサーバーで使用可能な共有ボリューム上にある場合は、この手順をスキップし、それ以外の場合は、次のコマンドをWCCHOST1で実行し、手順1で作成したテンプレート・パックをWCCHOST2にコピーします。

   scp /full_path/edgdomaintemplateExtIBR.jar oracle@WCCHOST2:/full_path/
   

   full_pathを、テンプレートJARファイルをコピーするディレクトリの完全なパスで置き換えます。

5. 次のunpackコマンドを各リモート・ホストで実行して、前の手順でコピーしたドメイン・テンプレートをMSERVER_HOMEディレクトリにデプロイします。

   cd ORACLE_COMMON_HOME/common/bin
   
   ./unpack.sh -domain=MSERVER_HOME 
               -template=/full_path/edgdomaintemplateExtIBR.jar 
               -app_dir=APPLICATION_HOME 
               -overwrite_domain=true
   

   この例では、次のとおりです。

   • MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

   • edgdomaintemplateIBR.jarは、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートのディレクトリ・パスおよび名前です。

   • 管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍する場合は、-overwrite_domain=true引数が必要です。

     上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

   • APPLICATION_HOMEを、ローカル記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。

   ヒント:

   packおよびunpackコマンドの詳細は、Oracle Fusion Middleware PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

13.2.2 ドメイン解凍後のNodeManager構成の更新

ドメインの拡張時に、MSERVER_HOMEのnodemanager.propertiesファイルがASERVER_HOMEのnodemanager.propertiesファイルの一部の値で上書きされることがあります。具体的には、ListenAddressまたはCustomIdentityAlias (あるいはその両方)の値がリセットされる場合があります。

注意:

• ListenAddressは通常、ASERVER_HOME nodemanagerと同じホストに常駐するMSERVER_HOME nodemanager上でリセットされます。このトポロジでは、WCCHOST1です。

• SOAサーバーとハードウェア・ロード・バランサ間のSSL通信を有効にする前のドメイン拡張では、CustomIdentityAliasに関して手順2から4は当てはまらないことがあります。

各ホストのMSERVER_HOME/nodemanager/nodemanager.propertiesファイルについて、次のことを実行します。

1. 正しいListenAddressパラメータ値を確認して、必要な場合は値を再設定します。

   grep ListenAddress MSERVER_HOME/nodemanager/nodemanager.properties

2. 次のコマンドの参照として、ドメイン構成ファイルから構成済アイデンティティ別名のリストを確認します。

   grep server-private-key-alias ASERVER_HOME/config/config.xml | sort | uniq

3. 現在のCustomIdentityAliasパラメータ値を確認します。

   grep CustomIdentityAlias MSERVER_HOME/nodemanager/nodemanager.properties

4. 必要に応じて、CustomIdentityAliasパラメータ値を、現在のホストに適した正しい別名文字列に再設定します。
5. nodemanagerプロセスを再起動します。

   kill `ps -eaf | grep weblogic.NodeManager | grep MSERVER_HOME | grep -v grep | awk '{print $2}' `
   nohup MSERVER_HOME/bin/startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

詳細は、「カスタム・キーストアを使用するためのノード・マネージャの構成」を参照してください。

13.2.3 既存の管理対象サーバーの再起動と検証

ドメインが拡張され、すべてのサーバーのMSERVER_HOMEディレクトリに解凍されたので、既存のコンポーネントの管理対象サーバーを再起動します。

1. WebLogic Serverコンソールから、まずWLS_WSMn管理対象サーバーを再起動します。
2. 別のブラウザ・ウィンドウから、URLを正常にロードすることで、WSM-PMアプリケーションが応答していることを確認します。

   http://wcpinternal.example.com/wsm-pm/validator
   

3. 解凍されたMSERVER_HOMEで同一場所に配置されている他の管理対象サーバーをすべて再起動します。これは、必要に応じて、ローリング方式で実行できます。次の手順を続行する前に、必要なサーバーの再起動およびサービスの検証を完了します。

13.2.4 uploadおよびstageディレクトリの絶対パスへの変更

ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

この手順は、リモート・デプロイメントの実行時の潜在的な問題の回避とステージ・モードが必要なデプロイメントのために必要です。

管理対象サーバー・ドメイン・ホーム・ディレクトリ内のすべての管理対象サーバーについてこれらのディレクトリ・パスを更新する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 左側のナビゲーション・ツリーで、「ドメイン」→「環境」を開きます。

3. 「ロックして編集」をクリックします。

4. 使用するクラスタ・タイプに適したオブジェクトに移動して編集します。

   1. 静的クラスタの場合、「サーバー」に移動し、編集する管理対象サーバーの名前をクリックします。

5. 編集する新しい管理対象サーバーまたはサーバー・テンプレートごとに、次の手順を実行します。

   1. 「構成」タブをクリックし、「デプロイメント」タブをクリックします。

   2. 「ステージング・ディレクトリ名」が次のように設定されていることを確認します。

      MSERVER_HOME/servers/server_or_template_name/stage
      

      MSERVER_HOMEをMSERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。静的クラスタを使用している場合、編集する管理対象サーバーの正しい名前で更新します。

   3. 「アップロード・ディレクトリ名」を次の値に更新します。

      ASERVER_HOME/servers/AdminServer/upload
      

      ASERVER_HOMEをASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。

   4. 「保存」をクリックします。

   5. 「サーバーのサマリー」または「サーバー・テンプレートのサマリー」画面(該当する方)に戻ります。

6. 該当するすべてのオブジェクトを変更したら、「変更のアクティブ化」をクリックします。

7. これらの変更の影響を受けるすべての管理対象サーバーを再起動します。

13.2.5 Inbound Refinery管理対象サーバーの起動

WCCHOST1でWLS_IBR1管理対象サーバーを起動する手順は次のとおりです。

1. 次のURLでOracle WebLogic Server管理コンソールにweblogic_wcpユーザーとしてログインします。

   http://admin.example.com/console

2. 次の手順に従い、管理コンソールを使用してWLS_IBR1管理対象サーバーを起動します。
   1. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。
   2. 「サーバー」をクリックします。
   3. 「サマリー」ページまたは「サーバー」ページで、「制御」タブをクリックします。
   4. 表の「サーバー」列からWLS_IBR1を選択します。
   5. 「起動」をクリックします。
3. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。
   • サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。
   • 「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。
4. 前述の手順を繰り返し、WCCHOST2でWLS_IBR2管理対象サーバーを起動します。

13.3 Inbound Refinery管理対象サーバーの構成

Inbound Refinery管理対象サーバーの構成を初期化するには、その管理対象サーバーに一度だけHTTP経由でアクセスする必要があります。これは、管理対象サーバーのリスニング・アドレスで直接実行できます。Inbound RefineryインスタンスはHTTPサーバーの後方に配置する必要があります。

Inbound Refineryインスタンスへのすべての後続のアクセスは、ソケット・リスナーを介して行われます。このリスナーは、次の項で構成する着信ソケット接続アドレス・セキュリティ・フィルタによって保護されます。

すべてのInbound Refineryインスタンスを使用して各コンテンツ・サーバー・インスタンスを構成することをお薦めします。コンテンツ・サーバーの構成プロセスは、Inbound Refineryインスタンスをプロバイダとして追加することです。また、一部のインストール後の手順をInbound Refineryで実行する必要があります。

次の項では、各Inbound Refineryインスタンスのインストール後の構成手順について説明します。

• Inbound Refineryの設定の構成
  Inbound Refinery管理対象サーバーを起動した後、インストール後の構成画面で各サーバーの設定を構成します。
• 資格証明マップ経由のWebCenter Content管理ロールの付与
  
• フォント・パスの指定
  
• Inbound Refineryにジョブを送信して変換するためのコンテンツ・サーバーの設定
  Oracle WebCenter Content ServerからInbound Refineryにジョブを送信して変換を実施できるようにするには、次の項の説明に従って、Inbound Refinery管理対象サーバーごとに設定タスクを事前に実行する必要があります。

13.3.1 Inbound Refineryの設定の構成

Inbound Refinery管理対象サーバーを起動した後、インストール後の構成画面で各サーバーの設定を構成します。

各Inbound Refineryインスタンスの設定を構成する手順は次のとおりです。

1. Oracle WebCenter Content Inbound Refinery共有フォルダ構成に必要なランタイム・クラスタ・サブディレクトリを作成します。

   Oracle WebCenter Content Inbound Refinery構成ファイルは、クラスタのすべてのメンバーがアクセスできるように共有ディスクに配置されます。Oracle WebCenter Content Inbound Refineryエンタープライズ・デプロイメントの共有ディスクの場所は、ORACLE_RUNTIME/domain_name/IBR_Servers/です。

   次のコマンドを実行して、各IBR管理対象サーバーに必要なサブディレクトリを作成します。

   mkdir -p ORACLE_RUNTIME/domain_name/IBR_Servers/ibr1/vault 
   mkdir -p ORACLE_RUNTIME/domain_name/IBR_Servers/ibr1/weblayout 
   mkdir -p ORACLE_RUNTIME/domain_name/IBR_Servers/ibr1/data/users/profiles  
   mkdir -p ORACLE_RUNTIME/domain_name/IBR_Servers/ibr2/vault 
   mkdir -p ORACLE_RUNTIME/domain_name/IBR_Servers/ibr2/weblayout 
   mkdir -p ORACLE_RUNTIME/domain_name/IBR_Servers/ibr2/data/users/profiles

2. 次のURLからInbound Refineryのインストール後の構成画面にアクセスします。Nには1または2を指定します。

   http://WCCHOSTN:16250/ibr/

3. 「構成」画面で、「Inbound Refineryのインスタンス識別子: name」を確認します。このインスタンスの構成設定を次のように設定します。各Inbound Refineryインスタンスは、他のインスタンスとは独立し、各マシンに対してローカルです。各インスタンスの構成ディレクトリとしてローカル・ディレクトリを使用します。

   • Inbound Refineryのインスタンス・フォルダ: これをORACLE_RUNTIME/domain_name/IBR_Servers/ibrNに設定します。

     例: /u01/oracle/runtime/wcpedg_domain/IBR_Servers/ibr1

   • ネイティブ・ファイル・リポジトリの場所: これをORACLE_RUNTIME/domain_name/IBR_Servers/ibrN/vaultに設定します。

     例: /u01/oracle/runtime/wcpedg_domain/IBR_Servers/ibr1/vault

   • Webレイアウト・フォルダ: これをORACLE_RUNTIME/domain_name/IBR_Servers/ibrN/weblayoutに設定します。

     例: /u01/oracle/runtime/wcpedg_domain/IBR_Servers/ibr1/weblayout

   • ユーザー・プロファイル・フォルダ: これを ORACLE_RUNTIME/domain_name/IBR_Servers/ibrN/data/users/profilesに設定します。

     例: /u01/oracle/runtime/wcpedg_domain/IBR_Servers/ibr1/data/users/profiles

   • 受信ソケット接続アドレス・セキュリティ・フィルタ:: ローカル・ホストとサーバーIPアドレスのパイプ区切りのリストです。

     127.0.0.1|0:0:0:0:0:0:0:1|WCCHOST1-IP|WCCHOST2-IP|WEBHOST1-IP|WEBHOST2-IP

     この設定によってコンテンツ・サーバーからアクセスできるようになります。WCCHOST1-IPおよびWCCHOST2-IPの値は、Inbound Refineryにジョブを送信するコンテンツ・サーバーのインスタンスが1つ以上あるマシンのIPアドレスである必要がありますが、必ずしもInbound RefineryのIPアドレスとは限りません。(ただし、このエンタープライズ・デプロイメント・ガイドで使用される参照トポロジでは、これらのIPアドレスは同じです。)

     「ソケット接続アドレス・セキュリティ・フィルタを着信中」フィールドの値にはワイルドカードを指定できます(例: 192.0.2.*)。

     この値は、後で/u02/oracle/runtime/wcpedg_domain/IBR_Servers/ibrN/config/config.cfgファイルのSocketHostAddressSecurityFilterを設定し、Inbound Refinery管理対象サーバーを再起動すると、変更できます。

     http://WCCHOST1:16250/ibr/ではNが1、http://WCCHOST2:16250/ibr/ではNが2

   • サーバーのソケット・ポート: 5555のように、使用されていないポート番号を入力します。この値は、トップレベルのサービスを呼び出すためのポートの番号です。

     このポート番号は、後でOracle WebCenter Contentの構成時に必要となるため、書き留めておいてください。

     このフィールド値を変更すると、/u01/oracle/runtime/wcpedg_domain/IBR_Servers/ibrN/config/config.cfgのIntradocServerPortエントリが変更されます。

     http://WCCHOST1:16250/ibr/ではNが1、http://WCCHOST2:16250/ibr/ではNが2

   • コンテンツ・サーバーのインスタンス名: Inbound Refineryサーバーのインスタンス名を指定します。

     デフォルト値を受け入れることも、より便利な名前に変更することもできます。このサーバー名は、後でOracle WebCenter Contentの構成時に必要となるため、書き留めておいてください。

   構成ページの他のすべてのフィールドはそのままにします。

   「送信」をクリックすると、次のメッセージが表示されます。

   インストール後の構成が完了しました。このノードを再起動してください。
4. WebLogic Server管理コンソールを使用して、Inbound Refinery管理対象サーバーを再起動します。
5. 各Inbound Refineryインスタンスに対して個別のコンテンツ・フォルダ名を使用して、前述の手順を実行します。

13.3.2 資格証明マップ経由のWebCenter Content管理ロールの付与

資格証明マップを構成してWCPAdministrators LDAPグループにContent Server管理ロールを付与する必要があります。

WCPAdministrators LDAPグループは、以前に完了した「エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング」の項で作成されました。資格証明マップのこの構成により、すべての構成、管理およびメンテナンス・タスクのLDAP管理ユーザーの一貫した利用が保証されます。

資格証明マップを構成し、LDAPベースのWCPAdministratorsグループに必要なロール権限を付与する手順は次のとおりです。

1. weblogicアカウントを使用してWCCHOST1のInbound Refineryサーバーにログインします。
2. 「管理」メニューを開き、「資格証明マップ」を選択します。
3. 「マップ識別子」フィールドに、新しい資格証明マップの名前をLDAPAdminsと入力します。
4. 次の行を追加して、LDAPグループを複数の管理ロールにマップします。

   # Assign full set of administration roles to the LDAP WCPAdministrators group
        WCPAdministrators, admin
        WCPAdministrators, sysmanager
        WCPAdministrators, refineryadmin
        WCPAdministrators, rmaadmin
        WCPAdministrators, pcmadmin
        WCPAdministrators, ermadmin
        #
        # Comment the following if you are not implementing Accounts in Content Server
        WCPAdministrators, @#all(RWDA)
        WCPAdministrators, @#none(RWDA)

   注意:

   アカウントを実装しない場合、前述の例の最後の2行をコメント・アウトします。
5. 「更新」をクリックします。
6. 「管理」→「プロバイダ」に移動します。
7. 既存のJPSプロバイダの「info」リンクをクリックします。
8. 「資格証明マップ」パラメータが、リストされたマップ識別子をまだ持っていないことを確認します。
9. 「編集」ボタンをクリックします。
10. 前述の手順3のマップ識別子の名前を「資格証明マップ」の値として入力します。
11. 「更新」をクリックします。
12. WCCHOST2のInbound Refineryサーバーについて、このプロセスを繰り返します。
13. IBR_Serversクラスタ内の管理対象サーバーを再起動します。
14. weblogic_wcp LDAPユーザーを使用して各Inbound Refineryサーバーにログインし、管理メニュー・オプションがユーザー・インタフェースに表示されていることを確認します。

13.3.3 フォント・パスの指定

Inbound Refineryが正常に機能するには、フォント・イメージを生成するために使用されるフォントへのパスを指定する必要があります。デフォルトでは、フォント・パスはInbound Refineryで使用されるJVM内のフォント・ディレクトリ(MW_HOME/jdk160_version/jre/lib/fonts)に設定されます。ただし、デフォルト・ディレクトリに含まれるフォントは限定されているため、レンディションが低下する可能性があります。また、非標準のJVMを使用した場合、デフォルトで指定されているJVMのフォント・パスと異なることがあります。この場合、エラー・メッセージがInbound Refineryとコンテンツ・サーバーの両方から表示されます。これが発生した場合は、変換を正しくレンダリングするために必要なフォントを含むディレクトリにフォント・パスが設定されていることを確認してください。

詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージメント』のフォント・パスの指定に関する項を参照してください。

13.3.4 Inbound Refineryにジョブを送信して変換するためのコンテンツ・サーバーの設定

Oracle WebCenter Content ServerからInbound Refineryにジョブを送信して変換を実施できるようにするには、次の項の説明に従って、Inbound Refinery管理対象サーバーごとに設定タスクを事前に実行する必要があります。

• 送信プロバイダの作成
  コンテンツ・サーバーからInbound Refineryにファイルを送信して変換を実施するには、「Inbound Refinery変換ジョブの処理」オプションを事前に選択して、コンテンツ・サーバーから各Inbound Refineryへの送信プロバイダを設定する必要があります。
• コンテンツ・サーバーでのInbound Refinery用のコンポーネントの有効化
  変換タイプによっては、コンテンツ・サーバーでヘルパー・コンポーネントを有効にする必要があります。ドキュメント変換にInbound Refineryを使用するコンテンツ・サーバーのインスタンスでは、InboundRefinerySupportコンポーネントを常に有効にする必要があります。新しいコンテンツ・サーバーのインストールではデフォルトで有効になっています。
• 変換するファイル形式の選択
  変換のためにInbound Refineryに送信するファイルをコンテンツ・サーバーに指定するには、ファイル形式を選択する必要があります。

13.3.4.1 送信プロバイダの作成

コンテンツ・サーバーからInbound Refineryにファイルを送信して変換を実施するには、「Inbound Refinery変換ジョブの処理」オプションを事前に選択して、コンテンツ・サーバーから各Inbound Refineryへの送信プロバイダを設定する必要があります。

各Inbound Refineryインスタンスの送信プロバイダを作成する手順は次のとおりです。

1. 次のURLからコンテンツ・サーバーにログインします。

   http://WCCHOST1:16200/cs/

2. 「管理」トレイまたはメニューを開いて、「プロバイダ」を選択します。
3. 「プロバイダ」ページの「新規プロバイダの作成」表で、「送信」行の「追加」をクリックします。
4. 次の値をフィールドに入力します。

   • プロバイダ名: 空白が含まれない短縮名。「インスタンス名」と同じ値を使用することをお薦めします。

   • プロバイダの説明: テキスト文字列。

   • サーバー・ホスト名: Inbound Refineryインスタンスが実行されているホスト・マシンの名前。たとえば、WCCHOST1など。

   • HTTPサーバー・アドレス: Inbound Refineryインスタンスのアドレス。たとえば、WCCHOST1: 16250など。

   • サーバー・ポート: 「Inbound Refineryの設定の構成」で指定されている「サーバーのソケット・ポート」フィールドの値。たとえば、5555など。これは、Inbound Refineryconfig.cfgファイルのIntradocServerPort値です。

   • インスタンス名: 「Inbound Refineryの設定の構成」で指定されているInbound Refineryのサーバー・インスタンス名。これは、Inbound Refineryconfig.cfgファイルのIDC_Name値です。

   • 相対Webルート: Inbound RefineryインスタンスのWebルート。たとえば、/ibr/など

5. 「変換オプション」で、「Inbound Refinery変換ジョブの処理」を選択します。

   「Inbound Refineryの読取り専用モード」は選択しないでください。

6. 「追加」をクリックします。
7. WebLogic Server管理コンソールを使用して、Inbound Refinery管理対象サーバーとOracle WebCenter Content Server (WebCenter Content管理対象サーバー)を再起動します。
8. 「プロバイダ」ページに戻り、プロバイダの「接続状態」の値が「良好」であることを確認します。

   値が「良好」でない場合は、前述のエントリをすべて正しく入力したことを再確認し、コンテンツ・サーバーとInbound Refineryのインスタンスが相互にpingできることを確認します。

9. 2番目のIBRサーバーに対して手順1～8を実行します。

プロバイダの設定の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のContent ServerとRefineryの通信の構成に関する項を参照してください。

13.3.4.2 コンテンツ・サーバーでのInbound Refinery用のコンポーネントの有効化

変換タイプによっては、コンテンツ・サーバーでヘルパー・コンポーネントを有効にする必要があります。ドキュメント変換にInbound Refineryを使用するコンテンツ・サーバーのインスタンスでは、InboundRefinerySupportコンポーネントを常に有効にする必要があります。新しいコンテンツ・サーバーのインストールではデフォルトで有効になっています。

コンテンツ・サーバーでInbound Refineryコンポーネントを有効にする手順は次のとおりです。

1. 次のURLからコンテンツ・サーバーにログインします。

   https://wcp.example.com/cs

2. 「管理」トレイまたはメニューから、「管理サーバー」→「コンポーネント・マネージャ」を選択します。
3. 「コンポーネント・マネージャ」ページで、「Inbound Refinery」を選択し、「Inbound Refinery」で有効にするコンポーネント(XMLConverterSupportなど)を選択したら、「更新」をクリックします。
4. 両方のコンテンツ・サーバーを再起動するために、WebLogic Server管理コンソールを使用してWebCenter Content管理対象サーバーを再起動します。

13.3.4.3 変換するファイル形式の選択

変換のためにInbound Refineryに送信するファイルをコンテンツ・サーバーに指定するには、ファイル形式を選択する必要があります。

変換するファイル形式を選択するには、次の手順を実行します。

1. 次のURLからコンテンツ・サーバーにログインします。

   https://wcp.example.com/cs/

2. 「管理」トレイまたはメニューを開いて「リファイナリ管理」、「ファイル形式ウィザード」の順に選択し、「ファイル形式ウィザード」ページを開きます。

   このページでは、どのファイル形式をコンテンツ・サーバーにチェックインした場合に、そのファイル形式をInbound Refineryに送信して変換を実施するかを指定します。

3. Microsoft Wordドキュメントのdoc、dot、docxおよびdotxなど、変換が必要なフォーマットを選択します。
4. 「更新」をクリックします。

また、構成マネージャでファイル形式を選択することもできます。構成マネージャでは、ウィザードでは示されないファイル形式など、さらにきめ細かく制御できます。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のファイル・タイプの管理に関する項を参照してください。

13.4 Inbound Refinery管理対象サーバーの構成の検証

作成したInbound Refinery管理対象サーバーが正しく構成されているかどうかを確認するには、コンテンツ・サーバーにログインし、変換に有効と認識された拡張子を持つファイルが正しく変換されることを確認して、構成を検証します。

たとえば、変換するフォーマットとしてdocxを選択した場合は、拡張子が.docxのMicrosoft Word文書をPDFフォーマットに変換できます。

チェックインとチェックアウトの手順の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの使用』のドキュメントのアップロードおよびファイルのチェックアウトとダウンロードに関する項を参照してください。

変換プロセスの詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のRefineryにジョブを送信するためのコンテンツ・サーバーの構成に関する項を参照してください。