Oracle® Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B55900-03 |
|
![]() 前 |
![]() 次 |
この章では、構成ウィザードを使用して、SOAコンポーネントを扱うことができるようにドメインを拡張する方法を説明します。このドメインは、第4章「ドメインの作成」で作成したものです。
重要: セットアップのプロセスを開始する前に、リリース・ノートに目を通してインストールとデプロイメントに関する補足の考慮事項を確認しておくことを強くお薦めします。 |
注意: SOAHOST1とSOAHOST2でSOAコンポーネントを実行する場合にのみ、この章の手順に従ってください。WebCenterトポロジでSOAコンポーネントを実行しない場合は、この章の手順を省略してかまいません。 |
この章の項目は次のとおりです。
Oracle Fusion Middleware for SOAは、SOAHOST1とSOAHOST2の両方にインストールする必要があります。これらのノードでは、SOAコンポーネントを使用して構成された管理対象サーバーが実行されます。
Oracle Fusion Middleware for SOAのインストーラを起動します。
SOAHOST1> runInstaller
インストーラからJRE/JDKの場所を指定することを要求された場合は、Oracle WebLogic Serverのインストール時に作成したOracle SDKの場所を入力します。たとえば、MW_HOME/jrockit_160_<version>とします。
「ようこそ」画面で、「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認して、「次へ」をクリックします。
インストール先を指定します。すでにインストールされているミドルウェア・ホームをドロップダウン・リストから選択します。Oracleホーム・ディレクトリとして、ディレクトリ名soaを入力します。
「次へ」をクリックします。
「インストールの概要」画面で「インストール」をクリックします。
「インストール 完了」画面で「終了」をクリックします。
SOAドメインでは、SOA管理対象サーバー用リスニング・アドレスに仮想ホスト名を使用します。2つのSOAマシン上にこれらのホスト名をそれぞれマップするVIP(SOAHOST1上のVIP2およびSOAHOST2上のVIP3)を有効化し、トポロジが使用するネットワーク・システムの仮想ホスト名を(DNSサーバーまたはホスト解決によって)正しく解決する必要があります。
VIPを有効にするには、第4.3項「SOAHOST1でのVIP1の有効化」で説明している手順に従ってください。これらのVIPおよびVHNは、SOAサーバーでサーバー移行を有効にするときに必要となります。SOAシステムで高可用性を実現するために、サーバー移行を構成する必要があります。SOAサーバーのサーバー移行の構成の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の第9章「サーバー移行」を参照してください。
この手順では、第4章「ドメインの作成」で作成したドメインを、SOAコンポーネントを扱うことができるように拡張します。この項では、SOAデプロイメントにおいて、WebCenterデプロイメントと同じデータベース・サービス(wcedg.mycompany.com)が使用されていることを前提としています。ただし、デプロイメントではSOA専用の別のデータベース・サービス(soaedg.mycompany.comなど)の使用を選択することもできます。
ディレクトリを構成ウィザードの場所に変更します。これはSOAホーム・ディレクトリにあります(すべてのデータベース・インスタンスを稼働状態にすることをお薦めします)。
SOAHOST1> cd ORACLE_HOME/common/bin
SOAHOST1> ./config.sh
「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。
「WebLogicドメイン・ディレクトリ」画面で、WebLogicドメイン・ディレクトリ(ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>
)を選択し、「次へ」をクリックします。
「拡張ソースの選択」画面で、次の手順を実行します。
「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。
次の製品を選択します。
Oracle SOA Suite 11.1.1.0
次の製品はすでに選択されてグレー表示されています。これらの製品は、第4.4項「SOAHOST1での構成ウィザードを使用したドメインの作成」の手順でドメインを作成したときに選択されたものです。
WebLogic Serverの基本ドメイン
Oracle Enterprise Manager
Oracle WSM Policy Manager
Oracle JRF
「次へ」をクリックします。
このドメインではOracle JRFが定義済であることを示す「競合の検出」メッセージが表示された場合は、「既存のコンポーネントを保持する」オプションを選択して、「OK」をクリックします。
「JDBCコンポーネント・スキーマの構成」画面(図5-1)で、次の手順を実行します。
表で「SOAインフラストラクチャ」、「ユーザー・メッセージング・サービス」および「SOA MDSスキーマ」が表示された各行を選択します。
「次のパネルで選択したコンポーネント・スキーマをRACマルチ・データ・ソース・スキーマとして構成します。」を選択します。
「次へ」をクリックします。
「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面(図5-2)で、次の手順を実行します。
「SOAインフラストラクチャ」を選択します。
次の各フィールドに値を入力して、RCUでシードされたRACデータベースの接続情報を指定します。
ドライバ: 「Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11」を選択します。
サービス名: データベースのサービス名を入力します(wcedg.mycompany.com
など)。
ユーザー名: スキーマの完全なユーザー名(接頭辞を含む)を入力します。図5-2に示すユーザー名では、RCUから作成されたスキーマの接頭辞にsoedg
が使用されたことが前提となっています。
パスワード: スキーマへのアクセスに使用するパスワードを入力します。
「追加」をクリックし、最初のRACインスタンスの詳細を入力します。
この手順をRACインスタンスごとに実行します。
「SOAインフラストラクチャ」を選択解除します。
「ユーザー・メッセージング・サービス」を選択します。
ユーザー・メッセージング・スキーマについて、前述のb、cおよびdの各手順を繰り返します。
「ユーザー・メッセージング・サービス」を選択解除します。
「SOA MDSスキーマ」を選択します。
SOA MDSスキーマについて、前述のb、cおよびdの各手順を繰り返します。
OWSM MDSスキーマの情報は変更しません。
「次へ」をクリックします。
「JDBCデータ・ソースのテスト」画面で、各接続のテストが自動的に行われます。「ステータス」列に結果が表示されます。すべての接続が成功したことを確認します。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続に成功したら「次へ」をクリックします。
「オプションの構成を選択」画面で、次の項目を選択します。
JMS分散宛先
管理対象サーバー、クラスタ、およびマシン
デプロイメントとサービス
「次へ」をクリックします。
「JMS分散宛先タイプの選択」画面で次の操作を行います。
UMSJMSystemResourceのドロップダウン・リストから「UDD」を選択します。
UMSJMSystemResourceのドロップダウン・リストから「UDD」を選択します。
「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。
soa_server1
というサーバーが自動的に作成されます。このサーバーの名前をWLS_SOA1に変更して、表5-1に示す属性をこのサーバーに割り当てます。続いて、WLS_SOA2という新しいサーバーを追加します。管理対象サーバーであるWLS_WSM1とWLS_WSM2は、拡張するドメインに属しているのですでに存在しています。最終的に、管理対象サーバーのリストは表5-1のリストと一致する必要があります。
表5-1 管理対象サーバー
名前 | リスニング・アドレス | リスニング・ポート | SSLリスニング・ポート | SSL有効 |
---|---|---|---|---|
WLS_SOA1 |
SOAHOST1VHN1 |
8001 |
該当なし |
いいえ |
WLS_SOA2 |
SOAHOST2VHN1 |
8001 |
該当なし |
いいえ |
WLS_WSM1 |
SOAHOST1 |
7010 |
該当なし |
いいえ |
WLS_WSM2 |
SOAHOST2 |
7010 |
該当なし |
いいえ |
「次へ」をクリックします。
表5-2 クラスタ
名前 | クラスタ・メッセージング・モード | マルチキャスト・アドレス | マルチキャスト・ポート | クラスタ・アドレス |
---|---|---|---|---|
SOA_Cluster |
ユニキャスト |
該当なし |
該当なし |
空白のままにします。 |
WSM-PM_Cluster |
ユニキャスト |
該当なし |
該当なし |
空白のままにします。 |
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。
SOA_Cluster:
WLS_SOA1
WLS_SOA2
WSM-PM_Cluster:
WLS_WSM1
WLS_WSM2
「次へ」をクリックします。
「マシンの構成」画面で、次の手順を実行します。
デフォルトで表示される「LocalMachine」を削除します。
「Unixマシン」タブをクリックします。次のエントリが表示されます(表5-3)。
その他すべてのフィールドはデフォルト値のままにします。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。
ADMINHOST:
AdminServer
SOAHOST1:
WLS_SOA1
WLS_WSM1
SOAHOST2:
WLS_SOA2
WLS_WSM2
「次へ」をクリックします。
「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。
usermessagingserverおよびusermessagingdriver-emailは、SOA_Clusterにのみターゲット設定する必要があります (usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです)。
oracle.rules.*、oracle.sdp.*、およびoracle.soa.*の各ライブラリは、SOA_Clusterにのみターゲット設定する必要があります。
wsm-pmアプリケーションは、WSM-PM_Clusterにのみターゲット設定する必要があります。
oracle.wsm.seedpoliciesライブラリは、WSM-PM_Clusterにのみターゲット設定する必要があります。
WebLogic WebServicesをSOA_Clusterにもデプロイする場合のみ、このライブラリをそれにもターゲット設定します。
「次へ」をクリックします。
「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。
JOC起動クラスおよびJOC停止クラスは、「WSM-PM_Cluster」にのみターゲット設定します。
mds-owsm、mds-owsm-rac0およびmds-owsm-rac1は、WSM-PM_ClusterおよびAdminServerの両方にターゲット設定します。
「次へ」をクリックします。
「構成のサマリ」画面で「拡張(E)」をクリックします。
注意: ドメイン構成ポートがホスト・ポートと競合していることを警告するダイアログが表示されますが、「OK」をクリックして閉じてください。この警告は、すでにインストールされているWSM-PMが原因で表示されます。 |
「ドメインの拡張」画面で、「完了」をクリックします。
この構成を有効にするには、管理サーバーを再起動する必要があります。
第4.5項「SOAHOST1での管理サーバー用boot.propertiesの作成」の手順に従って管理サーバーを再起動します。
コンポジットのデプロイではマルチキャスト通信がデフォルトで使用されますが、SOAエンタープライズ・デプロイメントではユニキャスト通信の使用をお薦めします。セキュリティ上の理由からマルチキャスト通信を無効にしている場合は、ユニキャストを使用します。
注意: デプロイメントに使用するOracle Coherenceフレームワークの構成が正しくないと、SOAシステムを起動できないことがあります。SOAシステムを実行するネットワーク環境に応じて、デプロイメント・フレームワークを適切にカスタマイズする必要があります。この項で説明する構成の使用をお薦めします。 |
マルチキャスト通信を使用すると、クラスタの中でコンポジットの動的なデプロイメント先となるすべてのメンバーをOracle Fusion Middleware SOAで検出できます。しかし、ユニキャスト通信を使用した場合、この方法ではノードから他のクラスタ・メンバーを検出できません。したがって、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加した新しいノードから既存ノードのいずれかを検出するために必要な数のノードを指定するだけでかまいません。この結果、クラスタに追加した新しいノードからクラスタにある他のすべてのノードを検出できます。また、同じマシンで複数のIPを使用できるSOAエンタープライズ・デプロイメントなどの構成では、特定のホスト名を使用してOracle Coherenceクラスタを作成するようにOracle Coherenceを構成する必要があります。
tangosol.coherence.wka
<n>
システム・プロパティを使用してノードを指定します。ここで<n>
は1から9の番号であり、指定できるノードは最大9個です。この番号は1から開始し、以降は順番に割り当てる必要があります。不連続な番号の割当てはできません。また、Oracle Coherenceでクラスタを作成するために使用するホスト名をtangosol.coherence.localhost
システム・プロパティで指定します。このローカル・ホスト名には、SOAサーバーでリスナーのアドレスとして使用する仮想ホスト名を指定する必要があります(SOAHOST2VHN1とSOAHOST2VHN1)。このプロパティを設定するには、Oracle WebLogic Server管理コンソールの「サーバーの起動」タブにある「引数」フィールドに-Dtangosol.coherence.localhost
パラメータを追加します(図5-2)。
図5-3 Oracle WebLogic Server管理コンソールの「サーバーの起動」タブを使用したホスト名の設定
Oracle Coherenceで使用するホスト名を追加するには、次の手順を実行します。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーの概要」ページが表示されます。
表の「名前」列にハイパーリンクで表示されているサーバーの名前(WLS_SOA1またはWLS_SOA2)をクリックします。選択したサーバーの「設定」ページが表示されます。
「ロックして編集」をクリックします。
「サーバーの起動」タブをクリックします(図5-3を参照)。
WLS_SOA1とWLS_SOA2について、「引数」フィールドに次の値を入力します。
WLS_SOA1については次の値を入力します。
-Dtangosol.coherence.wka1=SOAHOST1VHN1 -Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST1VHN1
WLS_SOA2については次の値を入力します。
-Dtangosol.coherence.wka1=SOAHOST2VHN1 -Dtangosol.coherence.wka2=SOAHOST1VHN1 -Dtangosol.coherence.localhost=SOAHOST2VHN1
注意: デプロイメントに使用される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=SOAHOST2VHN1 -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 |
注意: 異なる -D パラメータの間には、空白の行を入れないでください。テキストは、前述の場所からコピーして管理コンソールの引数テキスト・フィールドに貼り付けないでください。貼り付けると、Java引数にHTMLタグが挿入される可能性があります。このテキストには、前述の例に含まれているテキスト文字以外の文字を入れないでください。 |
「保存」→「変更のアクティブ化」をクリックします。
注意: これらの変数が管理対象サーバーに正しく渡されることを確認する必要があります (これらの変数はサーバーの出力ログに記録されます)。Oracle Coherenceフレームワークに問題があると、soa-infraアプリケーションを起動できないことがあります。 |
注意: このマルチキャスト・アドレスとユニキャスト・アドレスは、WebLogic Serverクラスタでクラスタ通信に使用するものとは異なります。SOAでは、2つのエンティティ(WebLogic Serverクラスタおよびコンポジットのデプロイ先グループ)の通信プロトコルが異なる場合でも、単一のWebLogic Serverクラスタの各メンバーにコンポジットを確実にデプロイできます。 |
注意: デプロイに使用するCoherenceクラスタは、デフォルトでポート8088を使用します。-Dtangosol.coherence.wkaX.port 起動パラメータを指定することにより、このポートを変更できます。 |
Oracle B2Bでは、特定のJMS宛先メンバー・コールを使用します。これらのコールを成功させるには、作成先識別子(CDI)を設定する必要があります。CDIを設定する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで「サービス」ノードを開き、「メッセージング」ノードを開きます。
「JMSモジュール」→「SOAJMSModule」をクリックします。
「ロックして編集」をクリックします。
「dist_B2BEventQueue_auto」→「構成」→「一般」タブをクリックし、「詳細」をクリックします。
「作成先識別子」フィールドで、キューに次のJNDI名を追加します。
jms/b2b/B2BEventQueue
この手順を繰り返して、次に一覧表示するキューに対して、次の作成先識別子を作成します。
dist_B2B_OUT_QUEUE_auto : jms/b2b/B2B_OUT_QUEUE
dist_B2B_IN_QUEUE_auto : jms/b2b/B2B_IN_QUEUE
dist_B2BBroadcastTopic_auto : jms/b2b/B2BBroadcastTopic
dist_XmlSchemaChangeNotificationTopic_auto : jms/fabric/XmlSchemaChangeNotificationTopic
保存およびアクティブな変更をクリックします。
この手順は、管理サーバーで様々なノードを認証するための適切な証明書を設定していない場合に必要です(第7章「ノード・マネージャの設定」を参照)。サーバー証明書を構成していないと、様々なWebLogicサーバーを管理する際にエラーが発生します。このエラーを回避するには、トポロジの設定と検証を行う際にホスト名の検証を無効にし、EDGトポロジの構成完了後に第7章「ノード・マネージャの設定」の説明に従って再びホスト名の検証を有効にします。
ホスト名の検証を無効にするには、次の手順を実行します。
Oracle WebLogic Server管理コンソールにログインします。
「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーの概要」ページが表示されます。
表の「名前」列で「WLS_SOA1」(これはハイパーリンクとして表示されています)を選択します。「設定」ページが表示されます。
「SSL」タブを選択します。
表示されたページの「詳細」セクションを開きます。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
WLS_SOA2管理対象サーバーについてこの手順を繰り返します。
変更を保存してアクティブ化します。
SOAHOST1でノード・マネージャを再起動するには:
ノード・マネージャに関係付けられたプロセスを停止することで、ノード・マネージャを停止します。
シェルのフォアグラウンドで実行されている場合は、[Ctrl]を押しながら[C]を押します。
シェルのバックグラウンドで実行されている場合は、関連付けられたプロセスを見つけ、kill
コマンドを使用して停止します。例:
SOAHOST1> ps -ef | grep NodeManager orcl 9139 9120 0 Mar03 pts/6 00:00:00 /bin/sh ./startNodeManager.sh SOAHOST1>kill -9 9139
ノード・マネージャを起動します。
SOAHOST1> ./startNodeManager.sh
起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播するには:
管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのコピーを作成します。
次の一連のコマンドを使用し、SOAHOST1でpack
コマンドを実行してテンプレート・パックを作成します。
SOAHOST1> cd ORACLE_COMMON_HOME/common/bin SOAHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/admin/<domain_name>/aserver/<domain_name> -template=soadomaintemplateExtSOA.jar -template_name=soa_domain_templateExtSOA
次のようにunpack
コマンドをSOAHOST1上で実行して、伝播されたテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。
SOAHOST1> ./unpack.sh -domain=ORACLE_BASE/admin/<domain_name>/mserver/<domain_name> -overwrite_domain=true -template=soadomaintemplateExtSOA.jar -app_dir=ORACLE_BASE/admin/<domain_name>/mserver/applications
注意: unpackコマンドで-overwrite_domain オプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。 |
SOAHOST1上でWLS_SOA1管理対象サーバーを起動するには、次の手順を実行します。
管理コンソール(http://ADMINVHN:7001/console
)にアクセスします。
「サーバー」をクリックします。
「制御」タブを開きます。
「WLS_SOA1」を選択します。
「起動」をクリックします。
注意: ADMINVHNは、SOAHOST1で管理サーバーがリスニングする仮想IPにマップされる仮想ホスト名です。 |
WLS_SOA1管理対象サーバーを検証するには、次の手順を実行します。
管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です。」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第11.6項「トラブルシューティング」を参照してください。
http://SOAHOST1VHN1:8001/soa-infra/
にアクセスしてWLS_SOA1のステータスを確認します。
http://SOAHOST1VHN1:8001/b2bconsole/
にアクセスしてB2Bのステータスを確認します。
http://SOAHOST1VHN1:8001/integration/worklistapp/
にアクセスしてワークリスト・アプリケーションのステータスを確認します。アクセスが許可されていることを確認する前に、管理対象サーバーWLS_WSM1が稼動していることを確認します。
注意: WLS_SOA1サーバーが稼働していても、一部のアプリケーションが失敗した状態になることがあります。そのため、前述のURLを検証し、個別のアプリケーションに関するエラーがないか、サーバーの出力ファイルで確認することをお薦めします。 |
ドメイン構成を伝播するには、次の手順を実行します。
次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・ファイルをSOAHOST2にコピーします。
SOAHOST1> cd ORACLE_HOME/common/bin SOAHOST1> scp soadomaintemplateExtSOA.jar oracle@node2:ORACLE_HOME/common/bin
unpack
コマンドをSOAHOST2で実行し、伝播されたテンプレートを解凍します。
SOAHOST2> cd ORACLE_HOME/common/bin SOAHOST2> ./unpack.sh -domain=ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>/ -template=soadomaintemplateExtSOA.jar -overwrite_domain=true -app_dir=ORACLE_BASE/admin/<domain_dir>/mserver/apps
注意: unpackコマンドで-overwrite_domain オプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。 |
第5.8項「SOAHOST1でのノード・マネージャの再起動」の手順をSOAHOST2で実行します。
次の手順を実行して、WLS_SOA2管理対象サーバーを起動し、このサーバーが正しく構成されていることを確認します。
管理コンソールを使用してWWLS_SOA2管理対象サーバーを起動します。
管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です。」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないかどうかを確認します。考えられる原因は、第11.6項「トラブルシューティング」を参照してください。
http://SOAHOST2VHN1:8001/soa-infra
にアクセスします。
http://SOAHOST2VHN1:8001/b2bconsole
にアクセスしてB2Bのステータスを確認します。
http://SOAHOST2VHN1:8001/integration/worklistapp/
にアクセスしてワークリスト・アプリケーションのステータスを確認します。アクセスが許可されていることを確認する前に、少なくとも1つの管理対象サーバー(WLS_WSM1またはWLS_WSM2)が稼動していることを確認します。
注意: WLS_SOA1サーバーが稼働していても、一部のアプリケーションが失敗した状態になることがあります。そのため、前述のURLを検証し、個別のアプリケーションに関するエラーがないか、サーバーの出力ファイルで確認することをお薦めします。 |
WLS_SOAn管理対象サーバーが属するSOA_ClusterにOracle HTTP Serverからルーティングできるようにするには、WebLogicCluster
パラメータをこのクラスタにあるノードのリストに設定する必要があります。
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> # 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> # UMS parlay <Location /sdpmessaging/parlayx> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> # UMS WS <Location /ucs/messaging/webservice> 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>
注意: /workflow のエントリは省略可能です。これは、ADFタスク・フォームと関連付けられたワークフロー・タスク用です。/workflow のURL自体は、フォームに応じた別の値とすることができます。 |
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 Fusion Middleware Oracle WebLogic ServerでのWeb Serverプラグインの使用のガイドを参照してください。
管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です。」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないかどうかを確認します。考えられる原因は、第11.6項「トラブルシューティング」を参照してください。
次のURLにアクセスできることを確認します。webhostN
には、各Oracle HTTP Serverホストの名前を指定します(WEBHOST1
やWEBHOST2
など)。
http://webhostN:7777/soa-infra
http://webhostN:7777/integration/worklistapp
http://webhostN:7777/b2bconsole
http://webhostN:7777/sdpmessaging/userprefs-ui
http://webhostN:7777/soa/composer
両方のOracle HTTP ServerインスタンスからSOA_Clusterを検証します。
ロード・バランサを介してシステムにアクセスするために、ロード・バランサの構成を参照します。
Oracle WebLogic Serverクラスタについて、フロントエンドHTTPのホストとポートを設定する必要があります。
WebLogic Server管理コンソールの「チェンジ・センター」セクションの「ロックして編集」をクリックします。
左ペインの「ドメイン構造」ウィンドウで「環境」を選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。
SOA_Clusterクラスタを選択します。
「HTTP」を選択します。
次の値を設定します。
フロントエンド・ホスト: wc.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. |
SOAシステムでは、次のようにコールバックURLを計算します。
SOAへのリクエストが外部または内部のサービスから発行された場合、SOAはクライアントで指定されたコールバックURLを使用します。
外部または内部の非同期サービスへのリクエストがSOAから発行された場合は、次の方法でコールバックURLが決定されます。ここでは決定方法の優先度が高い順に示しています。
特定の参照用のバインド・プロパティとして指定されたcallbackServerURL
を使用します(このプロパティは、コンポジットのモデリング時または実行時にMBeansを使用して設定できます)。これにより、サービス呼出しごとに異なるコールバックURLを割り当てることができます。つまり、外部サービスからのコールバックURLには、内部サービスへのコールバックURLとは異なる値を設定できます。EDGアーキテクチャでの一般的なコールバックURLは、外部サービスについてはwc.mycompany.com
(443/https)、内部サービスについてはwcinternal.mycompany.com
(7777/http)です。このプロパティは、システムMBeanブラウザに対応するバインドmbeanを通じ、実行時にシステムMBeanブラウザを使用して設定します。特定のURLを追加するには、そのProperties属性にcallbackServerURL
プロパティを追加してから保存操作を実行します。
soa-infra-config.xmlで指定したコールバックURLを使用します。この場合、指定できるアドレスは1つのみです。外部サービスと内部サービスの両方を組み合せて呼び出し可能な場合は、EDGアーキテクチャでこのアドレスをwc.mycompany.com
(443/https)に設定する必要があります。内部サービスのみを呼び出す場合は、このアドレスをwcinternal.mycompany.com
(7777/http)に設定します。
SOA_ClusterのWLSで指定するフロントエンド・ホストとして、このコールバックURLを使用します。この場合も指定できるアドレスは1つのみなので、soa-infra-config.xmlの場合と同じ処理をお薦めします。
WLS MBean APIで指定されたローカル・ホスト名を使用します。EDGなどのHA環境では、この方法はお薦めできません。
直接バインディング・コンポジットを使用する場合は、SOA_ClusterにWLSクラスタ・アドレスを設定する必要があります。WLSクラスタ・アドレスを設定する手順は次のとおりです。
WebLogic Server管理コンソールの「チェンジ・センター」セクションの「ロックして編集」をクリックします。
左ペインの「ドメイン構造」ウィンドウで「環境」を選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。
SOA_Clusterクラスタを選択します。
「構成」→「一般」タブで、「クラスタ・アドレス」フィールドに次のように入力します。
SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
「保存」をクリックします。
変更を有効にするために、管理コンソールの「チェンジ・センター」セクションの「変更のアクティブ化」をクリックします。
サーバーを再起動して、クラスタのフロントエンド・ホストの指定を有効化します。
注意: 直接バインディングを介してリクエスト/レスポンスが非同期でやり取りされるようにするため、SOAコンポジットでは、JNDIプロバイダURLを提供して、呼び出されたサービスが、コールバックするBeanを検索できるようにする必要があります。soa-infraの構成プロパティは指定されていないがWLSクラスタ・アドレスが指定されている場合は、JNDIプロバイダURLのクラスタ・アドレスが使用されます。このクラスタ・アドレスには、クラスタ化されたサーバーのIPアドレスにマップする単一のDNS名を指定することも、サーバーip:portのカンマ区切りリストを指定することもできます。また、ユーザーが明示的に設定していれば、soa-infraの構成プロパティ |
すべての永続ストアの場所を、両ノードから認識できるディレクトリとして構成します。詳細は、第2.3項「共有記憶域と推奨ディレクトリ構造」を参照してください。次のように、この共有ベース・ディレクトリを使用するようにすべての永続ストアを変更する必要があります。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウの「サービス」ノードを開いて「永続ストア」ノードをクリックします。「永続ストアの概要」ページが表示されます。
表の「名前」列で、該当の永続ストア(これはハイパーリンクとして表示されています)を選択します。その永続ストアの「設定」ページが表示されます。
「構成」タブの「ディレクトリ」フィールドに、クラスタにある他のサーバーで使用できる永続記憶域ソリューション(NASやSANなど)上の場所を入力します。この場所を指定すると、JMSの保留メッセージを送信できます。この場所は、次のディレクトリ構造であることが必要です。
ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/jms
注意: WLS_SOA1とWLS_SOA2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。 |
「保存」をクリックして変更内容を有効にします。
サーバーを再起動して永続ストアの変更内容を有効にします。
各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。WebLogic Serverでは、システム・クラッシュやネットワーク障害からのリカバリ時にこのトランザクション・ログを使用します。クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセスできる場所にトランザクション・ログを格納します。
注意: デュアルポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)をこの場所とすることをお薦めします。 |
デフォルト永続ストアの場所を設定するには、次の手順を実行します。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」ノードをクリックします。「サーバーの概要」ページが表示されます。
表の「名前」列にあるサーバーの名前(ハイパーリンクとして表示されています)をクリックします。選択したサーバーの「設定」ページが表示され、デフォルトで「構成」タブが選択状態になります。
「サービス」タブをクリックします。
表示されたページの「デフォルト・ストア」セクションで、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。このパスのディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/tlogs
「保存」をクリックします。
注意: トランザクション・リカバリ・サービスの移行を有効にするには、クラスタにある他のサーバーが使用できる永続記憶域ソリューションの場所を指定します。WLS_SOA1とWLS_SOA2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。 |
Oracle File AdapterおよびOracle FTP Adapterを使用すると、BPELプロセスやOracle MediatorでFTP(ファイル転送プロトコル)を使用して、ローカルとリモートのファイル・システムにあるファイルの読取りと書込みができます。これらのアダプタは、インバウンドとアウトバウンドの両方の操作に対し、Oracle BPEL Process ManagerとOracle Mediatorサービス・エンジンを使用してアクティブ/アクティブ・トポロジの高可用性をサポートします。Oracle File AdapterとOracle FTP Adapterがアウトバウンド操作に対する高可用性を備えるようにするには、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のアウトバウンド操作での高可用性に関する項を参照してください。データベースのmutex lock操作を使用すると、複数の参照から同じディレクトリへの書込みが発生しても、これらのアダプタでは相互の上書きを防止できます。
注意: ファイル・アダプタは、インバウンド・ディレクトリからファイルを取得して処理し、出力ディレクトリにファイルを出力します。ファイル・アダプタでの処理はトランザクション方式ではないので、ファイルは2回処理できます。この結果として、RACバックエンドまたはSOA管理対象サーバーでフェイルオーバーが発生したときに、重複するファイルが得られる可能性があります。 |
データベース表をコーディネータとして使用することで、アウトバウンドのOracleファイルやFTPアダプタのサービスに高可用性を実現します。そのためには次の手順を実行します。
注意: データベースをコーディネータとして使用する場合は、グローバル・トランザクション・タイムアウトの値を大きくする必要があります。 |
データベース表の作成
データベース・スキーマはsoainfraの一部として事前に作成済なので、この手順を実行する必要はありません。
Oracleファイル・アダプタのデプロイメント・ディスクリプタの変更
eis/HAFileAdapter
に対応する接続インスタンスについて、Oracle WebLogic ServerコンソールからOracleファイル・アダプタのデプロイメント・ディスクリプタを変更します。
Oracle WebLogic Serverコンソールにログインします。このコンソールにアクセスするには、http://
servername
:portnumber
/console
にアクセスします。
「ドメイン構造」の左ペインで「デプロイメント」をクリックします。
右ペインの「デプロイメントの概要」で「FileAdapter」をクリックします。
「構成」タブをクリックします。
「アウトバウンド接続プール」タブをクリックして「javax.resource.cci.ConnectionFactory」を開き、構成済の接続ファクトリを表示します。
「eis/HAFileAdapter」をクリックします。高可用性に対応する接続ファクトリの「アウトバウンド接続のプロパティ」が表示されます。
図5-4に示すように、接続ファクトリのプロパティが表示されます。
図5-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/SOALocalTxDataSource
に設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータソースです。
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>/dp/Plan.xml
「保存してアクティブ化」をクリックします。
次の例(バインディング・コンポーネント用コンポジットに含まれるjcaファイル)に示すように、BPEL Processまたは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 に設定されています。 |
論理削除ポーリングを使用していて、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テクノロジ・アダプタ・ユーザーズ・ガイド』の、スケーラビリティに関する項およびポーリング方式に関する項を参照してください。
拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、このガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法に関する詳細は、このガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、このガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。データベースのバックアップに関する詳細は、Oracle Databaseバックアップおよびリカバリ・ガイドも参照してください。
この時点でインストールをバックアップするには、次の手順を実行します:
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をバックアップするには、次のコマンドを実行してください。
SOAHOST1> tar -cvpf fmwhomeback.tar MW_HOME |