ヘッダーをスキップ
Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド
11g リリース1(11.1.1)
B55899-03
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

6 Oracle BPMを追加するためのドメインの拡張

Oracle BPMシステムは、前の章でインストールしたWL_HOMEおよびORACLE_HOMEを使用して共有記憶域に作成します。Oracle BPMでは、WebLogic構成ウィザードの手順を実行してドメインを拡張する前に、WL_HOMEとORACLE_HOMEというホームにパッチを適用し、最新のOracle FMW 11.1.1.3(PS2)パッチ・セット・レベルにしておく必要があります。

BPMは、次の2つの方法でFusion Middlewareインストールで有効にできます。

6.1 オプション1: SOAおよびBPMを追加するためのドメインの拡張

この項では、構成ウィザードを使用してドメインを拡張し、SOAおよびBPMのコンポーネントを追加する方法について説明します。さらにそのドメインを拡張してBAMを追加することもできます。ここでは、SOA ORACLE_HOME(バイナリ)がすでにインストールされ、該当する場合はパッチが適用されて最新のパッチ・セットになっており、SOAHOST1およびSOAHOST2からアクセスできると想定しています。また、管理サーバーを含むドメインが作成されていることも想定しています。これが、SOAコンポーネントをサポートする、この章で拡張されるドメインになります。


重要:

セットアップのプロセスを開始する前に、リリース・ノートに目を通してインストールとデプロイメントに関する補足の考慮事項を確認しておくことを強くお薦めします。

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

6.1.1 既存のインストールのバックアップ

この章の手順を開始する前に、既存のFusion Middlewareホームとドメインをバックアップすることをお薦めします。

SOAHOST1> tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw
SOAHOST1> tar -cvpf domainhomeback.tar ORACLE_BASE/admin/domain_name/aserver/domain_name

これらのコマンドにより、Oracle WebLogic ServerとOracle Fusion Middlewareの両方のインストール・ファイルのバックアップ、およびドメイン構成が作成されます。

6.1.2 SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化

この項の手順は、WLS_SOA1およびWLS_SOA2のサーバー移行に必要です。

WLS_SOA1サーバーおよびWLS_SOA2を仮想ホスト名(SOAHOST1VHN1およびSOAHOST2VHN1)に関連付けます。これらの仮想ホスト名がDNSまたはシステム内の/etc/hosts解決で有効になっていること、およびそれらが適切なVIP(VIP2およびVIP3)にマップされていることを確認します。

Linux上で仮想IPを有効にするには、root権限で次のようにifconfigコマンドを実行します。

/sbin/ifconfig <interface:index> IPAddress netmask netmask
/sbin/arping -q -U -c 3 -I interface IPAddress

例:

/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0

次の例のように、ネットワークで仮想IPの新しい場所を登録できるようにします。

/sbin/arping -q -U -c 3 -I ethX 100.200.140.206

次の例のように、別のノードからこのアドレスにpingを実行して、このアドレスが使用可能であることを確認します。

/bin/ping 100.200.140.206

この例で、ethXはイーサネット・インタフェース(eth0またはeth1)、Yはインデックス(0、1、2)です。

6.1.3 SOAHOST1での構成ウィザードを使用した現在のドメインの拡張

SOAホーム・ディレクトリで構成ウィザードを実行して、管理サーバーとOracle Web Services Managerを持つドメインを拡張し、SOAおよびBPMのコンポーネントをサポートするようにします。

  1. リポジトリをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

  2. ディレクトリを構成ウィザードの場所に変更します。これはSOAホーム・ディレクトリ内にあります。

    SOAHOST1> cd ORACLE_COMMON_HOME/common/bin

  3. Oracle Fusion Middleware構成ウィザードを開始します。

    SOAHOST1> ./config.sh

  4. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

  5. WebLogicドメイン・ディレクトリ画面で、WebLogicドメイン・ディレクトリORACLE_BASE/admin/domain_name/aserver/domain_nameを選択し、「次へ」をクリックします。

  6. 「拡張ソースの選択」画面で、次の手順を実行します。

    • 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。次の製品を選択します。

    • 次の製品を選択します。

      • Oracle BPM Suite - 11.1.1.0 [soa]

      • Oracle SOA Suite - 11.1.1.0 [soa](これは、Oracle BPM Suiteを選択すると自動的に選択されます)

      • Oracle WSM Policy Manager 11.1.1.0 [oracle_common](これは、Oracle BPM Suiteを選択すると自動的に選択されます)

      • Oracle Enterprise Manager - 11.1.1.0 [oracle_common]

      • Oracle JRF - 11.1.1.0 [oracle_common](これは自動的に選択されてグレー表示されます)

      いくつかのターゲットを間違って選択解除した場合は、次の項目が選択されていることを確認します。

      • Oracle SOA

      • Oracle BPM Suite

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

  7. 「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。

    • 「SOAインフラストラクチャ」→「ユーザー・メッセージング・サービス」→SOA MDSスキーマを選択します。

    • 「次のパネルで選択したコンポーネント・スキーマをRACマルチ・データ・ソース・スキーマとして構成します。」を選択します。

    図6-1「JDBCコンポーネント・スキーマの構成」画面

    図6-1の説明
    「図6-1 「JDBCコンポーネント・スキーマの構成」画面」の説明

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

  8. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面が表示されます。この画面の次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。この情報はスキーマごとに入力します(複数のスキーマを選択して、すべてに共通する値を指定できます)。

    図6-2 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面

    図6-2の説明
    「図6-2 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面」の説明

    この画面で、次の手順を実行します。

    すべてのスキーマを選択し、すべてに共通する値を入力できます。OWSM MDSスキーマの情報はすでに第 4 章で構成されているのでそのままにしておきます。

    次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。各スキーマに入力する情報は次のとおりです。

    1. 最初のRAC DBインスタンスのホスト名、インスタンス名およびポートを入力します。

    2. 「追加」をクリックします。

    3. この手順をRACインスタンスごとに実行します。

    4. ドライバ: 「Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11」を選択します。

    5. サービス名: データベースのサービス名を入力します(soaedg.mycompany.comなど)。

    6. ユーザー名: スキーマの完全なユーザー名(接頭辞を含む)を入力します。すべてのスキーマが選択されている値(接頭辞など)を入力してから、各スキーマを個別に選択して残りのスキーマ名を変更します。

    7. パスワード: スキーマへのアクセスに使用するパスワードを入力します。

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

  9. 「JDBCデータ・ソースのテスト」画面で、各接続のテストが自動的に行われます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。

    すべての接続に成功したら「次へ」をクリックします。

  10. オプションの構成画面で、次の項目を選択します。

    • JMS分散宛先

    • 管理対象サーバー、クラスタ、およびマシン

    • デプロイメントとサービス

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

  11. 「JMS分散宛先タイプの選択」画面で、すべてのFusion MiddlewareコンポーネントのJMSモジュールのドロップダウン・リストから「UDD」を選択します。


    注意:

    Fusion MiddlewareコンポーネントでのWDDの使用はサポートされません。

  12. 「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。

    soa_server1というサーバーが自動的に作成されます。このサーバーの名前をWLS_SOA1に変更し、WLS_SOA2という新しいサーバーを追加します。表6-1に示す属性をこれらのサーバーに割り当てます。この画面に表示されている他のサーバーは、このまま変更しません。

    表6-1 管理対象サーバー

    名前 リスニング・アドレス リスニング・ポート SSLリスニング・ポート SSL有効

    WLS_SOA1

    SOAHOST1VHN1

    8001

    なし

    いいえ

    WLS_SOA2

    SOAHOST2VHN1

    8001

    なし

    いいえ

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

  13. 「クラスタの構成」画面で、表6-2に示すクラスタを追加します。この画面に表示されている他のクラスタは、このまま変更しません。

    表6-2 クラスタ

    名前 クラスタ・メッセージング・モード マルチキャスト・アドレス マルチキャスト・ポート クラスタ・アドレス

    SOA_Cluster

    ユニキャスト

    なし

    なし

    空白

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

  14. 「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。

    • SOA_Cluster:

      • WLS_SOA1

      • WLS_SOA2

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

  15. 「マシンの構成」画面で、次の手順を実行します。

    • 「削除」をクリックして、デフォルトの「LocalMachine」を削除します。

    • 「Unixマシン」タブをクリックします。SOAHOST1マシンとSOAHOST2マシンには、次のエントリが表示されます(表6-3)。

      表6-3 マシン

      名前 ノード・マネージャのリスニング・アドレス

      SOAHOST1

      SOAHOST1

      SOAHOST2

      SOAHOST2

      ADMINHOST

      localhost

    その他すべてのフィールドはデフォルト値のままにします。

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

  16. 「サーバーのマシンへの割当」画面で、次の項目を追加します。

    • AdminServerをADMINHOSTに割り当てます。

    • WLS_SOA1をSOAHOST1に割り当てます。

    • WLS_SOA2をSOAHOST2に割り当てます。

    • WLS_WSM1をSOAHOST1に割り当てます。

    • WLS_WSM2をSOAHOST2に割り当てます。

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

  17. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

    • WSM-PMはWSM-PM_Clusterにのみターゲット設定します。

    • oracle.rules.*、oracle.sdp.*、oracle.bpm.*およびoracle.soa.*の各デプロイメントは、SOA_Clusterにのみターゲット設定します。

    • oracle.wsm.seedpoliciesライブラリは、WSM-PM_ClusterおよびSOA_Clusterにのみターゲット設定します(SOA_Clusterにwebservices自体を含める場合)。

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

  18. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

    • JOC起動クラスとJOC停止クラスは、WSM-PM_Clusterにのみターゲット設定します。

    • mds-owsm、mdw-owsm-rac0、mds-owsm-rac1の各データソースは、WSM-PM_ClusterおよびAdminServerにターゲット設定します。

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

  19. 「構成のサマリ」画面で、「拡張」をクリックします。

  20. 「ドメインの作成中」画面で、「完了」をクリックします。

    この構成を有効にするには、管理サーバーを再起動する必要があります。管理サーバーを再起動するには、第4.7項「SOAHOST1での管理サーバーの起動」の手順を使用します。

6.1.4 コンポジットをデプロイするためのOracle Coherenceの構成

コンポジットのデプロイではマルチキャスト通信がデフォルトで使用されますが、SOAエンタープライズ・デプロイメントではユニキャスト通信の使用をお薦めします。セキュリティ上の理由からマルチキャスト通信を無効にしている場合は、ユニキャストを使用します。


注意:

デプロイメントに使用するOracle Coherenceフレームワークの構成が正しくないと、SOAシステムを起動できないことがあります。SOAシステムを実行するネットワーク環境に応じて、デプロイメント・フレームワークを適切にカスタマイズする必要があります。この項で説明する構成の使用をお薦めします。

ユニキャスト通信を使用したデプロイメントの通信の有効化

マルチキャスト通信を使用すると、クラスタの中でコンポジットの動的なデプロイメント先となるすべてのメンバーをOracle Fusion Middleware SOAで検出できます。しかし、ユニキャスト通信を使用した場合、この方法ではノードから他のクラスタ・メンバーを検出できません。したがって、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加した新しいノードから既存ノードのいずれかを検出するために必要な数のノードを指定するだけでかまいません。この結果、クラスタに追加した新しいノードからクラスタにある他のすべてのノードを検出できます。また、同じマシンで複数のIPを使用できるSOAエンタープライズ・デプロイメントなどの構成では、特定のホスト名を使用してOracle Coherenceクラスタを作成するようにOracle Coherenceを構成する必要があります。


ヒント:

SOAコンポジットのデプロイメント時に高可用性を確保するには、適切な数のノードを指定して、どの時点でもそのうちのいずれかが必ず稼働しているようにします。

tangosol.coherence.wka<n>システム・プロパティを使用してノードを指定します(<n>は1から9の番号)。指定できるノードは最大9個です。番号は1から開始します。以降、この番号は順番に割り当てる必要があり、不連続に割り当てることはできません。また、Oracle Coherenceでクラスタを作成するために使用するホスト名をtangosol.coherence.localhostシステム・プロパティで指定します。このローカル・ホスト名には、SOAサーバーでリスナーのアドレスとして使用する仮想ホスト名を指定する必要があります(SOAHOST1VHN1とSOAHOST2VHN1)。このプロパティを設定するには、Oracle WebLogic Server管理コンソールの「サーバーの起動」タブにある「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加します(図6-3)。


注意:

SOAHOST1VHN1は、SOAHOST1でWLS_SOA1がリスニングする仮想IPにマップされる仮想ホスト名です。SOAHOST2VHN1は、SOAHOST2でWLS_SOA2がリスニングする仮想IPにマップされる仮想ホスト名です。

図6-3 Oracle WebLogic Server管理コンソールの「サーバーの起動」タブを使用したホスト名の設定

図6-3の説明
「図6-3 Oracle WebLogic Server管理コンソールの「サーバーの起動」タブを使用したホスト名の設定」の説明

ホスト名の指定

Oracle Coherenceで使用するホスト名を追加するには、次の手順を実行します。

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

  2. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

  3. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

  4. 表の「名前」列にハイパーリンクで表示されているサーバーの名前(WLS_SOA1またはWLS_SOA2)をクリックします。選択したサーバーの「設定」ページが表示されます。

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

  6. 「構成」タブをクリックして、「サーバーの起動」タブをクリックします。

  7. WLS_SOA1とWLS_SOA2について、「引数」フィールドに次の値を入力します。

    WLS_SOA1については次の値を入力します。

    -Dtangosol.coherence.wka1=SOAHOST1VHN1 
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST2VHN1

    WLS_SOA2については次の値を入力します。

    -Dtangosol.coherence.wka1=SOAHOST1VHN1 
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST2VHN1

    注意:

    異なる-Dパラメータの間には、空白の行を入れないでください。テキストは、前述の場所からコピーして管理コンソールの引数テキスト・フィールドに貼り付けないでください。貼り付けると、Java引数にHTMLタグが挿入される可能性があります。このテキストには、前述の例に含まれているテキスト文字以外の文字を入れないでください。

  8. 「保存」→「変更のアクティブ化」をクリックします。


注意:

これらの変数が管理対象サーバーに正しく渡されることを確認する必要があります (これらの変数はサーバーの出力ログに記録されます)。Oracle Coherenceフレームワークに問題があると、soa-infraアプリケーションを起動できないことがあります。


注意:

このマルチキャスト・アドレスとユニキャスト・アドレスは、WebLogic Serverクラスタでクラスタ通信に使用するものとは異なります。SOAでは、2つのエンティティ(WebLogic Serverクラスタおよびコンポジットのデプロイ先グループ)の通信プロトコルが異なる場合でも、単一のWebLogic Serverクラスタの各メンバーにコンポジットを確実にデプロイできます。

6.1.5 B2Bキューでの接続先の識別子の設定

Oracle B2Bでは、特定のJMS宛先メンバー・コールを使用します。これらのコールを成功させるには、作成先識別子(CDI)を設定する必要があります。CDIを設定する手順は次のとおりです。

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

  2. 「ドメイン構造」ウィンドウで「サービス」ノードを開き、「メッセージング」ノードを開きます。

  3. 「JMSモジュール」→「SOAJMSModule」をクリックします。

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

  5. 「dist_B2BEventQueue_auto」→「構成」→「一般」タブをクリックし、「詳細」をクリックします。

  6. 「作成先識別子」フィールドで、キューに次のJNDI名を追加します。

    jms/b2b/B2BEventQueue

  7. この手順を繰り返して、次に一覧表示するキューに対して、次の作成先識別子を作成します。

    • B2B_OUT_QUEUE: jms/b2b/B2B_IN_QUEUE

    • B2B_IN_QUEUE: jms/b2b/B2B_OUT_QUEUE

    • B2BBroadcastTopic: jms/b2b/B2BBroadcastTopic

    • XmlSchemaChangeNotificationTopic: jms/fabric/XmlSchemaChangeNotificationTopic

  8. 保存およびアクティブな変更をクリックします。

6.1.6 WLS_SOA1、WLS_SOA2、管理対象サーバーに対するホスト名検証の無効化

この手順は、管理サーバーで様々なノードを認証するための適切な証明書を設定していない場合に必要です(第8章「ノード・マネージャの設定」を参照)。サーバー証明書を構成していないと、様々なWebLogicサーバーを管理する際にエラーが発生します。このエラーを回避するには、トポロジの設定と検証を行う際にホスト名の検証を無効にし、EDGトポロジの構成完了後に第8章「ノード・マネージャの設定」の説明に従って再びホスト名の検証を有効にします。

ホスト名検証を無効化するには:

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

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

  3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

  4. 「サーバー」をクリックします。

    「サーバーの概要」ページが表示されます。

  5. 表の「名前」列で「WLS_SOA1」(これはハイパーリンクとして表示されています)を選択します。

    「設定」ページが表示されます。

  6. 「SSL」タブを選択します。

  7. 表示されたページの「詳細」セクションを開きます。

  8. 「ホスト名の検証」を「なし」に設定します。

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

  10. WLS_SOA2サーバーについてステップ4から8を繰り返します。

  11. 変更を保存してアクティブ化します。

  12. この変更内容を有効にするには、管理サーバーおよびノード・マネージャを再起動する必要があります。管理サーバーを再起動するには、第4.7項「SOAHOST1での管理サーバーの起動」の手順を実行します。

    1. 管理サーバーを再起動するには、第5.3項「管理サーバーの再起動」の手順を実行します。

    2. SOAHOST1でノード・マネージャを再起動するには、第5.7項「SOAHOST1でのノード・マネージャの再起動」の手順を実行します。

      SOAHOST2でノード・マネージャの処理を繰り返します。

6.1.7 管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播するには:

  1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのコピーを作成します。

  2. SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

    SOAHOST1> cd ORACLE_COMMON_HOME/common/bin

SOAHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/admin/
domain_name/aserver/domain_name -template=soadomaintemplateExtSOABPM.jar
 -template_name=soa_domain_templateExtSOABPM

  3. SOAHOST1でunpackコマンドを実行して、伝播されたテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

    SOAHOST1> ./unpack.sh -domain=ORACLE_BASE/admin/
domain_name/mserver/domain_name -overwrite_domain=true
-template=soadomaintemplateExtSOABPM.jar 
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

    注意:

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

6.1.8 WLS_SOA1管理対象サーバーの起動と検証

WLS_SOA1管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認するには:

  1. 次の手順に従い、Oracle WebLogic Server管理コンソールを使用してWLS_SOA1管理対象サーバーを起動します。

    1. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

    2. 「サーバー」を選択します。

      「サーバーのサマリー」画面が表示されます。

    3. 「制御」タブをクリックします。

    4. 「WLS_SOA1」を選択して、「起動」をクリックします。

  2. サーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第10章「トラブルシューティング」を参照してください。

  3. 次のURLにアクセスします。

    http://SOAHOST1VHN1:8001/soa-infra/(WLS_SOA1のステータスを確認する場合)。

    http://SOAHOST1VHN1:8001/soa/composer/(SOAプロセス・コンポーザのステータスを確認する場合)。


    注意:

    ポリシーやアサーション・テンプレートがまったく表示されない場合は、構成が正しくありません。

    http://SOAHOST1VHN1:8001/integration/worklistapp/(ワークリスト・アプリケーションのステータスを確認する場合)。

    http://SOAHOST1VHN1:8001/b2bconsole/(B2Bのステータスを確認する場合)。

    http://SOAHOST1VHN1:8001/sdpmessaging/userprefs-ui/(メッセージング・システム・プリファレンスのステータスを確認する場合)。

    http://SOAHOST1VHN1:8001/bpm/composer/にアクセスしてコンポーザ・アプリケーションにログインします。

    http://SOAHOST1VHN1:8001/bpm/workspace/にアクセスしてワークスペース・アプリケーションにログインします。

6.1.9 unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播

SOAHOST2にドメイン構成を伝播させるには:

  1. 次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・ファイルをSOAHOST2にコピーします。

    SOAHOST1> cd ORACLE_COMMON_HOME/common/bin

SOAHOST1> scp soadomaintemplateExtSOABPM.jar oracle@node2:ORACLE_COMMON_HOME/common/bin

  2. unpackコマンドをSOAHOST2で実行し、伝播されたテンプレートを解凍します。

    SOAHOST2> cd ORACLE_COMMON_HOME/common/bin

SOAHOST2> ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name 
-overwrite_domain=true -template=soadomaintemplateExtSOABPM.jar 
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

    注意:

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

6.1.10 SOAHOST2でのXEngineファイルの抽出

SOAHOST2でB2BのXEngineを有効にするには、次のようにXEngine tarの内容を手動で抽出する必要があります。

SOAHOST2>cd ORACLE_HOME/soa/thirdparty/edifecs
SOAHOST2>tar -xzvf XEngine.tar.gz

6.1.11 WLS_SOA2管理対象サーバーの起動と検証

WLS_SOA2管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認するには:

  1. 次の手順に従い、Oracle WebLogic Server管理コンソールを使用してWLS_SOA2管理対象サーバーを起動します。

    1. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

    2. 「サーバー」を選択します。

      「サーバーのサマリー」画面が表示されます。

    3. 「制御」タブをクリックします。

    4. 「WLS_SOA2」を選択して、「起動」をクリックします。

  2. サーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第10章「トラブルシューティング」を参照してください。

  3. 次のURLにアクセスします。

    http://SOAHOST2VHN1:8001/soa-infra(WLS_SOA2のステータスを確認する場合)。

    http://SOAHOST2VHN1:8001/soa/composer(SOAプロセス・コンポーザのステータスを確認する場合)。


    注意:

    ポリシーやアサーション・テンプレートがまったく表示されない場合は、構成が正しくありません。

    http://SOAHOST2VHN1:8001/integration/worklistapp(ワークリスト・アプリケーションのステータスを確認する場合)。

    http://SOAHOST2VHN1:8001/b2bconsole(B2Bのステータスを確認する場合)。

    http://SOAHOST2VHN1:8001/sdpmessaging/userprefs-ui(メッセージング・システム・プリファレンスのステータスを確認する場合)。

    http://SOAHOST2VHN1:8001/bpm/composerにアクセスしてコンポーザ・アプリケーションにログインします。

    http://SOAHOST2VHN1:8001/bpm/workspaceにアクセスしてワークスペース・アプリケーションにログインします。

6.1.12 WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成

WLS_SOAn管理対象サーバーが属するSOA_ClusterにOracle HTTP Serverからルーティングできるようにするには、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定する必要があります。

  1. WEBHOST1とWEBHOST2で、ORACLE_BASE/ admin/instance_name/config/OHS/component_name/mod_wl_ohs.confファイルに次の行を追加します。

    # SOA soa-infra app
<Location /soa-infra>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# Worklist
<Location /integration>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# B2B
<Location /b2bconsole>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# Workflow
<Location /workflow>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

#Required if attachments are added for workflow tasks
 <Location /ADFAttachmentHelper> 
    SetHandler weblogic-handler 
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# SOA composer application 
 <Location /soa/composer> 
     SetHandler weblogic-handler 
     WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# BPM
<Location /bpm/composer>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# BPM
<Location /bpm/workspace>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

    mod_wl_ohsファイルと同じディレクトリに格納されているhttpd.confファイルに、次の行が記述されていることを確認します。

    NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://soa.mycompany.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

NameVirtualHost *:7777
<VirtualHost *:7777>
    ServerName admin.mycompany.com:80
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit
</VirtualHost>

    注意:

    ここであげているsoa.mycompany.com:443、7777、admin.mycompany:80、you@youraddressなどの値は、単なる例です。これらのかわりに、実際の環境に基づいた値を入力してください。

  2. WEBHOST1およびWEBHOST2で、Oracle HTTP Serverを再起動します。

    WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1
WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2

WebLogicClusterパラメータで指定したサーバーは、起動時のプラグインに対してのみ重要な役割を持ちます。このノードのリストには、実行しているクラスタ・メンバーを1つ以上記述しておく必要があります。記述しておかないと、このプラグインで他のクラスタ・メンバーを検出できません。Oracle HTTP Serverの起動時には、リストに記述したクラスタ・メンバーを実行している必要があります。Oracle WebLogic Serverとこのプラグインの連携により、クラスタに発生した新規のメンバー、失敗したメンバーおよびリカバリしたメンバーを反映してサーバーのリストが自動的に更新されます。

次に例を示します。

  • 例1: 2つのノードで構成したクラスタに3番目のメンバーを追加する場合、そのメンバーを追加するために構成を更新する必要はありません。3番目のメンバーは、実行時に自動的に検出されます。

  • 例2: クラスタは3つのノードで構成されていても、構成に記述されているノードはそのうちの2つのみであるとします。Oracle HTTP Serverを起動するときにこの2つのノードが両方とも停止していると、プラグインはクラスタを検出できません。Oracle HTTP Serverを起動するときは、リストに記述したノードを1つ以上実行している必要があります。

    クラスタのメンバーをすべてリストに記述した場合は、Oracle HTTP Serverの起動時にそのうちの1つ以上を実行しておくことで、クラスタに確実に到達できます。

WebLogic Serverプラグインの構成の詳細は、Oracle WebLogic ServerでWeb Serverプラグインを使用するOracle Fusion Middlewareのガイドを参照してください。

6.1.13 Oracle HTTP Serverを介したアクセスの検証

サーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第10.7項「トラブルシューティング」を参照してください。

次のURLにアクセスできることを確認します。webhostNには、各Oracle HTTP Serverホストの名前を指定します(WEBHOST1やWEBHOST2など)。

  • http://WEBHOST1:7777/soa-infra

  • http://WEBHOST2:7777/soa-infra

  • http://WEBHOST1:7777/soa/composer

  • http://WEBHOST2:7777/soa/composer

  • http://WEBHOST1:7777/integration/worklistapp

  • http://WEBHOST2:7777/integration/worklistapp

  • http://WEBHOST1:7777/sdpmessaging/userprefs-ui

  • http://WEBHOST2:7777/sdpmessaging/userprefs-ui

  • http://WEBHOST1:7777/b2bconsole

  • http://WEBHOST2:7777/b2bconsole

  • http://WEBHOST1:7777/bpm/composer

  • http://WEBHOST2:7777/bpm/composer

  • http://WEBHOST1:7777/bpm/workspace

  • http://WEBHOST2:7777/bpm/workspace

これらのURLは、LBRアドレスを使用して確認することもできます。

  • http://soa.mycompany.com:80/soa-infra

  • http://soa.mycompany.com:80/soa/composer

  • http://soa.mycompany.com:80/integration/worklistapp

  • http://soa.mycompany.com:80/sdpmessaging/userprefs-ui

  • http://soa.mycompany.com:80/b2bconsole

  • http://soa.mycompany.com:80/bpm/composer

  • http://soa.mycompany.com:80/bpm/workspace

ロード・バランサを介したシステム・アクセスの構成は、第2.2.2項「ロード・バランサ」を参照してください。

6.1.14 フロントエンドHTTPホストおよびポートの設定

Oracle WebLogic Serverクラスタについて、フロントエンドHTTPのホストとポートを設定する必要があります。

  1. WebLogic Server管理コンソールの「チェンジ・センター」セクションの「ロックして編集」をクリックします。

  2. 左ペインの「ドメイン構造」ウィンドウで「環境」を選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。

  3. SOA_Clusterクラスタを選択します。

  4. 「HTTP」を選択します。

  5. 次の値を設定します。

    • フロントエンド・ホスト: soa.mycompany.com

    • フロントエンドHTTPSポート: 443

    • フロントエンドHTTPポート: 80

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

  7. 変更を有効にするために、管理コンソールの「チェンジ・センター」セクションの「変更のアクティブ化」をクリックします。

  8. サーバーを再起動して、クラスタのフロントエンド・ホストの指定を有効化します。


注意:

フロントエンドHTTPのホストとポートを設定していない場合は、Oracle B2Bからドキュメント定義のXSDを取得しようとすると次のメッセージが表示されます。 
An error occured while loading the document definitions.
java.lang.IllegalArgumentException: Cluster address must be set when clustering is enabled.

コールバックURL

SOAシステムでは、次のようにコールバックURLを計算します。

  • SOAへのリクエストが外部または内部のサービスから発行された場合、SOAはクライアントで指定されたコールバックURLを使用します。

  • 外部または内部の非同期サービスへのリクエストがSOAから発行された場合は、次の方法でコールバックURLが決定されます。ここでは決定方法の優先度が高い順に示しています。

    1. 特定の参照用のバインド・プロパティとして指定されたcallbackServerURLを使用します(このプロパティは、コンポジットのモデリング時または実行時にMBeansを使用して設定できます)。これにより、サービス呼び出しごとに異なるコールバックURLを割り当てることができます。つまり、外部サービスからのコールバックURLには、内部サービスへのコールバックURLとは異なる値を設定できます。EDGアーキテクチャでの一般的なコールバックURLは、外部サービスについてはsoa.mycompany.com(443/https)、内部サービスについてはsoainternal.mycompany.com(7777/http)です。このプロパティは、システムMBeanブラウザに対応するバインドmbeanを通じ、実行時にシステムMBeanブラウザを使用して設定します。特定のURLを追加するには、そのProperties属性にcallbackServerURLプロパティを追加してから保存操作を実行します。

    2. soa-infra-config.xmlで指定したコールバックURLを使用します。この場合、指定できるアドレスは1つのみです。外部サービスと内部サービスの両方を組み合せて呼び出し可能な場合は、EDGアーキテクチャでこのアドレスをsoa.mycompany.com(443/https)に設定する必要があります。内部サービスのみを呼び出す場合は、このアドレスをsoainternal.mycompany.com(7777/http)に設定します。

    3. SOA_ClusterのWLSで指定するフロントエンド・ホストとして、このコールバックURLを使用します。この場合も指定できるアドレスは1つのみなので、soa-infra-config.xmlの場合と同じ処理をお薦めします。

    4. WLS MBean APIで指定されたローカル・ホスト名を使用します。EDGなどのHA環境では、この方法はお薦めできません。

6.1.15 コンポジットに対する直接バインディング/RMI呼出し用のWLSクラスタ・アドレスの設定

直接バインディング・コンポジットを使用する場合は、SOA_ClusterにWLSクラスタ・アドレスを設定する必要があります。WLSクラスタ・アドレスを設定する手順は次のとおりです。

  1. WebLogic Server管理コンソールの「チェンジ・センター」セクションの「ロックして編集」をクリックします。

  2. 左ペインの「ドメイン構造」ウィンドウで「環境」を選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。

  3. SOA_Clusterクラスタを選択します。

  4. 「構成」→「一般」タブで、「クラスタ・アドレス」フィールドに次のように入力します。

    SOAHOST1VHN1:8001,SOAHOST2VHN1:8001

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

  6. 変更を有効にするために、管理コンソールの「チェンジ・センター」セクションの「変更のアクティブ化」をクリックします。

  7. サーバーを再起動して、クラスタのフロントエンド・ホストの指定を有効化します。


    注意:

    直接バインディングを介してリクエスト/レスポンスが非同期でやり取りされるようにするため、SOAコンポジットでは、JNDIプロバイダURLを提供して、呼び出されたサービスが、コールバックするBeanを検索できるようにする必要があります。

    soa-infraの構成プロパティは指定されていないがWLSクラスタ・アドレスが指定されている場合は、JNDIプロバイダURLのクラスタ・アドレスが使用されます。このクラスタ・アドレスには、クラスタ化されたサーバーのIPアドレスにマップする単一のDNS名を指定することも、サーバーip:portのカンマ区切りリストを指定することもできます。また、ユーザーが明示的に設定していれば、soa-infraの構成プロパティJndiProviderURL/SecureJndiProviderURLを同じ目的に使用することもできます。

6.1.16 共有JMS永続ストアの構成

すべての永続ストアの場所を、両ノードから認識できるディレクトリとして構成します。詳細は、第4.1項「Oracle Fusion Middlewareホームのインストール」を参照してください。次のように、この共有ベース・ディレクトリを使用するようにすべての永続ストアを変更する必要があります。

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

  2. 「ドメイン構造」ウィンドウの「サービス」ノードを開いて「永続ストア」ノードをクリックします。

    「永続ストアの概要」ページが表示されます。

  3. 表の「名前」列で、該当の永続ストア(これはハイパーリンクとして表示されています)を選択します。

    その永続ストアの「設定」ページが表示されます。

  4. 「構成」タブの「ディレクトリ」フィールドに、クラスタにある他のサーバーで使用できる永続記憶域ソリューション(NASやSANなど)上の場所を入力します。

    この場所を指定すると、JMSの保留メッセージを送信できます。この場所は、次のディレクトリ構造であることが必要です。

    ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

    注意:

    WLS_SOA1とWLS_SOA2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。

  5. 「保存」をクリックして変更内容を有効にします。

  6. サーバーを再起動して永続ストアの変更内容を有効にします。

6.1.17 トランザクション・リカバリ用デフォルト永続ストアの構成

各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。WebLogic Serverでは、システム・クラッシュやネットワーク障害からのリカバリ時にこのトランザクション・ログを使用します。クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセスできる場所にトランザクション・ログを格納します。


注意:

デュアルポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)をこの場所とすることをお薦めします。

デフォルト永続ストアの場所を設定するには、次の手順を実行します。

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

  2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」ノードをクリックします。「サーバーの概要」ページが表示されます。

  3. 表の「名前」列にあるサーバーの名前(ハイパーリンクとして表示されています)をクリックします。選択したサーバーの「設定」ページが表示され、デフォルトで「構成」タブが選択状態になります。

  4. 「サービス」タブをクリックします。

  5. 表示されたページの「デフォルト・ストア」セクションで、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。このパスのディレクトリ構造は次のとおりです。

    ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

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


注意:

トランザクション・リカバリ・サービスの移行を有効にするには、クラスタにある他のサーバーが使用できる永続記憶域ソリューションの場所を指定します。WLS_SOA1とWLS_SOA2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。

6.1.18 OracleファイルとFTPアダプタの高可用性化

OracleファイルとFTPアダプタを使用すると、BPELプロセスやOracle MediatorでFTP(ファイル転送プロトコル)を使用して、ローカルとリモートのファイル・システムにあるファイルの読取りと書込みができます。これらのアダプタは、インバウンドとアウトバウンドの両方の操作に対し、Oracle BPEL Process ManagerとOracle Mediatorサービス・エンジンを使用してアクティブ/アクティブ・トポロジの高可用性をサポートします。OracleファイルやFTPアダプタのアウトバウンド操作に対する高可用性を実現するには、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のアウトバウンド操作の高可用性に関する項の説明に従って、データベースのmutex lock操作を使用します。データベースのmutex lock操作を使用すると、複数の参照から同じディレクトリへの書込みが発生しても、これらのアダプタでは相互の上書きを防止できます。


注意:

ファイル・アダプタは、インバウンド・ディレクトリからファイルを取得して処理し、出力ディレクトリにファイルを出力します。ファイル・アダプタでの処理はトランザクション方式ではないので、ファイルは2回処理できます。この結果として、RACバックエンドまたはSOA管理対象サーバーでフェイルオーバーが発生したときに、重複するファイルが得られる可能性があります。

6.1.18.1 データベースのmutex lock操作の使用

データベース表をコーディネータとして使用することで、アウトバウンドのOracleファイルやFTPアダプタのサービスに高可用性を実現します。そのためには次の手順を実行します。


注意:

FTPアダプタの手順および構成オプションは、フィルタ・アダプタのオプションと完全に同じです。FTP HAの構成に使用する接続ファクトリは、FTPアダプタ・デプロイメントの送信接続プールの下に表示されるeis/Ftp/HAFtpAdapterです。


注意:

データベースをコーディネータとして使用する場合は、グローバル・トランザクション・タイムアウトの値を大きくする必要があります。

  1. データベース表の作成

    データベース・スキーマはsoainfraの一部として事前に作成済なので、この手順を実行する必要はありません。

  2. Oracleファイル・アダプタのデプロイメント・ディスクリプタの変更

    eis/HAFileAdapterに対応する接続インスタンスについて、Oracle WebLogic ServerコンソールからOracleファイル・アダプタのデプロイメント・ディスクリプタを変更します。

    1. Oracle WebLogic Serverコンソールにログインします。このコンソールにアクセスするには、http://servername:portnumber/consoleにアクセスします。

    2. 「ドメイン構造」の左ペインで「デプロイメント」をクリックします。

    3. 右ペインの「デプロイメントの概要」で「FileAdapter」をクリックします。

    4. 「構成」タブをクリックします。

    5. 「アウトバウンド接続プール」タブをクリックして「javax.resource.cci.ConnectionFactory」を開き、構成済の接続ファクトリを表示します。

    6. 「eis/HAFileAdapter」をクリックします。高可用性に対応する接続ファクトリの「アウトバウンド接続のプロパティ」が表示されます。

    7. 図6-4に示すように、接続ファクトリのプロパティが表示されます。

      図6-4 Oracle WebLogic Serverコンソール - 「javax.resource.cci.Connectionfactoryの設定」ページ

      図6-4の説明
      「図6-4 Oracle WebLogic Serverコンソール - 「javax.resource.cci.Connectionfactoryの設定」ページ」の説明

      「ロックして編集」をクリックします。これにより、プロパティ値の列が編集可能になります(「プロパティ値」列で任意の行をクリックしてその値を変更できます)。

      OracleファイルとFTPアダプタの接続ファクトリの新しいパラメータは次のとおりです。

      controlDir: 制御ファイルを格納するディレクトリ構造に設定します。1つのクラスタの中で複数のWebLogic Serverインスタンスを実行する場合は、この値を共有場所に設定する必要があります。この共有記憶域のディレクトリは次のような構造にします。

      ORACLE_BASE/admin/<domain_name>/<cluster_name>/fadapter

      inboundDataSource: jdbc/SOADataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。事前作成スキーマはORACLE_HOME/ rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sqlにあります。事前作成スキーマを別の場所で作成する場合は、このスクリプトを使用します。別のスキーマを選択する場合は、それに応じてinboundDataSourceプロパティを設定する必要があります。

      outboundDataSource: jdbc/SOADataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。事前作成スキーマはORACLE_HOME/ rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sqlにあります。事前作成スキーマを別の場所で作成する場合は、このスクリプトを使用します。その場合は、outboundDataSourceプロパティを設定する必要があります。

      outboundDataSourceLocal: jdbc/SOADataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータソースです。

      outboundLockTypeForWrite: Oracle Databaseを使用している場合は、この値をoracleに設定します。デフォルトでは、OracleファイルとFTPアダプタはメモリー内mutexを使用してアウトバウンドの書込み操作をロックします。書込み操作を同期化するには、次の値のいずれかを選択する必要があります。

      memory: OracleファイルとFTPアダプタはメモリー内mutexを使用してファイル・システムへのアクセスを同期化します。

      oracle: アダプタはOracle Databaseシーケンスを使用します。

      db: アダプタは事前作成されたデータベース表(FILEADAPTER_MUTEX)をロック・メカニズムとして使用します。このオプションは、Oracle Databaseスキーマ以外のスキーマを使用している場合にのみ使用します。

      user-defined: アダプタはユーザー定義のmutexを使用します。ユーザー定義のmutexを構成するには、mutexインタフェースoracle.tip.adapter.file.Mutexを実装し、新しいバインド・プロパティoracle.tip.adapter.file.mutexを構成して、その値にアウトバウンド参照のmutexの完全修飾クラス名を指定します。

    8. これらのプロパティを更新した後、「保存」をクリックします。「デプロイメント・プランの保存」ページが表示されます。

    9. デプロイメント・プランの共有記憶域場所を入力します。そのディレクトリ構造は次のとおりです。

      ORACLE_BASE/admin/<domain_name>/<cluster_name>/dp/Plan.xml

    10. 保存してアクティブ化をクリックします。

    11. 次の例のように、接続ファクトリが使用されるようにBPELプロセスまたはMediatorシナリオを構成します。

      <adapter-config name="FlatStructureOut" adapter="File Adapter" xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
  <connection-factory location="eis/HAFileAdapter" adapterRef=""/>
  <endpoint-interaction portType="Write_ptt" operation="Write">
<interaction-spec className="oracle.tip.adapter.file.outbound.FileInteractionSpec">
      <property../>
      <property../>
    </interaction-spec>
  </endpoint-interaction>
</adapter-config>

      注意:

      location属性は、接続ファクトリのeis/HAFileAdapterに設定されています。

6.1.19 Oracleデータベース・アダプタのスケーリング

論理削除ポーリングを使用していて、MarkReservedValueを設定している場合は、ロックのスキップは使用されません。

以前は、複数のOracle BPEL Process ManagerノードまたはOracle Mediatorノードにデプロイする複数のOracleデータベース・アダプタ・プロセス・インスタンスにおける最善の手法は、基本的に、ポーリング・ノードごとに一意のMarkReservedValueを設定し、さらにMaxTransactionSizeを設定して、LogicalDeletePollingStrategyまたはDeletePollingStrategyを使用することでした。

ただし、今回のリリースでロックのスキップが導入されたため、そのアプローチは破棄されました。以前にこのアプローチを使用していた場合は、MarkReservedValueを(db.jcaで)削除するか、または(ウィザードの「論理削除」ページで)消去するだけです。それによってロックが自動的にスキップされるようになります。

予約された値に対してロックのスキップを使用することには、次のような利点があります。

  • ロックをスキップすると、クラスタにおいて、また負荷がかかっている状態で、スケーリングが向上します。

  • (更新/予約→コミットを行ってから新しいトランザクションで選択するのとは反対に)すべての作業が1つのトランザクションで行われるため、高可用性環境でリカバリ不能な状況に直面するリスクが最小に抑えられます。

  • 一意のMarkReservedValueを指定する必要がありません。以前は、そのようにするためには、R${weblogic.Name-2}-${IP-2}-${instance}のように、複雑な変数を構成することが必要でした。

詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のスケーラビリティとポーリング計画に関する項を参照してください。

6.1.20 インストールのバックアップ

拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、このガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。データベースのバックアップに関する詳細は、Oracle Database バックアップおよびリカバリ・ガイドも参照してください。

この時点でインストールをバックアップする手順は次のとおりです。

  1. Web層をバックアップする手順は次のとおりです。

    1. opmnctlを使用してインスタンスを停止します。

      ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

    2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

      tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

    3. 次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。

      tar -cvpf BACKUP_LOCATION/web_instance.tar ORACLE_INSTANCE

    4. opmnctlを使用してインスタンスを起動します。

      ORACLE_BASE/admin/instance_name/bin/opmnctl startall

  2. データベースをバックアップします。これは、Oracle Recovery Manager(推奨)またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。

  3. 管理サーバーのドメイン・ディレクトリをバックアップしてドメイン構成を保存します。構成ファイルは、すべてORACLE_BASE/admin/<domain_name>ディレクトリの下にあります。

    SOAHOST1> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

注意:

ORACLE_HOMEのバックアップは、B2B設定の一部であるXEngine構成が変更されたときに実行する必要があります。対象のファイルは、ORACLE_HOME/soa/thirdparty/edifecs/XEngineにあります。ORACLE_HOMEをバックアップするには、次のコマンドを実行してください。 
SOAHOST1> tar -cvpf fmwhomeback.tar MW_HOME

6.2 オプション2: Oracle BPMを追加するためのSOAドメインの拡張

この手順では、第5章「SOAコンポーネントを使用するためのドメインの拡張」で作成したドメインを、BPMを扱うことができるように拡張します。さらにそのドメインを拡張してBAMを追加することもできます。ここでは、SOA ORACLE_HOME(バイナリ)がすでにインストールされ、パッチが適用されてOracle FMW 11.1.1.3(PS2)パッチ・セット・レベルになっており、SOAHOST1およびSOAHOST2からアクセスできると想定しています(これは、WebLogic構成ウィザードの手順を実行してドメインを拡張する前に実行する必要があります)。

この項に示す手順では、ノード・マネージャ、管理サーバー、SOAサーバーおよびWSMサーバーが存在し、前の章の説明のように、SOAシステムを実行するように構成されていると想定しています。サーバー移行、トランザクション・ログ、Coherenceなど、SOAシステムのすべての構成手順はすでに実行されているので、BPMで使用されます。BPMは、既存の構成のスーパーセットとして追加されます。

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

6.2.1 既存のインストールのバックアップ

この項の手順を開始する前に、既存のFusion Middlewareホームとドメインをバックアップすることをお薦めします。最初に管理サーバーを停止することを忘れないでください。

SOAHOST1> tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw
SOAHOST1> tar -cvpf domainhomeback.tar ORACLE_BASE/admin/domain_name/aserver/domain_name

これらのコマンドにより、Oracle WebLogic ServerとOracle Fusion Middlewareの両方のインストール・ファイルのバックアップ、およびドメイン構成が作成されます。

6.2.2 SOAHOST1での構成ウィザードを使用したBPMを追加するためのSOAドメインの拡張

SOAホーム・ディレクトリで構成ウィザードを実行して、管理サーバーとOracle Web Services Managerを持つドメインを拡張し、SOAおよびBPMのコンポーネントをサポートするようにします。

  1. ディレクトリを構成ウィザードの場所に変更します。これはSOAホーム・ディレクトリ内にあります。ドメインの拡張は、管理サーバーが存在するノードから実行します。

    SOAHOST1> cd ORACLE_HOME/common/bin

  2. Oracle Fusion Middleware構成ウィザードを開始します。

    SOAHOST1> ./config.sh

  3. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

  4. WebLogicドメイン・ディレクトリ画面で、WebLogicドメイン・ディレクトリORACLE_BASE/admin/domain_name/aserver/domain_nameを選択し、「次へ」をクリックします。

  5. 「拡張ソースの選択」画面で、次の手順を実行します。

    • 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。次の製品を選択します。

    • 次の製品を選択します。

      • Oracle BPM Suite - 11.1.1.0 [soa]

  6. 「JDBCコンポーネント・スキーマの構成」画面に入力されている値(既存のSOAシステムで作成されたスキーマ)を受け入れて、「次へ」をクリックします。

    BPMでは、既存のsoa-infraシステムと同じデータソースが使用されます。

  7. オプションの構成画面で、次の項目を選択します。

    • JMS分散宛先

    • デプロイメントとサービス

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

  8. 「JMS分散宛先タイプの選択」画面で、BPMJMSModuleのドロップダウン・リストから「UDD」を選択します。既存のモジュールはそのままにします。

  9. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

    • WSM-PMはWSM-PM_Clusterにのみターゲット設定します。

    • usermessagingserverおよびusermessagingdriver-emailは、SOA_Clusterにのみターゲット設定する必要があります (usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです)。

    • oracle.rules.*、oracle.sdp.*、oracle.bpm.*およびoracle.soa.*の各デプロイメントは、SOA_Clusterにのみターゲット設定します。

    • oracle.wsm.seedpoliciesライブラリは、WSM-PM_ClusterおよびSOA_Clusterにのみターゲット設定する必要があります。

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

  10. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

    • JOC起動クラスとJOC停止クラスは、WSM-PM_Clusterにのみターゲット設定します。

    • mds-owsm、mdw-owsm-rac0、mds-owsm-rac1の各データソースは、WSM-PM_ClusterおよびAdminServerにターゲット設定します。

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

  11. 「構成のサマリ」画面で、「拡張」をクリックします。

  12. 「ドメインの作成中」画面で、「完了」をクリックします。

    この構成を有効にするには、管理サーバーを再起動する必要があります。管理サーバーを再起動するには、第4.7項「SOAHOST1での管理サーバーの起動」の手順を使用します。

6.2.3 BPM JMS用のJMS永続ストアの構成

デフォルトの永続ストアの場所を、両ノードから認識できるディレクトリとして構成します。詳細は、第4.1項「Oracle Fusion Middlewareホームのインストール」を参照してください。次のように、この共有ベース・ディレクトリを使用するようにすべての永続ストアを変更する必要があります。

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

  2. 「ドメイン構造」ウィンドウの「サービス」ノードを開いて「永続ストア」ノードをクリックします。

    「永続ストアの概要」ページが表示されます。

  3. 表の「名前」列で、永続ストア「BPMJMSFileStore_auto_1」(これはハイパーリンクとして表示されています)を選択します。

    永続ストア「BPMJMSFileStore_auto_1」の「設定」ページが表示されます。

  4. 「構成」タブの「ディレクトリ」フィールドに、クラスタにある他のサーバーで使用できる永続記憶域ソリューション(NASやSANなど)上の場所を入力します。

    この場所を指定すると、JMSの保留メッセージを送信できます。この場所は、次のディレクトリ構造であることが必要です。

    ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

    注意:

    WLS_SOA1とWLS_SOA2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。

  5. 「保存」をクリックして変更内容を有効にします。

  6. 永続ストア「BPMJMSFileStore_auto_2」でもこの手順を繰り返します。

  7. サーバーを再起動して永続ストアの変更内容を有効にします。

6.2.4 SOAHOST1の管理対象サーバー・ディレクトリ、さらにはSOAHOST2へのドメイン構成の伝播

Oracle BPM Suiteでは、WebLogic Serverの起動スクリプトに多少の更新が必要です。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播するには:

  1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのバックアップ・コピーを作成します。

  2. SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

    SOAHOST1> cd ORACLE_COMMON_HOME/common/bin

SOAHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/admin/
domain_name/aserver/domain_name -template=soadomaintemplateExtBPM.jar
 -template_name=soa_domain_templateExtBPM

  3. SOAHOST1でunpackコマンドを実行して、伝播されたテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

    SOAHOST1> ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name
-overwrite_domain=true -template=soadomaintemplateExtBPM.jar 
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

  4. テンプレートをSOAHOST2にコピーします。

    SOAHOST1> cd ORACLE_COMMON_HOME/common/bin

SOAHOST1> scp soadomaintemplateExtBPM.jar oracle@SOAHOST2:/ORACLE_HOME/common/bin

  5. unpackコマンドをSOAHOST2で実行し、伝播されたテンプレートを解凍します。

    SOAHOST2> cd ORACLE_COMMON_HOME/common/bin

SOAHOST2> ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name/ -overwrite_domain=true
-template=soadomaintemplateExtBPM.jar -app_dir=ORACLE_BASE/admin/
domain_name/mserver/applications

    注意:

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

6.2.5 BPM Suiteコンポーネントの起動

構成変更および起動スクリプトを有効にするには、BPMが追加されたWLS_SOAnサーバーを再起動する必要があります。


注意:

BPMでは既存のSOAシステムが拡張されているので、管理サーバーおよびそれぞれのノード・マネージャはSOAHOST1およびSOAHOST2で稼働しています。

追加されたBPMコンポーネントを起動するには:

  1. WLS_SOA1管理対象サーバーを再起動します。

    1. 次の場所にあるOracle WebLogic Server管理コンソールにログインします。

      http://ADMINVHN:7001/console

    2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。

      「サーバーの概要」ページが表示されます。

    3. 「制御」タブをクリックします。

    4. 表の「サーバー」列から「WLS_SOA1」を選択します。

    5. 「停止」をクリックします。停止が完了するのを待ちます(WebLogic Serverコンソールのページを更新して、ステータスが「停止」になったことを確認します)。

    6. 「起動」をクリックします。

  2. WLS_SOA2に対して手順aからfを繰り返します。

6.2.6 WLS_SOA1およびWLS_SOA2でのBPM Suiteコンポーネントの検証

SOA_Clusterのクラスタ・アドレスは前の章で設定済なので、Oracle HTTP ServerがBPMコンテキストURLをWebLogicサーバーにルーティングするよう構成してからでないと、BPMシステムは検証できません。Oracle HTTP Serverを使用してBPMシステムを検証するには、第6.2.7項「WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成」および第6.2.8項「Oracle HTTP Serverを介したアクセスの検証」の手順に従ってください。

6.2.7 WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成

BPM WebアプリケーションにOracle HTTP Serverからルーティングできるようにするには、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定する必要があります。

  1. ORACLE_BASE/ admin/instance_name/config/OHS/component_name/mod_wl_ohs.confファイルに次の行を追加します。

    # BPM
<Location /bpm/composer >
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2:VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# BPM
<Location /bpm/workspace >
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2:VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

  2. WEBHOST1およびWEBHOST2で、Oracle HTTP Serverを再起動します。

    WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1

WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2

6.2.8 Oracle HTTP Serverを介したアクセスの検証

URLを検証して、HTTP ServerからBPM Suiteコンポーネントへのルーティングとフェイルオーバーが適切に機能することを確認します。URLを検証する手順は次のとおりです。

  1. WLS_SOAが稼動している状態で、Oracle WebLogic Server管理コンソールを使用してWLS_SOA1を停止します。

  2. WebHost1:7777/bpm/composerおよびWebHost1:7777/bpm/workspaceにアクセスして、BPMプロジェクト・コンポーザが正常に機能していることを確認します。

  3. Oracle WebLogic Server管理コンソールでWLS_SOA1を起動します。

  4. Oracle WebLogic Server管理コンソールでWLS_SOA2を停止します。

  5. WebHost1:7777/bpm/composerおよびWebHost1:7777/bpm/workspaceにアクセスして、BPMワークスペースが正常に機能していることを確認します。

これらのURLは、LBRアドレスを使用して確認することもできます。

  • http://soa.mycompany.com:80/bpm/composer

  • http://soa.mycompany.com:80/bpm/workspace

6.2.9 インストールのバックアップ

拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。この時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、このガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法に関する詳細は、このガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、このガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。データベースのバックアップに関する詳細は、Oracle Databaseバックアップおよびリカバリ・ガイドも参照してください。

この時点でインストールをバックアップする手順は次のとおりです。

  1. Web層をバックアップする手順は次のとおりです。

    1. opmnctlを使用してインスタンスを停止します。

      ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

    2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

      tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

    3. 次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。

      tar -cvpf BACKUP_LOCATION/web_instance.tar ORACLE_INSTANCE

    4. opmnctlを使用してインスタンスを起動します。

      ORACLE_BASE/admin/instance_name/bin/opmnctl startall

  2. データベースをバックアップします。これは、Oracle Recovery Manager(推奨)またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。

  3. 管理サーバーのドメイン・ディレクトリをバックアップしてドメイン構成を保存します。構成ファイルは、すべてORACLE_BASE/admin/<domain_name>ディレクトリの下にあります。

    SOAHOST1> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name
  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次		 索引へ移動
索引