| Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1) B55899-07 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1) B55899-07 |
|
前 |
次 |
この章では、Oracle BPMを追加するためのドメイン拡張の手順を説明します。
この章に含まれる項は、次のとおりです。
次の2つの方法で、Fusion MiddlewareインストールにOracle BPMをインストールして構成できます。
(単一の構成ウィザード・セッションで)管理サーバー(および必要に応じてその他の非SOAサーバー)を含む既存のドメインを拡張して、SOAおよびBPMを組み込みます。表10-1は、このアプローチをまとめたものです。構成手順の詳細は、第10.2項「オプション1: SOAおよびBPMを追加するためのドメインの拡張」を参照してください。
SOA(および必要に応じてその他の非SOAサーバー)が含まれているドメインをBPMに拡張します。表10-2は、このアプローチをまとめたものです。構成手順の詳細は、第10.3項「オプション2: Oracle BPMを追加するためのSOAドメインの拡張」を参照してください。
表10-1 SOAおよびBPMを追加するための既存ドメインの拡張手順
| 手順 | 説明 | 詳細 |
|---|---|---|
|
SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化 |
各ホスト名の仮想IPマッピングを有効化します。 |
第10.2.1項「SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化」 |
|
ドメイン拡張のための構成ウィザードの実行 |
SOAホーム・ディレクトリで構成ウィザードを実行して、管理サーバーとOracle Web Services Managerを持つドメインを拡張し、SOAおよびBPMのコンポーネントをサポートするようにします。 |
第10.2.2項「SOAHOST1での構成ウィザードを使用した現在のドメインの拡張」 |
|
コンポジットをデプロイするためのOracle Coherenceの構成 |
コンポジットのデプロイにユニキャスト通信を使用するためOracle Coherenceを構成します。 |
第10.2.4項「コンポジットをデプロイするためのOracle Coherenceの構成」 |
|
B2Bキューでの接続先の識別子の設定 |
JMS宛先メンバー・コールで使用する作成先識別子(CDI)を設定します。 |
|
|
WLS_SOAn管理対象サーバーに対するホスト名検証の無効化 |
Oracle BPMを使用するためのドメイン拡張手順を実行した後、管理サーバーで様々なノードを認証するための適切な証明書を設定します。 |
第10.2.6項「WLS_SOAn管理対象サーバーに対するホスト名検証の無効化」 |
|
管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播 |
起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。 |
第10.2.7項「管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播」 |
|
WLS_SOA1管理対象サーバーの起動と検証 |
Oracle WebLogic Server管理コンソールを使用してWLS_SOA1管理対象サーバーを起動して、検証します。 |
第10.2.8項「WLS_SOA1管理対象サーバーの起動と検証」 |
|
SOAHOST2へのドメイン構成の伝播 |
Unpackユーティリティを使用してSOAHOST2にドメイン構成を伝播します。 |
第10.2.9項「unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播」 |
|
SOAHOST2でのXEngineファイルの抽出 |
SOAHOST2でB2BのXEngineを有効にするには、XEngine tarの内容を手動で抽出します。 |
第10.2.10項「SOAHOST2でのXEngineファイルの抽出」 |
|
WLS_SOA2管理対象サーバーの起動と検証 |
WLS_SOA2管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認します。 |
第10.2.11項「WLS_SOA2管理対象サーバーの起動と検証」 |
|
WLS_SOAn管理対象サーバーに対するOracle HTTP Serverの構成 |
Oracle HTTP ServerでSOA_Clusterへのルーティングを有効化します。 |
第10.2.12項「WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成」 |
|
Oracle HTTP Serverを介したアクセスの検証 |
サーバーのステータスが「実行中」であることを確認します。 |
第10.2.13項「Oracle HTTP Serverを介したアクセスの検証」 |
|
フロントエンドHTTPホストおよびポートの設定 |
Oracle WebLogic Serverクラスタに対してフロントエンドHTTPのホストとポートを設定します。 |
第10.2.14項「フロントエンドHTTPホストおよびポートの設定」 |
|
トランザクション・リカバリのためのデフォルトの永続ストアの構成 |
クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセスできる場所にトランザクション・ログを格納します。 |
第10.2.15項「トランザクション・リカバリ用デフォルト永続ストアの構成」 |
|
OracleファイルとFTPアダプタの高可用性化 |
OracleファイルとFTPアダプタのアウトバウンド操作に対する高可用性を、データベースのmutexロック操作を使用して実現します。 |
第10.2.16項「OracleファイルとFTPアダプタの高可用性化」 |
表10-2 すでにSOAが含まれている既存ドメインの拡張手順
| 手順 | 説明 | 詳細 |
|---|---|---|
|
SOAHOST1での構成ウィザードを使用したBPMを追加するためのSOAドメインの拡張 |
SOAホーム・ディレクトリで構成ウィザードを実行して、管理サーバーとOracle Web Services Managerを持つドメインを拡張し、SOAおよびBPMのコンポーネントをサポートするようにします。 |
第10.3.1項「SOAHOST1での構成ウィザードを使用したBPMを追加するためのSOAドメインの拡張」 |
|
SOAHOST1の管理対象サーバー・ディレクトリ、さらにはSOAHOST2へのドメイン構成の伝播 |
Oracle BPM Suiteでは、WebLogic Serverの起動スクリプトに多少の更新が必要です。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。 |
第10.3.2項「SOAHOST1の管理対象サーバー・ディレクトリ、さらにはSOAHOST2へのドメイン構成の伝播」 |
|
BPM Suiteコンポーネントの起動 |
構成変更および起動スクリプトを有効にするため、BPMが追加されたWLS_SOAnサーバーを再起動します。 |
|
|
WLS_SOAn管理対象サーバーに対するOracle HTTP Serverの構成 |
BPM WebアプリケーションにOracle HTTP Serverからルーティングできるようにするため、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。 |
第10.3.4項「WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成」 |
|
Oracle HTTP Serverを介したアクセスの検証 |
URLを検証して、HTTP ServerからBPM Suiteコンポーネントへのルーティングとフェイルオーバーが適切に機能することを確認します。 |
第10.3.5項「Oracle HTTP Serverを介したアクセスの検証」 |
Oracle BPMを追加するためのドメイン拡張の前提条件
現在のドメインを拡張する前に、既存のデプロイメントが次の前提条件を満たしていることを確認します。
インストールのバックアップ - 既存のFusion Middlewareホームとドメインをバックアップしていない場合は、今すぐバックアップすることをお薦めします。
既存のFusion Middlewareホームおよびドメインをバックアップするには、次のコマンドをSOAHOST1で実行します。
tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw tar -cvpf domainhomeback.tar ORACLE_BASE/admin/domain_name/aserver/domain_name
これらのコマンドにより、Oracle WebLogic ServerとOracle Fusion Middlewareの両方のインストール・ファイルのバックアップ、およびドメイン構成が作成されます。
前の章でインストールしたWL_HOMEおよびORACLE_HOMEが共有記憶域にあります。
この項では、構成ウィザードを使用してドメインを拡張し、SOAおよびBPMのコンポーネントを追加する方法について説明します。さらにそのドメインを拡張してBPMを追加できます。ここでは、SOA ORACLE_HOME(バイナリ)がすでにインストールされ、該当する場合はパッチが適用されて最新のパッチ・セットになっており、SOAHOST1およびSOAHOST2からアクセスできると想定しています。また、管理サーバーを含むドメインが作成されていることも想定しています。これが、SOAコンポーネントをサポートする、この章で拡張されるドメインになります。
|
注意: セットアップのプロセスを開始する前に、リリース・ノートに目を通してインストールとデプロイメントに関する補足の考慮事項を確認しておくことを強くお薦めします。 |
この項で説明する項目は、次のとおりです。
WLS_SOA1サーバーおよびWLS_SOA2を仮想ホスト名(SOAHOST1VHN1およびSOAHOST2VHN1)に関連付けます。これらの仮想ホスト名がDNSまたはシステム内の/etc/hosts解決で有効になっていること、およびそれらが適切な仮想IP(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)です。
SOAホーム・ディレクトリで構成ウィザードを実行して、管理サーバーとOracle Web Services Managerを持つドメインを拡張し、SOAおよびBPMのコンポーネントをサポートするようにします。
Oracle BPMを使用するためのドメイン拡張手順は次のとおりです。
リポジトリをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。
ディレクトリを構成ウィザードの場所に変更します。これはSOAホーム・ディレクトリ内にあります。
cd ORACLE_COMMON_HOME/common/bin
Oracle Fusion Middleware構成ウィザードを開始します。
./config.sh
「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。
WebLogicドメイン・ディレクトリ画面で、WebLogicドメイン・ディレクトリORACLE_BASE/admin/domain_name/aserver/domain_nameを選択し、「次へ」をクリックします。
「拡張ソースの選択」画面で、次の手順を実行します。
「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。次の製品を選択します。
次の製品を選択します。
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
「次へ」をクリックします。
「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。
「SOAインフラストラクチャ」→「ユーザー・メッセージング・サービス」→SOA MDSスキーマを選択します。
「コンポーネント・スキーマのOracle RAC構成」については、「GridLinkへ変換」を選択します。
「次へ」をクリックします。
「GridLink RACコンポーネント・スキーマの構成」画面が表示されます(図10-1)。
この画面で、次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。
ドライバ: OracleのGridLinkConnections用ドライバ (Thin) バージョン: 10以上を選択します。
サービス名: データベースのサービス名を、小文字で入力します。例:
soaedg.mycompany.com
ユーザー名: 対応するコンポーネントのデータベース・スキーマ・オーナーの名前を入力します。(replace table reference)に表示されたユーザー名は、RCUからのスキーマ作成の接頭辞としてsoedgが使用されたことを示しています。
パスワード: データベース・スキーマ・オーナーのパスワードを入力します。
「FANの有効化」を選択します。
「SSLの有効化」が選択解除されていることを確認します(暗号化するONS通知にsslが選択されている場合は、適切なウォレットとウォレット・パスワードを指定します)。
サービス・リスナー: 使用するRACデータベースのためのSCANアドレスとポートを入力します。このアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せれば識別できます。
SQL>show parameter remote_listener; NAME TYPE VALUE ------------------------------------------------------------- remote_listener string db-scan.mycompany.com:1521
|
注意: Oracle Database 11g リリース1 (11.1) では、次の例のように、各データベースのインスタンス・リスナーの仮想IPとポートを使用します。 custdbhost1-vip.mycompany.com (port 1521) および custdbhost2-vip.mycompany.com (1521) Oracle Database 10gでは、Oracle RACデータベースへの接続にマルチ・データ・ソースを使用します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。 |
ONSホスト: Oracle RACデータベースのSCANアドレスおよびデータベースから報告されたONSリモート・ポートを入力します。
[orcl@db-scan1 ~]$ srvctl config nodeapps -s ONS exists: Local port 6100, remote port 6200, EM port 2016
|
注意: Oracle Database 11g リリース1 (11.1)では、次の例のように、各データベースのONSサービスのホスト名とポートを使用します。 custdbhost1.mycompany.com (port 6200) および custdbhost2.mycompany.com (6200) |
「JDBCデータ・ソースのテスト」画面で、各接続のテストが自動的に行われます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続に成功したら「次へ」をクリックします。
オプションの構成の画面で、次の項目を選択します。
JMS分散宛先
管理対象サーバー、クラスタ、およびマシン
デプロイメントとサービス
「次へ」をクリックします。
「JMS分散宛先タイプの選択」画面で、すべてのFusion MiddlewareコンポーネントのJMSモジュールのドロップダウン・リストから「UDD」を選択します。
|
注意: Fusion MiddlewareコンポーネントでのWDDの使用はサポートされません。 |
「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。
soa_server1というサーバーが自動的に作成されます。このサーバーの名前をWLS_SOA1に変更し、WLS_SOA2という新しいサーバーを追加します。表10-3に示す属性をこれらのサーバーに指定します。この画面に表示されている他のサーバーは、このまま変更しません。
表10-3 管理対象サーバー
| 名前 | リスニング・アドレス | リスニング・ポート | SSLリスニング・ポート | SSL有効 |
|---|---|---|---|---|
|
WLS_SOA1 |
SOAHOST1VHN1 |
8001 |
なし |
いいえ |
|
WLS_SOA2 |
SOAHOST2VHN1 |
8001 |
なし |
いいえ |
「次へ」をクリックします。
「クラスタの構成」画面で、表10-4に示すクラスタを追加します。この画面に表示されている他のクラスタは、このまま変更しません。
表10-4 クラスタ
| 名前 | クラスタ・メッセージング・モード | マルチキャスト・アドレス | マルチキャスト・ポート | クラスタ・アドレス |
|---|---|---|---|---|
|
SOA_Cluster |
ユニキャスト |
なし |
なし |
SOAHOST1VHN1:8001、SOAHOST2VHN1:8001 |
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。
SOA_Cluster:
WLS_SOA1
WLS_SOA2
「次へ」をクリックします。
「マシンの構成」画面で、次の手順を実行します。
「削除」をクリックして、デフォルトの「LocalMachine」を削除します。
「Unixマシン」タブをクリックします。SOAHOST1マシンとSOAHOST2マシンには、次のエントリが表示されます(表10-5)。
他のフィールドはすべてデフォルト値のままにします。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、次の表に従ってサーバーをマシンに割り当てます。
表10-6 マシンへのサーバーの割当て
| サーバー | マシン |
|---|---|
|
AdminServer |
ADMINHOST |
|
WLS_SOA1 |
SOAHOST1 |
|
WLS_SOA2 |
SOAHOST2 |
|
WLS_WSM1 |
SOAHOST1 |
|
WLS_WSM2 |
SOAHOST2 |
「次へ」をクリックします。
「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。
WSM-PMはWSM-PM_Clusterにのみターゲット設定します。
oracle.sdp.*、oracle.BPM.*およびoracle.soa.*の各デプロイメントは、SOA_Clusterにのみターゲット設定します。
oracle.rules.*ライブラリは、管理サーバーおよびSOA_Clusterにのみターゲット設定する必要があります。
「次へ」をクリックします。
「サービスのクラスタまたはサーバーへのターゲット設定」画面で、mds-owsm、mdw-owsm-rac0およびmds-owsm-rac1データソースを、WSM-PM_ClusterとAdminServerにターゲット設定し、「次へ」をクリックします。
「JMSファイル・ストアの構成」画面で、第4.3項「異なるディレクトリの推奨場所」でお薦めしているように、JMSストアに指定した共有ディレクトリの場所を入力します。例:
ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
すべてのストアに対してDirect-writeポリシーを選択します。
「次へ」をクリックします。
「構成のサマリ」画面で、「拡張」をクリックします。
「ドメインの作成中」画面で、「完了」をクリックします。
この構成を有効にするには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用して、管理サーバーを再起動する必要があります。
サーバーが開始したら、GridLinkデーター・ソースが正しく構成され、ONS設定が正しいことを確認します。作成されたすべてのGridLinkデータ・ソースに対して、この手順を実行します。
GridLinkデータ・ソースの構成を検証する手順は次のとおりです。
Oracle WebLogic管理コンソールにログインします。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。
新しいデータ・ソースの内の1つをクリックします。
「監視」タブをクリックし、いずれかのサーバーを選択します。
「統計」タブをクリックし、いずれかのサーバーを選択します。
「ONS」タブをクリックし、「テスト」タブをクリックします。
サーバーを選択して、「ONSのテスト」をクリックします。
テストが両方とも成功すれば、正しく構成されています。ONSのテストが失敗した場合は、RACデータベース・ノードでONSサービスが実行されていることを確認します。
orcl@db-scan1 ~]$ srvctl status scan_listener SCAN Listener LISTENER_SCAN1 is enabled SCAN listener LISTENER_SCAN1 is running on node db-scan1 SCAN Listener LISTENER_SCAN2 is enabled SCAN listener LISTENER_SCAN2 is running on node db-scan2 SCAN Listener LISTENER_SCAN3 is enabled SCAN listener LISTENER_SCAN3 is running on node db-scan2 [orcl@db-scan1 ~]$ srvctl config nodeapps -s ONS exists: Local port 6100, remote port 6200, EM port 2016 [orcl@db-scan1 ~]$ srvctl status nodeapps | grep ONS ONS is enabled ONS daemon is running on node: db-scan1 ONS daemon is running on node: db-scan2
データ・ソースを使用するすべてのWebLogicサーバーからONSテストを実行します。
コンポジットのデプロイではマルチキャスト通信がデフォルトで使用されますが、SOAエンタープライズ・デプロイメントではユニキャスト通信の使用をお薦めします。セキュリティ上の理由からマルチキャスト通信を無効にしている場合は、ユニキャストを使用します。
ユニキャスト通信を使用した場合、この方法ではノードから他のクラスタ・メンバーを検出できません。したがって、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加した新しいノードから既存ノードのいずれかを検出するために必要な数のノードを指定するだけでかまいません。この結果、クラスタに追加した新しいノードからクラスタにある他のすべてのノードを検出できます。また、同じシステムで複数のIPを使用できるSOAエンタープライズ・デプロイメントなどの構成では、特定のホスト名を使用してOracle Coherenceクラスタを作成するようにOracle Coherenceを構成する必要があります。
|
注意: デプロイメントに使用するOracle Coherenceフレームワークの構成が正しくないと、SOAシステムを起動できないことがあります。SOAシステムを実行するネットワーク環境に応じて、デプロイメント・フレームワークを適切にカスタマイズする必要があります。この項で説明する構成をお薦めします。 |
tangosol.coherence.wka<n>システム・プロパティを使用してノードを指定します。<n>は、1から9の数字です。指定できるノードは最大9個です。番号は1から開始します。この番号付けは、連続的で間隙を含まないようにする必要があります。また、Oracle Coherenceでクラスタを作成するために使用するホスト名をtangosol.coherence.localhostシステム・プロパティで指定します。このローカル・ホスト名には、SOAサーバーでリスナーのアドレスとして使用する仮想ホスト名を指定する必要があります(SOAHOST1VHN1とSOAHOST2VHN1)。このプロパティを設定するには、Oracle WebLogic Server管理コンソールの「サーバーの起動」タブにある「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加します(図10-2)。
図10-2 Oracle WebLogic Server管理コンソールの「サーバーの起動」タブを使用したホスト名の設定
管理コンソールを使用して、Oracle Coherenceで使用するホスト名を指定します。
Oracle Coherenceで使用するホスト名を追加する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーの概要」ページが表示されます。
表の「名前」列にハイパーリンクで表示されているサーバーの名前(WLS_SOA1またはWLS_SOA2)をクリックします。選択したサーバーの「設定」ページが表示されます。
「ロックして編集」をクリックします。
「サーバーの起動」タブをクリックします(図10-2を参照)。
WLS_SOA1とWLS_SOA2について、「引数」フィールドに次の値を入力します。
|
注意: 異なる |
|
注意: デプロイメントで使用されるCoherenceクラスタでは、ポート8088をデフォルトで使用します。このポートは、起動パラメータ-Dtangosol.coherence.wkan.portおよび-Dtangosol.coherence.localportで別なポート(8089など)を指定することで変更できます。例: WLS_SOA1(「引数」フィールドに、改行なしで1行で次のように入力): -Dtangosol.coherence.wka1=SOAHOST1VHN1 -Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST1VHN1 -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 WLS_SOA2(「引数」フィールドに、改行なしで1行で次のように入力): -Dtangosol.coherence.wka1=SOAHOST1VHN1 -Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST1VHN1 -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 Coherenceクラスタの詳細は、『Oracle Coherence開発者ガイド』を参照してください。 |
WLS_SOA1については次の値を入力します。
-Dtangosol.coherence.wka1=SOAHOST1VHN1 -Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST1VHN1
WLS_SOA2については次の値を入力します。
-Dtangosol.coherence.wka1=SOAHOST1VHN1 -Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST2VHN1
「保存」→「変更のアクティブ化」をクリックします。
|
注意: これらの変数が管理対象サーバーに正しく渡されることを確認する必要があります(これらの変数はサーバーの出力ログに記録されます)。Oracle Coherenceフレームワークに問題があると、soa-infraアプリケーションを起動できないことがあります。 |
|
注意: このマルチキャスト・アドレスとユニキャスト・アドレスは、WebLogic Serverクラスタでクラスタ通信に使用するものとは異なります。SOAでは、2つのエンティティ(WebLogic Serverクラスタおよびコンポジットのデプロイ先グループ)の通信プロトコルが異なる場合でも、単一のWebLogic Serverクラスタの各メンバーにコンポジットを確実にデプロイできます。 |
Oracle B2Bでは、特定のJMS宛先メンバー・コールを使用します。これらのコールを成功させるには、作成先識別子(CDI)を設定する必要があります。CDIを設定する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで「サービス」ノードを開き、「メッセージング」ノードを開きます。
「JMSモジュール」→「SOAJMSModule」をクリックします。
「ロックして編集」をクリックします。
「dist_B2BEventQueue_auto」→「構成」→「一般」タブをクリックし、「詳細」をクリックします。
「作成先識別子」フィールドで、キューに次のJNDI名を追加します。
jms/b2b/B2BEventQueue
この手順を繰り返して、次に一覧表示するキューに対して、次の作成先識別子を作成します。
B2B_OUT_QUEUE: jms/b2b/B2B_IN_QUEUE
B2B_IN_QUEUE: jms/b2b/B2B_OUT_QUEUE
B2BBroadcastTopic: jms/b2b/B2BBroadcastTopic
XmlSchemaChangeNotificationTopic: jms/fabric/XmlSchemaChangeNotificationTopic
保存およびアクティブな変更をクリックします。
このガイドで説明するエンタープライズ・デプロイメントでは、Oracle BPMを使用するためのドメイン拡張手順を実行した後に、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。そのため、WLS_SOAn管理対象サーバーのホスト名検証を無効化して、様々なWebLogic Serverを管理するときにエラーが出ないようにします。エンタープライズ・デプロイメントのトポロジ構成が完了したときに、ホスト名検証を再び有効化します。詳細は、第13.3項「SOAHOST1でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。
ホスト名検証を無効化するには:
Oracle WebLogic Server管理コンソールにログインします。
「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。
表の「名前」列で「WLS_SOA1」(これはハイパーリンクとして表示されています)を選択します。
「設定」ページが表示されます。
「SSL」タブを選択します。
このページの「詳細」セクションを展開します。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
WLS_SOA2サーバーについてステップ4から8を繰り返します。
変更を保存してアクティブ化します。
この変更内容を有効にするには、管理サーバーおよびノード・マネージャを再起動する必要があります。
管理サーバーを再起動する手順は、第8.4.3項「SOAHOST1での管理サーバーの起動」を参照してください。
SOAHOST1でノード・マネージャを再起動するには、第9.5.2項「SOAHOST1でのノード・マネージャの再起動」を参照してください。
SOAHOST2でノード・マネージャの処理を繰り返します。
起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。
起動スクリプトとクラスパス構成を伝播する手順は次のとおりです。
管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのコピーを作成します。
SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ORACLE_BASE/admin/ domain_name/aserver/domain_name -template=soadomaintemplateExtSOABPM.jar -template_name=soa_domain_templateExtSOABPM
SOAHOST1でunpackコマンドを実行して、伝播されたテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。
./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コマンドで |
|
注意: このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。 |
Oracle WebLogic Server管理コンソールを使用してWLS_SOA1管理対象サーバーを起動して、検証します。
WLS_SOA1管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認するには:
次の手順に従い、Oracle WebLogic Server管理コンソールを使用してWLS_SOA1管理対象サーバーを起動します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」を選択します。
「サーバーのサマリー」画面が表示されます。
「制御」タブをクリックします。
「WLS_SOA1」を選択して、「起動」をクリックします。
サーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16章の「エンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。
次の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/にアクセスしてワークスペース・アプリケーションにログインします。
SOAHOST2にドメイン構成を伝播させるには:
次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・ファイルをSOAHOST2にコピーします。
cd ORACLE_COMMON_HOME/common/bin scp soadomaintemplateExtSOABPM.jar oracle@node2:ORACLE_COMMON_HOME/common/bin
unpackコマンドをSOAHOST2で実行し、伝播されたテンプレートを解凍します。
cd ORACLE_COMMON_HOME/common/bin ./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コマンドで |
|
注意: このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。 |
SOAHOST2でB2BのXEngineを有効にするには、次のようにXEngine tarの内容を手動で抽出する必要があります。
cd ORACLE_HOME/soa/thirdparty/edifecs
tar -xzvf XEngine.tar.gz
WLS_SOA2管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認するには:
次の手順に従い、Oracle WebLogic Server管理コンソールを使用してWLS_SOA2管理対象サーバーを起動します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」を選択します。
「サーバーのサマリー」画面が表示されます。
「制御」タブをクリックします。
「WLS_SOA2」を選択して、「起動」をクリックします。
サーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16章の「エンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。
次の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/にアクセスしてワークスペース・アプリケーションにログインします。
WLS_SOAn管理対象サーバーが属するSOA_ClusterにOracle HTTP Serverからルーティングできるようにするには、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。
Oracle HTTP ServerでSOA_Clusterへのルーティングを有効化する手順は次のとおりです。
WEBHOST1およびWEBHOST2上で、次のディレクトリにあるsoa.vh.confファイルにディレクティブを追加します。
ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf
第7.6項「仮想ホストの定義」の指示に従って、soa_vh.confファイルを作成している必要があります。
<VirtualHost>タグ内に、次のディレクティブを追加します。
# 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>
soa_vh.confファイルは、例10-1のように表示されます。
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
例10-1 soa_vh.confファイル
<VirtualHost *:7777>
ServerName https://soa.mycompany.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
<Location /soa-infra>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# SOA inspection.wsil
<Location /inspection.wsil>
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>
</VirtualHost>
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サーバー・プラグインの使用』ガイドを参照してください。
サーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.13項「エンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。
次の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は、ロード・バランサ・アドレスを使用して確認することもできます。
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
ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。
Oracle WebLogic Serverクラスタについて、フロントエンドHTTPのホストとポートを設定する必要があります。
WebLogic Server管理コンソールの「チェンジ・センター」セクションの「ロックして編集」をクリックします。
左ペインの「ドメイン構造」ウィンドウで「環境」を選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。
SOA_Clusterクラスタを選択します。
「HTTP」を選択します。
次の値を設定します。
フロントエンド・ホスト: soa.mycompany.com
フロントエンドHTTPSポート: 443
フロントエンドHTTPポート: 80
フロントエンドHTTPのホストとポートを設定していない場合は、Oracle B2Bからドキュメント定義のXSDを取得しようとすると次のメッセージが表示されます。
An error occured while loading the document definitions. java.lang.IllegalArgumentException: Cluster address must be set when clustering is enabled.
「保存」をクリックします。
変更を有効にするために、管理コンソールの「チェンジ・センター」セクションの「変更のアクティブ化」をクリックします。
サーバーを再起動して、クラスタのフロントエンド・ホストの指定を有効化します。
|
注意: ロード・バランサでHTTPSが有効になっており、SSLがロード・バランサで終了する場合(SOAサーバーはHTTPSではなくHTTPリクエストのみを受信します)、ここに示しているように、Webサービスのエンドポイント・プロトコルは (javax.xml.soap.SOAPException: oracle.j2ee.ws.saaj.ContentTypeException) この例外を解決するには、URLエンドポイントを更新します。 Enterprise Managerの「テスト」ページで、エンドポイントURLの編集を確認します。 「エンドポイントURL」ページで、次の操作を実行します。
|
|
注意: フロントエンドHTTPのホストとポートを設定していない場合は、Oracle B2Bからドキュメント定義のXSDを取得しようとすると次のメッセージが表示されます。 An error occured while loading the document definitions. java.lang.IllegalArgumentException: Cluster address must be set when clustering is enabled. |
SOAシステムでは、次のようにコールバックURLを計算します。
SOAへのリクエストが外部または内部のサービスから発行された場合、SOAはクライアントで指定されたコールバックURLを使用します。
外部または内部の非同期サービスへのリクエストがSOAから発行された場合は、次の方法でコールバックURLが決定されます。ここでは決定方法の優先度が高い順に示しています。
特定の参照用のバインド・プロパティとして指定されたcallbackServerURLを使用します(このプロパティは、コンポジットのモデリング時または実行時にMBeansを使用して設定できます)。これにより、サービス呼び出しごとに異なるコールバックURLを割り当てることができます。つまり、外部サービスからのコールバックURLには、内部サービスへのコールバックURLとは異なる値を設定できます。エンタープライズ・デプロイメント・アーキテクチャでの一般的なコールバックURLは、外部サービスについてはsoa.mycompany.com(443/https)、内部サービスについてはsoainternal.mycompany.com(7777/http)です。このプロパティは、システムMBeanブラウザに対応するバインドmbeanを通じ、実行時にシステムMBeanブラウザを使用して設定します。特定のURLを追加するには、そのProperties属性にcallbackServerURLプロパティを追加してから保存操作を実行します。
soa-infra-config.xmlで指定したコールバックURLを使用します。この場合、指定できるアドレスは1つのみです。外部サービスと内部サービスの両方を組み合せて呼び出し可能な場合は、エンタープライズ・デプロイメント・アーキテクチャでこのアドレスをsoa.mycompany.com(443/https)に設定する必要があります。内部サービスのみを呼び出す場合は、このアドレスをsoainternal.mycompany.com(7777/http)に設定します。
SOA_ClusterのWLSで指定するフロントエンド・ホストとして、このコールバックURLを使用します。この場合も指定できるアドレスは1つのみなので、soa-infra-config.xmlの場合と同じ処理をお薦めします。
WLS MBean APIで指定されたローカル・ホスト名を使用します。エンタープライズ・デプロイメントのような高可用性環境では、この方法はお薦めできません。
各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。WebLogic Serverでは、システム・クラッシュやネットワーク障害からのリカバリ時にこのトランザクション・ログを使用します。クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセスできる場所にトランザクション・ログを格納します。
|
注意: お薦めする場所は、デュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)です。 |
デフォルトの永続ストアの場所を設定する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」ノードをクリックします。「サーバーの概要」ページが表示されます。
表の「名前」列にあるサーバーの名前(ハイパーリンクとして表示されています)をクリックします。選択したサーバーの「設定」ページが表示され、デフォルトで「構成」タブが選択状態になります。
「サービス」タブをクリックします。
ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。パスのディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs
「保存」をクリックします。
|
注意: トランザクション・リカバリ・サービスの移行を有効にするには、クラスタにある他のサーバーが使用できる永続記憶域ソリューションの場所を指定します。WLS_SOA1とWLS_SOA2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。 |
OracleファイルとFTPアダプタを使用すると、BPELプロセスやOracle MediatorでFTP(ファイル転送プロトコル)を使用して、ローカルとリモートのファイル・システムにあるファイルの読取りと書込みができます。これらのアダプタは、インバウンドとアウトバウンドの両方の操作に対し、Oracle BPEL Process ManagerとOracle Mediatorサービス・エンジンを使用してアクティブ/アクティブ・トポロジの高可用性をサポートします。Oracle File AdapterとOracle FTP Adapterがアウトバウンド操作に対する高可用性を備えるようにするには、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のアウトバウンド操作での高可用性に関する項で説明されているデータベースのmutexロック操作を使用します。データベースのmutexロック操作を使用すると、複数の参照から同じディレクトリへの書込みが発生しても、これらのアダプタでは相互の上書きを防止できます。
|
注意: この項で説明する操作は、これらのアダプタがアプリケーションで必要になる場合にのみ実行する必要があります。 |
|
注意: ファイル・アダプタは、インバウンド・ディレクトリからファイルを取得して処理し、出力ディレクトリにファイルを出力します。ファイル・アダプタでの処理はトランザクション方式ではないので、ファイルは2回処理できます。この結果として、Oracle RACバックエンドまたはSOA管理対象サーバーでフェイルオーバーが発生したときに、重複するファイルが得られる可能性があります。 |
データベース表をコーディネータとして使用することで、アウトバウンドのOracleファイルやFTPアダプタのサービスに高可用性を実現します。そのためには次の手順を実行します。
|
注意: FTPアダプタの手順および構成オプションは、フィルタ・アダプタのオプションと完全に同じです。FTP HAの構成に使用する接続ファクトリは、FTPアダプタ・デプロイメントの送信接続プールの下に表示される |
|
注意: データベースをコーディネータとして使用する場合は、グローバル・トランザクション・タイムアウトの値を大きくする必要があります。 |
データベース表の作成
データベース・スキーマはsoainfraの一部として事前に作成済なので、この手順を実行する必要はありません。
Oracleファイル・アダプタのデプロイメント・ディスクリプタの変更
eis/HAFileAdapterに対応する接続インスタンスについて、Oracle WebLogic ServerコンソールからOracleファイル・アダプタのデプロイメント・ディスクリプタを変更します。
Oracle WebLogic Serverコンソールにログインします。このコンソールにアクセスするには、http://servername:portnumber/consoleにアクセスします。
「ドメイン構造」の左ペインで「デプロイメント」をクリックします。
右ペインの「デプロイメントの概要」で「FileAdapter」をクリックします。
「構成」タブをクリックします。
「アウトバウンド接続プール」タブをクリックして「javax.resource.cci.ConnectionFactory」を開き、構成済の接続ファクトリを表示します。
「eis/HAFileAdapter」をクリックします。高可用性に対応する接続ファクトリの「アウトバウンド接続のプロパティ」が表示されます。
図10-3に示すように、接続ファクトリのプロパティが表示されます。
図10-3 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の完全修飾クラス名を指定します。
これらのプロパティを更新した後、「保存」をクリックします。「デプロイメント・プランの保存」ページが表示されます。
デプロイメント・プランの共有記憶域場所を入力します。そのディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/cluster_name/dd/Plan.xml
「保存してアクティブ化」をクリックします。
次の例のように、接続ファクトリが使用されるように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属性は、接続ファクトリの |
ロックのスキップ機能の導入により、これまでの最善の方法であった、各ポーリング・ノードでLogicalDeletePollingStrategyまたはDeletePollingStrategyと一意のMarkReservedValueを使用し、MaxTransactionSizeを設定する方法は使用できなくなりました。以前にこのアプローチを使用していた場合は、MarkReservedValueを(db.jcaで)削除するか、または(ウィザードの「論理削除」ページで)消去するだけです。それによってロックが自動的にスキップされるようになります。
予約された値に対してロックのスキップを使用することには、次のような利点があります。
ロックをスキップすると、クラスタにおいて、また負荷がかかっている状態で、スケーリングが向上します。
(更新/予約→コミットを行ってから新しいトランザクションで選択するのとは反対に)すべての作業が1つのトランザクションで行われるため、高可用性環境でリカバリ不能な状況に直面するリスクが最小に抑えられます。
一意のMarkReservedValueを指定する必要がありません。以前は、そのようにするためには、R${weblogic.Name-2}-${IP-2}-${instance}のように、複雑な変数を構成することが必要でした。
論理削除ポーリングを使用していて、MarkReservedValueを設定している場合は、ロックのスキップは使用されません。
以前は、複数のOracle BPEL Process ManagerノードまたはOracle Mediatorノードにデプロイする複数のOracleデータベース・アダプタ・プロセス・インスタンスにおける最善の手法は、基本的に、ポーリング・ノードごとに一意のMarkReservedValueを設定し、さらにMaxTransactionSizeを設定して、LogicalDeletePollingStrategyまたはDeletePollingStrategyを使用することでした。
詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のスケーラビリティとポーリング計画に関する項を参照してください。
この手順では、第9章「SOAコンポーネントを使用するためのドメインの拡張」で作成したドメインを、Oracle BPMを扱うことができるように拡張します。
Oracle BPMを追加するためのSOAドメイン拡張の前提条件
現在のドメインを拡張する前に、既存のデプロイメントが次の前提条件を満たしていることを確認します。
インストールのバックアップ - 既存のFusion Middlewareホームとドメインをバックアップしていない場合は、今すぐバックアップすることをお薦めします。
既存のFusion Middlewareホームおよびドメインをバックアップする手順は次のとおりです。
tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw tar -cvpf domainhomeback.tar ORACLE_BASE/admin/domain_name/aserver/domain_name
これらのコマンドにより、Oracle WebLogic ServerとOracle Fusion Middlewareの両方のインストール・ファイルのバックアップ、およびドメイン構成が作成されます。
前の章でインストールしたWL_HOMEおよびSOA ORACLE_HOME (バイナリ)が共有記憶域にあり、SOAHOST1およびSOAHOST2からアクセスできること(WebLogic構成ウィザードの手順を実行してドメインを拡張する前にこのようになっている必要があります)。
ノード・マネージャ、管理サーバー、SOAサーバーおよびWSMサーバーが存在し、前の章の説明のように、SOAシステムを実行するように構成されていること。サーバー移行、トランザクション・ログ、Coherenceなど、SOAシステムのすべての構成手順はすでに実行されているので、BPMで使用されます。BPMは、既存の構成のスーパーセットとして追加されます。
この項で説明する項目は、次のとおりです。
SOAホーム・ディレクトリで構成ウィザードを実行して、管理サーバーとOracle Web Services Managerを持つドメインを拡張し、SOAおよびBPMのコンポーネントをサポートするようにします。
ディレクトリを構成ウィザードの場所に変更します。これはSOAホーム・ディレクトリ内にあります。ドメインの拡張は、管理サーバーが存在するノードから実行します。
cd ORACLE_COMMON_HOME/common/bin
Oracle Fusion Middleware構成ウィザードを開始します。
./config.sh
「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。
WebLogicドメイン・ディレクトリ画面で、WebLogicドメイン・ディレクトリORACLE_BASE/admin/domain_name/aserver/domain_nameを選択し、「次へ」をクリックします。
「拡張ソースの選択」画面で、次の手順を実行します。
「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。次の製品を選択します。
次の製品を選択します。
Oracle BPM Suite - 11.1.1.0 [soa]
「JDBCコンポーネント・スキーマの構成」画面に入力されている値(既存のSOAシステムで作成されたスキーマ)を受け入れて、「次へ」をクリックします。
Oracle BPMでは、既存のsoa-infraシステムと同じデータ・ソースが使用されます。
オプションの構成の画面で、次の項目を選択します。
JMS分散宛先
デプロイメントとサービス
「次へ」をクリックします。
「JMS分散宛先タイプの選択」画面で、BPMJMSModuleのドロップダウン・リストから「UDD」を選択します。既存のモジュールはそのままにします。
「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。
WSM-PMはWSM-PM_Clusterにのみターゲット設定します。
usermessagingserverおよびusermessagingdriver-emailは、SOA_Clusterにのみターゲット設定します。(usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです)。
oracle.sdp.*、oracle.BPM.*およびoracle.soa.*ライブラリは、SOA_Clusterにのみターゲット設定します。
oracle.rules.*ライブラリは、SOA_Clusterおよび管理サーバーにターゲット設定します。
「次へ」をクリックします。
「サービスのクラスタまたはサーバーへのターゲット設定」画面で、mds-owsmデータソースをWSM-PM_ClusterおよびAdminServerにターゲット設定し、「次へ」をクリックします。
「JMSファイル・ストアの構成」画面で、第4.3項「異なるディレクトリの推奨場所」でお薦めしているように、JMSストアに指定した共有ディレクトリの場所を入力します。例:
ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
すべてのストアに対してDirect-writeポリシーを選択します。
「次へ」をクリックします。
「構成のサマリ」画面で、「拡張」をクリックします。
「ドメインの作成中」画面で、「完了」をクリックします。
この構成を有効にするには、管理サーバーを再起動する必要があります。管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。
Oracle BPM Suiteでは、WebLogic Serverの起動スクリプトに多少の更新が必要です。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。
起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播するには:
管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのバックアップ・コピーを作成します。
SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ORACLE_BASE/admin/ domain_name/aserver/domain_name -template=soadomaintemplateExtSOABPM.jar -template_name=soa_domain_templateExtSOABPM
SOAHOST1でunpackコマンドを実行して、伝播されたテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。
./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コマンドで |
テンプレートをSOAHOST2にコピーします。
cd ORACLE_COMMON_HOME/common/bin scp soadomaintemplateExtBPM.jar oracle@SOAHOST2:/ORACLE_HOME/common/bin
unpackコマンドをSOAHOST2で実行し、伝播されたテンプレートを解凍します。
cd ORACLE_COMMON_HOME/common/bin ./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
|
注意: このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。 |
構成変更および起動スクリプトを有効にするには、BPMが追加されたWLS_SOAnサーバーを再起動する必要があります。BPMでは既存のSOAシステムが拡張されているので、管理サーバーおよびそれぞれのノード・マネージャはSOAHOST1およびSOAHOST2で稼働しています。
追加されたBPMコンポーネントを起動するには:
WLS_SOA1管理対象サーバーを再起動します。
次の場所にあるOracle WebLogic Server管理コンソールにログインします。
http://ADMINVHN:7001/console
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。
「サーバーの概要」ページが表示されます。
「制御」タブをクリックします。
表の「サーバー」列から「WLS_SOA1」を選択します。
「停止」をクリックします。停止が完了するのを待ちます(WebLogic Serverコンソールのページを更新して、ステータスが「停止」になったことを確認します)。
「起動」をクリックします。
WLS_SOA2に対して手順aからfを繰り返します。
WLS_SOAn管理対象サーバーが属するSOA_ClusterにOracle HTTP Serverからルーティングできるようにするには、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。
Oracle HTTP ServerでSOA_Clusterへのルーティングを有効化する手順は次のとおりです。
WEBHOST1およびWEBHOST2上で、次のディレクトリにあるsoa.vh.confファイルにディレクティブを追加します。
ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf
<VirtualHost>タグ内に、次のディレクティブを追加します。
# 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>
soa_vh.confファイルは、例10-1のように表示されます。
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
SOA_Clusterのクラスタ・アドレスは前の章で設定済なので、Oracle HTTP ServerがBPMコンテキストURLをWebLogicサーバーにルーティングするよう構成してからでないと、BPMシステムは検証できません。URLを検証して、HTTP ServerからBPM Suiteコンポーネントへのルーティングとフェイルオーバーが適切に機能することを確認します。
ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。
URLを検証する手順は次のとおりです。
WLS_SOAが稼動している状態で、Oracle WebLogic Server管理コンソールを使用してWLS_SOA1を停止します。
WebHost1:7777/BPM/composerおよびWebHost1:7777/BPM/workspaceにアクセスして、BPMプロジェクト・コンポーザが正常に機能していることを確認します。
Oracle WebLogic Server管理コンソールでWLS_SOA1を起動します。
Oracle WebLogic Server管理コンソールでWLS_SOA2を停止します。
WebHost1:7777/BPM/composerおよびWebHost1:7777/BPM/workspaceにアクセスして、BPMワークスペースが正常に機能していることを確認します。
これらのURLは、ロード・バランサ・アドレスを使用して確認することもできます。
http://soa.mycompany.com:80/BPM/composer
http://soa.mycompany.com:80/BPM/workspace
拡張したドメインが正常に動作していることを確認した後、そのドメイン構成をバックアップします。このバックアップは、この後の手順でエラーが発生した場合にすぐにリストアできるようにすることが目的です。構成をローカル・ディスクにバックアップします。エンタープライズ・デプロイメントが完了すれば、このバックアップは破棄してかまいません。エンタープライズ・デプロイメントが完了すれば、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。
環境のバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。情報のリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。
ドメイン構成をバックアップする手順は次のとおりです。
Web層をバックアップする手順は次のとおりです。
opmnctlを使用してインスタンスを停止します。
ORACLE_BASE/admin/instance_name/bin/opmnctl stopall
次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。
tar -cvpf BACKUP_LOCATION/web.tar MW_HOME
次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。
tar -cvpf BACKUP_LOCATION/web_instance.tar ORACLE_INSTANCE
opmnctlを使用してインスタンスを起動します。
ORACLE_BASE/admin/instance_name/bin/opmnctl startall
データベースをバックアップします。これは、Oracle Recovery Manager(推奨)またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。
管理サーバーのドメイン・ディレクトリをバックアップしてドメイン構成を保存します。構成ファイルは次のディレクトリにあります。
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をバックアップする手順は次のとおりです。
tar -cvpf fmwhomeback.tar MW_HOME
|
