1. Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド
  2. エンタープライズ・デプロイメントの構成
  3. Oracle SOA Suiteを含めるドメインの拡張

14 Oracle SOA Suiteを含めるドメインの拡張

Oracle SOA Suiteソフトウェアを追加してエンタープライズ・デプロイメント・ドメインを拡張するには、特定のタスクを実行する必要があります。
  • Oracle SOA Suiteの構成時に使用される変数
    Oracle SOA Suiteを追加してドメインを拡張する際には、この項にリストされているディレクトリ変数を参照します。
  • Oracle SOA Suiteでの動的クラスタのサポート
    SOAは、静的クラスタベースのトポロジと動的クラスタベースのトポロジの2種類のトポロジをサポートしています。動的クラスタのトポロジを選択したときには、いくつかの点で従来型の静的クラスタ構成との違いが生じます。
  • システム・クロックの同期
    Oracle SOA Suiteを追加するためにドメインを拡張する前に、各ホスト・コンピュータのシステム・クロックが同期していることを確認します。
  • エンタープライズ・デプロイメント用のソフトウェアのインストール
    この項では、エンタープライズ・デプロイメント用のソフトウェアをインストールする手順を説明します。
  • Oracle SOA Suiteデータベース・スキーマの作成
    Oracle SOA Suiteドメインを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに必要なスキーマをインストールする必要があります。
  • Oracle SOA Suiteを含めるエンタープライズ・デプロイメント・ドメインの拡張
    次のタスクを実行して、Oracle SOA Suiteソフトウェアを含めることで既存のエンタープライズ・デプロイメント・ドメインを拡張します。
  • ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播
    Oracle WebCenter Portalインスタンスを含めることでドメインを拡張し、WCPHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリとマシンに伝播する必要があります。
  • ドメイン解凍後のNodeManager構成の更新
    ドメインの拡張時に、MSERVER_HOMEのnodemanager.propertiesファイルがASERVER_HOMEのnodemanager.propertiesファイルの一部の値で上書きされることがあります。具体的には、ListenAddressまたはCustomIdentityAlias (あるいはその両方)の値がリセットされる場合があります。
  • 既存の管理対象サーバーの再起動と検証
    ドメインが拡張され、すべてのサーバーのMSERVER_HOMEディレクトリに解凍されたら、既存のコンポーネントの管理対象サーバーを再起動する必要があります。
  • エンタープライズ・ドメインでのuploadおよびstageディレクトリの絶対パスへの変更
    ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。また、AdminServerのアップロード・ディレクトリを、相対パスではなく、同じ絶対パスを持つように更新します。そうしないと、デプロイメントの問題が発生する可能性があります。動的クラスタを実装する場合、新しく追加した各クラスタに割り当てられたサーバー・テンプレートの構成を検証および更新する必要があります。そうでない場合、新しく追加したクラスタの静的に定義された各管理対象サーバーを検証および構成します。
  • 動的クラスタの使用時のリスニング・アドレスの構成
  • WLS_SOA1管理対象サーバーの起動および検証
    これでドメインの拡張、管理サーバーの起動、およびドメインの他のホストへの伝播を完了したので、新しく構成したOracle SOA Suite管理対象サーバーを起動できます。
  • 管理対象サーバーWLS_SOA2の起動と検証
    WLS_SOA1管理対象サーバーの正常な構成と起動を検証したら、WLS_SOA2管理対象サーバーを起動して検証できます。
  • 拡張したドメインでのOracle HTTP Serverの構成
    次の項では、パブリックURLおよび内部URLの両方のリクエストを、エンタープライズ・トポロジ内の正しいクラスタにルーティングするようにOracle HTTP Serverインスタンスを構成する方法について説明します。
  • Oracle SOA Suiteの構成後ステップ
    Oracle SOA Suiteをインストールして構成した後、次のような構成後タスクを検討します。
  • JDBC永続ストアの有効化
    Oracleデータベースの一貫性、データ保護および高可用性機能を活用し、クラスタ内のすべてのサーバーによるリソースの使用を可能にする、JDBCストアを使用することをお薦めします。
  • 自動サービス移行の有効化
    この章でインストールした製品の高可用性を実現するには、適切にサービス移行を構成する必要があります。
  • 構成のバックアップ
    ベスト・プラクティスとして、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。ここまでのインストールが正常に行われたことを確認したら、バックアップを作成します。これは、後のステップで問題が発生した場合に即座にリストアするための迅速なバックアップになります。

上位トピック: 「エンタープライズ・ドメインの構成」

Oracle SOA Suiteの構成時に使用する変数

Oracle SOA Suiteを追加してドメインを拡張する際には、この項にリストされているディレクトリ変数を使用します。

いくつかのディレクトリ変数の値は、「このガイドで使用するファイル・システムとディレクトリ変数」で定義されています。

  • ORACLE_HOME

  • ASERVER_HOME

  • MSERVER_HOME

  • APPLICATION_HOME

  • DEPLOY_PLAN_HOME

  • WEB_DOMAIN_HOME

  • JAVA_HOME

  • ORACLE_RUNTIME

さらに、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」で定義されている次の仮想IP (VIP)アドレスを参照します。

  • ADMINVHN

この章のアクションは、次のホスト・コンピュータで実行します。

  • WCPHOST1

  • WCPHOST2

  • WEBHOST1

  • WEBHOST2

  • WCCHOST1

  • WCCHOST2

親トピック: Oracle SOA Suiteを含めるドメインの拡張

Oracle SOA Suiteでの動的クラスタのサポート

SOAは、静的クラスタベースのトポロジと動的クラスタベースのトポロジの2種類のトポロジをサポートしています。動的クラスタのトポロジを選択したときには、いくつかの点で従来型の静的クラスタ構成との違いが生じます。

静的クラスタは、構成済クラスタとも言い、各サーバー・インスタンスを手動で構成して追加する従来型のクラスタです。動的クラスタには、新しい"server-template"オブジェクトが含まれています。このオブジェクトは、すべての生成された(動的)サーバー・インスタンスの一元的な構成を定義するために使用します。動的クラスタを作成すると、動的サーバーが事前構成され、自動的に生成されます。この機能により、追加のサーバー容量が必要になったときに、動的クラスタ内のサーバー・インスタンスの数をスケール・アップできます。動的サーバーは、最初に手動で構成してそれをクラスタに追加する必要はなく、単に起動するだけで使用できます。

この項に示すステップには、静的トポロジまたは動的トポロジの両方に対応するドメインの構成ステップが含まれています。この2種類の構成の相違点は次のとおりです。

  • 構成ウィザードのプロセスは、それぞれのケースに応じて異なることがあります。たとえば、サーバーではなく動的クラスタ用のサーバー・テンプレートの定義が必要になります。

  • 動的クラスタの場合は、サーバー固有の構成(リスニング・アドレスの設定、アップロードとステージングのディレクトリの構成、キーストアの構成など)をサーバーではなくサーバー・テンプレートで実行する必要があります。

  • 動的クラスタの場合は、サービス移行が異なる方法で構成されます。動的クラスタは移行可能ターゲットを使用しないかわりに、JMSリソースがクラスタをターゲットにします。動的クラスタのサービス移行を構成する際の具体的な手順は、このガイドに記載されています。

複合クラスタ(動的サーバー・インスタンスと構成済サーバー・インスタンスの両方を含むクラスタ)は、Oracle WebCenter Portalエンタープライズ・デプロイメントではサポートされていません。

親トピック: Oracle SOA Suiteを含めるドメインの拡張

システム・クロックの同期

Oracle SOA Suiteを追加するためにドメインを拡張する前に、各ホスト・コンピュータのシステム・クロックが同期していることを確認します。

ネットワーク・タイム・プロトコル(NTP)の使用をお薦めします。「NTP (時間)サーバーを使用するためのホストの構成」を参照してください。

時刻同期を確認するには、それぞれのホストでntpstatコマンドを実行してNTPサービスに問合せを実行します。

出力例:

$ ntpstat
synchronised to NTP server (10.132.0.121) at stratum 3
 time correct to within 42 ms
 polling server every 16 s

親トピック: Oracle SOA Suiteを含めるドメインの拡張

エンタープライズ・デプロイメント用のソフトウェアのインストール

この項では、エンタープライズ・デプロイメント用のソフトウェアをインストールする手順について説明します。

親トピック: Oracle SOA Suiteを含めるドメインの拡張

WCCHOST1でのOracle SOA Suiteインストーラの起動

インストール・プログラムを起動する手順は次のとおりです。

  1. WCCHOST1にログインします。
  2. インストール・プログラムがダウンロードされたディレクトリに移動します。
  3. 次の例に示すように、システム上のJDKディレクトリからjava実行可能ファイルを実行して、インストール・プログラムを起動します。
    JAVA_HOME/bin/java -d64 -jar Installer File Name

    これらの例にあるJDKの場所は、ご使用のシステムの実際のJDKの場所に読み替えてください。

    Installer File Nameは、「エンタープライズ・デプロイメント用のソフトウェア・ディストリビューションの特定と取得」にリストされているご使用の製品の実際のインストーラ・ファイルの名前に読み替えてください。

インストール・プログラムが表示されると、インストールを開始する準備ができています。

親トピック: エンタープライズ・デプロイメント用のソフトウェアのインストール

インストール画面への移動

インストール・プログラムでは次の表に記載された順番で一連の画面が表示されます。

インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。

画面 説明

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面を使用して、使用可能なパッチを「My Oracle Support」で自動的に検索するかユーザーの組織のためにすでにダウンロードされているパッチを、ローカル・ディレクトリで自動的に検索します。

インストール場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

Oracle Fusion Middlewareのディレクトリ構造の詳細は、『Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成用のディレクトリの選択に関する項を参照してください。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

  • 「SOA Suite」を選択します

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告メッセージまたはエラー・メッセージが表示された場合は、『Oracle Fusion Middleware Infrastructureのインストールと構成』のシステム環境の検証ロードマップに関する項に記載されているドキュメントのいずれかを参照してください。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを検証できます。

「インストール」をクリックしてインストールを開始します。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

進捗バーが100%完了になった後で、「次へ」をクリックします。

インストール完了

この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

親トピック: エンタープライズ・デプロイメント用のソフトウェアのインストール

他のホスト・コンピュータへのOracle SOA Suiteのインストール

WCCHOST2上の製品マウント・ポイントとORACLE_HOME用に個別の共有記憶域ボリュームまたはパーティションを構成している場合は、WCCHOST2で製品のインストールを実行する必要もあります。

「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

トポロジ内の他のホスト・コンピュータにソフトウェアをインストールするには、各ホストにログインして、「WCCHOST1でのインフラストラクチャ・インストーラの起動」と「インフラストラクチャ・インストール画面のナビゲート」の手順に従って、適切な記憶域デバイスにOracleホームを作成します。

親トピック: エンタープライズ・デプロイメント用のソフトウェアのインストール

インストールの検証

インストールの完了後、次のタスクを正常に実行することでインストールを検証できます。

親トピック: エンタープライズ・デプロイメント用のソフトウェアのインストール

インストール・ログ・ファイルの確認

インストール・ログ・ファイルの内容を確認し、何も問題が発生していないことを確認します。ログ・ファイルとその場所の詳細は、『Oracle Universal Installerによるソフトウェアのインストール』のインストール・ログ・ファイルの理解に関する項を参照してください。

親トピック: インストールの確認

ディレクトリ構造のチェック

インストールの内容は、インストール中に選択するオプションによって異なります。

Oracle SOA Suiteを追加すると、次のディレクトリおよびサブディレクトリが追加されます。ls --format=single-columnコマンドを使用して、ディレクトリ構造を確認します。 

ls --format=single-column /u01/oracle/products/fmw/soa

bam
bin
bpm
common
integration
jlib
modules
plugins
readme.txt
reports
soa

インストール後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解のOracle Fusion Middlewareの主要ディレクトリに関する項を参照してください。

親トピック: インストールの確認

Oracleホームの内容の表示

viewInventoryスクリプトを使用して、Oracleホームの内容を表示することもできます。『Oracle Universal Installerによるソフトウェアのインストール』のOracleホームの内容の表示に関する項を参照してください。

親トピック: インストールの確認

Oracle SOA Suiteデータベース・スキーマの作成

Oracle SOA Suiteドメインを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに必要なスキーマをインストールする必要があります。

親トピック: Oracle SOA Suiteを含めるドメインの拡張

リポジトリ作成ユーティリティ(RCU)の起動

リポジトリ作成ユーティリティ(RCU)を起動するには:

  1. 対象のシステムで、ORACLE_HOME/oracle_common/binディレクトリに移動します。
  2. 対象のシステムで、JAVA_HOME環境変数が、動作保証されたJDKの場所に設定されていることを確認します。この場所は、binディレクトリより上の階層にする必要があります。たとえば、JDKが/u01/oracle/products/jdkに存在する場合は、次のようになります。

    UNIXオペレーティング・システムの場合:

    export JAVA_HOME=/u01/oracle/products/jdk
  3. RCUを起動します。

    UNIXオペレーティング・システムの場合:

    ./rcu

    注意:

    データベースで透過的データ暗号化(TDE)が有効化されている場合に、RCUによって作成される表領域を暗号化するには、RCUの起動時に-encryptTablespace trueオプションを指定します。

    これによって、RCUの実行中に追加の操作をすることなく、「表領域のマップ」画面で適切なRCU GUI「表領域の暗号化」チェック・ボックスが選択されるようにデフォルト指定されます。『リポジトリ作成ユーティリティによるスキーマの作成』の表領域の暗号化に関する項を参照してください。

親トピック: Oracle SOA Suiteデータベース・スキーマの作成

スキーマ作成のためのRCU画面のナビゲート

スキーマ作成に必要なタスクは、次のとおりです。

タスク1   RCUの導入

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

タスク2   スキーマ作成の方法の選択

対象のデータベースに対するDBAアクティビティの実行に必要なパーミッションと権限が付与されている場合は、「システム・ロードおよび製品ロード」を選択します。この手順は、必要な権限が付与されていることを前提としています。

データベースに対するDBAアクティビティの実行に必要なパーミッションまたは権限が付与されていない場合は、この画面で、「システム・ロードに対するスクリプトの準備」を選択する必要があります。このオプションによってSQLスクリプトが生成され、必要なスキーマを作成するためにデータベース管理者が利用できます。『リポジトリ作成ユーティリティによるスキーマの作成』のシステム・ロードと製品ロードの理解に関する項を参照してください。

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

タスク3   データベース接続の詳細の指定

RCUがデータベースに接続できるようにするために、データベース接続の詳細を指定します。

  1. 「ホスト名」フィールドに、Oracle RACデータベースのSCANアドレスを入力します。

  2. RACデータベースのスキャン・リスナーの「ポート」番号、たとえば1521を入力します。

  3. データベースのRAC「サービス名」を入力します。

  4. スキーマとスキーマ・オブジェクトを作成する権限を持つユーザーの「ユーザー名」、たとえば「SYS」などを入力します。

  5. ステップ4で指定した名前のユーザーの「パスワード」を入力します。

  6. SYSユーザーを選択した場合は、ロールを必ずSYSDBAに設定してください。

  7. 「次へ」をクリックして先に進み、データベースへの接続が成功したことを確認するダイアログ・ウィンドウで、「OK」をクリックします。

タスク4   カスタム接頭辞の指定とスキーマの選択

「既存の接頭辞の選択」を選択し、初期ドメインを作成したときに使用した接頭辞を選択します。

スキーマのリストから「SOA Suite」スキーマを選択します。これにより、「SOAインフラストラクチャ」が自動的に選択されます。また、次の依存スキーマがInfrastructureとともにすでにインストールされて灰色表示されています。

  • 共通インフラストラクチャ・サービス

  • Oracle Platform Security Services

  • ユーザー・メッセージング・サービス

  • 監査サービス

  • 監査サービス・アペンド

  • 監査サービス・ビューア

  • Metadata Services

  • WebLogicサービス

カスタム接頭辞は、これらのスキーマを論理的にグループ化して、このドメイン内でのみ使用することを目的としています。複数のドメイン間でのスキーマの共有はサポートされていないため、ドメインごとに固有のスキーマのセットを作成する必要があります。

ヒント:

カスタム接頭辞の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のカスタム接頭辞の理解に関する項を参照してください。

マルチドメイン環境のスキーマを構成する方法の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のスキーマの作成計画に関する項を参照してください。

「次へ」をクリックして続行し、スキーマ作成の前提条件チェックが成功したことを通知するダイアログ・ウィンドウで「OK」をクリックします。

タスク5   スキーマのパスワードの指定

スキーマのパスワードをデータベースに設定する方法を指定してから、パスワードの指定と確認を行います。続行する前にパスワードの複雑さがデータベース・セキュリティ要件を満たしていることを確認します。パスワード・ポリシーを満たしていない場合でも、この時点でRCUでは処理が続行されます。このため、このチェックはRCU自体の外部で実行します。

ヒント:

この画面で設定するパスワードは、メモしておく必要があります。このパスワードは、後述するドメイン作成のプロセスで必要になります。

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

タスク6   カスタム変数の指定

SOAインフラストラクチャ・スキーマのカスタム変数を指定します。

エンタープライズ・デプロイメント・トポロジの場合、Database Profileカスタム変数としてLARGEを入力し、Oracle Healthcareの使用を予定している場合は、Healthcare Integration変数としてYESを入力します。『Oracle SOA SuiteおよびBusiness Process Managementのインストールと構成』のSOA Suiteスキーマに必要なカスタム変数に関する項を参照してください。

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

タスク7   必須スキーマの表領域の検証

「表領域のマップ」画面で情報を確認し、「次へ」をクリックして、デフォルト値を受け入れます。

確認ダイアログ・ボックスで「OK 」をクリックします。

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

タスク8   スキーマの作成

ロード対象のスキーマのサマリーをレビューし、「作成」をクリックしてスキーマの作成を完了します。

注意:

障害が発生した場合、続行する前に、リストされたログ・ファイルをレビューして根本的原因を特定し、欠陥を解決してから、RCUを使用してスキーマを削除して再作成します。

タスク9   レビュー完了のサマリーとRCU実行の完了

「完了サマリー」画面まで進んだら、スキーマ作成がすべて正常に完了していることを確認し、「閉じる」をクリックしてRCUを閉じます。

親トピック: Oracle SOA Suiteデータベース・スキーマの作成

スキーマ・アクセスの確認

RCUで作成した新しいスキーマ・ユーザーとしてデータベースに接続し、スキーマ・アクセスを確認します。SQL*Plusまたは別のユーティリティを使用して接続し、RCUに入力した適切なスキーマ名およびパスワードを入力します。

次に例を示します。

./sqlplus

SQL*Plus: Release 12.1.0.2.0 Production on Wed Aug 31 05:41:31 2016

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Enter user-name: FMW1221_SOAINFRA
Enter password: soainfra_password

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production 
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Advanced Analytics and Real Application Testing options 

SQL>

親トピック: Oracle SOA Suiteデータベース・スキーマの作成

トランザクション・リカバリ用のSOAスキーマの構成

Oracle SOA Suiteスキーマを正常にインストールしたら、この項の手順に従ってトランザクション・リカバリのスキーマを構成します。

この手順では、WebLogic Serverが予期せずに使用不可になった後、進行中のトランザクションをリカバリする際に、Oracle WebLogic Serverトランザクション・マネージャでトランザクション状態の情報を問い合せて該当するコマンド(commitやrollbackなど)を発行できるように適切なデータベース権限を設定します。

これらの権限は、RCUでスキーマを作成したときに定義したSOAINFRAスキーマの所有者に付与する必要があります。

トランザクション・リカバリ権限のSOAスキーマを構成する手順は次のとおりです。

  1. sysdba権限を持つユーザーとしてSQL*Plusにログオンします。例: 
    sqlplus "/ as sysdba"
  2. 次のコマンドを入力します。
    SQL> Grant select on sys.dba_pending_transactions to soa_schema_prefix_soainfra;

Grant succeeded.
 
SQL> Grant force any transaction to soa_schema_prefix_soainfra;
 
Grant succeeded.
 
SQL>

親トピック: Oracle SOA Suiteデータベース・スキーマの作成

Oracle SOA Suiteを含めるエンタープライズ・デプロイメント・ドメインの拡張

次のタスクを実行して、Oracle SOA Suiteソフトウェアを含めることで既存のエンタープライズ・デプロイメント・ドメインを拡張します。

注意:

フットプリントを改善し起動を最適化するために、構成ウィザードのセッション後にコア・アダプタのみをSOAクラスタ(MFTを構成する場合はMFTクラスタ)にターゲット指定します。二義的なアダプタを手動でターゲット指定する必要があります(このアダプタが必要な場合)。「手動でのアダプタのターゲット指定」を参照してください。

ドメインを拡張するには、次のタスクを実行する必要があります。

親トピック: Oracle SOA Suiteを含めるドメインの拡張

構成ウィザードの起動

既存のエンタープライズ・デプロイメント・ドメインを拡張するための最初のステップとして構成ウィザードを起動します。

注意:

ドメインで起動スクリプトに直接カスタマイズを追加した場合、それらは構成ウィザードによって上書きされます。ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverridesLate.shという名前のファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のJavaコマンド行オプションの指定、追加の環境変数の指定などを実施するように構成できます。このファイルに追加したカスタマイズは、ドメインのアップグレード操作時に保持され、packコマンドとunpackコマンドの使用時にリモート・サーバーに継承されます。

このエンタープライズ・デプロイメント・ガイドでのsetUserOverridesLateスクリプトの使用の詳細は、「setUserOverridesLateスクリプトを使用したサーバー・パラメータのカスタマイズ」を参照してください。

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

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

親トピック: Oracle SOA Suiteを含めるエンタープライズ・デプロイメント・ドメインの拡張

Oracle SOA Suiteを含めるドメイン拡張を行うための構成ウィザード画面のナビゲート

次の各項に示す手順に従って、静的または動的クラスタを含むOracle SOA Suiteのドメインを拡張します。

親トピック: Oracle SOA Suiteを含めるエンタープライズ・デプロイメント・ドメインの拡張

静的クラスタを含めるドメインの拡張

この項に示す手順に従って、静的クラスタを含めてOracle SOA Suiteのドメインを拡張します。

注意:

この手順では、既存のドメインを拡張することを想定しています。手順に示された内容と要件があわないときは、適切な内容を選択していることを確認するか、その他の詳細について説明されているドキュメントを参照してください。

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

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

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

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。

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

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

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

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

  • Oracle SOA Suite - 12.2.1.3.0 [soa]

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

タスク3   高可用性オプションの構成

この画面は、自動サービス移行またはJDBCストアあるいはその両方を使用するクラスタを初めて作成するときに表示されます。クラスタに対してHAオプションを選択した後、構成ウィザードを使用してドメインに追加される後続のすべてのクラスタで、HAオプションが自動的に適用されます(つまり、構成ウィザードにより、JDBCストアが作成され、これらに対してASMが構成されます)。

「高可用性のオプション」画面で、次を実行します。

  • 「データベース・ベース」を使用して「自動サービス移行の有効化」を選択します。

  • 「JTAトランザクション・ログ永続性」を「JDBC TLogストア」に設定します。

  • 「JMSサーバー永続性」を「JMS JDBCストア」に設定します。

注意:

Oracleデータベースの一貫性、データ保護および高可用性機能を活用し、クラスタ内のすべてのサーバーによるリソースの使用を可能にする、JDBCストアを使用することをお薦めします。このため、構成ウィザードのステップでは、JDBC永続ストアが自動サービス移行とともに使用されていることを前提としています。

JDBC永続ストアを選択すると、余分な未使用のファイル・ストアが自動的に作成されますが、クラスタをターゲットとしたものではありません。こうしたファイル・ストアは無視してください。

なんらかの理由でファイル・ストアを使用する場合、この画面ではTLOGおよびJMS永続ストアのオプションをデフォルト値のままにしておき、後から共有の場所で構成することができます。「タスク9「詳細構成の選択」」を参照してください。フェイルオーバー・シナリオでJMSおよびJTAを再開するには、共有の場所が必要です。

事後ステップでTLOGおよびJMS永続ストアを手動で構成することもできます。JDBCとファイル・ストアの間の差異の詳細、およびこれらの手動構成の特定の手順は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対する永続ストアの使用」を参照してください。

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

タスク4   データベース構成タイプの指定

「データベース構成タイプ」画面で、「RCUデータ」を選択します。

インフラストラクチャ・ドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。「RCUデータ」画面で次の手順を実行します。

  • 「ベンダー」がOracle、「ドライバ」が*Oracle's Driver (Thin) for Service Connections; Versions: Anyであることを確認します。

  • 「接続パラメータ」が選択されていることを確認します。

  • すべてのフィールドにおける資格証明が、Oracle Fusion Middleware Infrastructureの構成中に指定したものと同じであることを確認します。

データベース接続情報の確認が完了した後で、「RCU構成の取得」をクリックします。「接続結果ログ」の次の出力は、操作が成功したことを示します。 

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

ヒント:

「RCUデータ」オプションの詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解 に関する項を参照してください。

この画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のデータ・ソース・デフォルトに関する項を参照してください。

タスク5   JDBCコンポーネント・スキーマ情報の指定

「JDBCコンポーネント・スキーマ」画面で、表にあるSOAスキーマをすべて選択します。

スキーマを選択すると、ページ上のフィールドがアクティブ化され、データベース接続フィールドに自動的に値が移入されます。

「GridLinkへ変換」をクリックして、「次へ」をクリックします。

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

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

要素 説明と推奨値

「SCAN」、「ホスト名」および「ポート」

「SCAN」チェック・ボックスを選択します。

「ホスト名」フィールドには、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

「ポート」フィールドには、データベースのリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。

「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

これらの値は、Oracle 11gデータベースに接続する際には必須で、Oracleデータベース・リリース12c以上に接続する場合はオプションです。Oracle 12cデータベースを使用している場合、ONSリストはデータベースからドライバに自動的に提供されます。

FANの有効化

「FANの有効化」チェック・ボックスが選択され、データベースがFANイベントを受信および処理できることを確認します。

タスク7   JDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

この画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のコンポーネント・スキーマのテスト関する項を参照してください。

タスク8   キーストア

この画面を使用して、ドメインで使用されるキーストアの詳細を指定します。

標準的なエンタープライズ・デプロイメントの場合、デフォルト値をそのまま使用できます。

詳細は、構成ウィザードによるWebLogicドメインの作成のキーストアを参照してください。

タスク9   拡張構成の選択

トポロジのドメイン構成を完了するには、「拡張構成」画面で「トポロジ」を選択します。

注意:

推奨はJDBCストアで、タスク3「高可用性オプションの選択」でも選択されるので、「ファイル・ストア」を構成する必要はありません。

タスク3「高可用性オプションの選択」で「ファイル・ストア」を選択した場合は、ここで「ファイル・ストア」オプションを選択し、ORACLE_RUNTIME/domain_name/SOA_Cluster/jmsの共有場所でそれを構成する必要があります。フェイルオーバー・シナリオでJMSおよびJTAを再開するには、共有の場所が必要です。

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

「管理対象サーバー」画面で、サーバーのリストにOracle SOA Suite用の新しい管理対象サーバーが表示されます。このサーバーは、タスク2「構成テンプレートの選択」で選択したOracle SOA Suite構成テンプレートによって自動的に作成されています。

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

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

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

    ヒント:

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

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

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

サーバー名 リスニング・アドレス リスニング・ポート SSLの有効化 SSLリスニング・ポート サーバー・グループ

WLS_SOA1

WCCHOST1

8001

いいえ

無効

SOA-MGD-SVRS-ONLY

WLS_SOA2

WCCHOST2

8001

いいえ

無効

SOA-MGD-SVRS-ONLY

タスク11   クラスタの構成

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

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

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

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

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

注意:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Coherenceライセンス情報については、『Oracle Fusion Middlewareライセンス情報ユーザー・マニュアル』のOracle Coherence製品に関する項を参照してください。

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

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

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

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

WLS_SOA1をWCCHOST1、WLS_SOA2をWCCHOST2に割り当てます。

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

タスク18   仮想ターゲットの構成

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

タスク19   パーティションの構成

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

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

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

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

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

終了したら、「構成の進行状況」画面で「次へ」をクリックします。

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

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

「構成に成功しました」画面には、構成したドメインに関する次のような項目が表示されます。

  • ドメインの場所

  • 管理サーバーURL

どちらの項目も後で必要になるためメモしてください。ドメインの場所は、管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、管理サーバーのURLはWebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlへのアクセスで必要になります。

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

ドメイン拡張プロセスの間に管理サーバーを実行していた場合は、続行する前にサーバーを再起動します。

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

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

静的クラスタを含めるドメインの拡張が完了したら、「手動でのアダプタのターゲット指定」に進みます。

動的クラスタを含めるドメインの拡張

この項に示す手順に従って、動的クラスタを含めてOracle SOA Suiteのドメインを拡張します。

注意:

この手順では、既存のドメインを拡張することを想定しています。手順に示された内容と要件があわないときは、適切な内容を選択していることを確認するか、その他の詳細について説明されているドキュメントを参照してください。

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

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

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

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

MSERVER_HOME変数の値は入力しないでください。これは、管理対象サーバー・ドメイン・ディレクトリの場所を表します。

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

ヒント:

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

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

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

  • Oracle SOA Suite - 12.2.1.3.0 [soa]

ヒント:

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

タスク3   データベース構成タイプの指定

「データベース構成タイプ」画面で、「RCUデータ」を選択します。

インフラストラクチャ・ドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。「RCUデータ」画面で次の手順を実行します。

  • 「ベンダー」がOracle、「ドライバ」が*Oracle's Driver (Thin) for Service Connections; Versions: Anyであることを確認します。

  • 「接続パラメータ」が選択されていることを確認します。

  • すべてのフィールドにおける資格証明が、Oracle Fusion Middleware Infrastructureの構成中に指定したものと同じであることを確認します。

データベース接続情報の確認が完了した後で、「RCU構成の取得」をクリックします。「接続結果ログ」の次の出力は、操作が成功したことを示します。 

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

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

ヒント:

「RCUデータ」オプションの詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解 に関する項を参照してください。

この画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のデータ・ソース・デフォルトに関する項を参照してください。

タスク4   JDBCコンポーネント・スキーマ情報の指定

「JDBCコンポーネント・スキーマ」画面で、表にあるSOAスキーマをすべて選択します。

スキーマを選択すると、ページ上のフィールドがアクティブ化され、データベース接続フィールドに自動的に値が移入されます。

「GridLinkへ変換」をクリックし、「次へ」をクリックします。

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

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

要素 説明と推奨値

「SCAN」、「ホスト名」および「ポート」

「SCAN」チェック・ボックスを選択します。

「ホスト名」フィールドには、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

「ポート」フィールドには、データベースのリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。

「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

これらの値は、Oracle 11gデータベースに接続する際には必須で、Oracleデータベース・リリース12c以上に接続する場合はオプションです。Oracle 12cデータベースを使用している場合、ONSリストはデータベースからドライバに自動的に提供されます。

FANの有効化

「FANの有効化」チェック・ボックスが選択され、データベースがFANイベントを受信および処理できることを確認します。

タスク6   JDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

ヒント:

この画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のコンポーネント・スキーマのテスト関する項を参照してください。

タスク7   キーストア

この画面を使用して、ドメインで使用されるキーストアの詳細を指定します。

標準的なエンタープライズ・デプロイメントの場合、デフォルト値をそのまま使用できます。

詳細は、構成ウィザードによるWebLogicドメインの作成のキーストアを参照してください。

タスク8   拡張構成の選択

トポロジのドメイン構成を完了するには、「拡張構成」画面で「トポロジ」を選択します。

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

「管理対象サーバー」画面で、サーバーのリストにOracle SOA Suite用の新しい管理対象サーバーが表示されます。このサーバーは、タスク2「構成テンプレートの選択」で選択したOracle SOA Suite構成テンプレートによって自動的に作成されています。

動的クラスタ構成には、SOA静的管理対象サーバーの定義は必要ありません。デフォルトの管理対象サーバーを削除するには、次のステップを実行します。

  1. soa_server1管理対象サーバーをクリックして、「削除」をクリックします。

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

タスク10   クラスタの構成

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

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

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

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

  3. 「動的サーバー・グループ」ドロップダウン・リストで、SOA-DYN-CLUSTER-ONLYを選択します。

注意:

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

ヒント:

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

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

テンプレートを構成するには、次のステップを実行します。

  1. 「名前」フィールドでsoa-server-templateが選択されていることを確認します。

  2. 「リスニング・ポート」フィールドで、8000を指定します。

  3. 「SSLの有効化」オプションは未選択のままにしておきます。

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

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

「動的クラスタ」画面を使用して、必要なクラスタを構成します。

  1. 「クラスタ名」フィールドにSOA_Clusterがリストされていることを確認します。

  2. 「サーバー名の接頭辞」フィールドで、WLS_SOAを指定します。

  3. 「サーバー・テンプレート」ドロップダウン・リストで、soa-server-templateを選択します。

  4. 「動的クラスタ・サイズ」フィールドに2を指定します。

  5. 「マシン名マッチング式」フィールドで、WCCHOST*を指定し、「計算済マシン名」を選択します。

    注意:

    動的クラスタの「計算済マシン名」および「マシン名マッチング式」属性は、動的クラスタ内のサーバー・インスタンスをマシンに割り当てる方法を制御します。「計算済マシン名」属性がFalseに設定されている場合、動的サーバーはマシンに割り当てられません。「計算済マシン名」属性がTrueに設定されている場合、「マシン名マッチング式」属性が使用され、動的サーバーに使用されるマシンのセットが選択されます。「マシン名マッチング式」属性が設定されていない場合、ドメイン内のすべてのマシンが選択されます。割当は、ラウンド・ロビン・アルゴリズムを使用して行われます。

    実際の物理的なホスト名とは関係なく作業をより簡単にするために、WebLogicマシン名としてWCCHOSTn (nは連続番号です)を使用することをお薦めします。これについては、インフラストラクチャ・ドメインの構成に関するタスク18「マシンの作成」で説明しています。この規則により、動的クラスタが各クラスタ・メンバーをどこから起動するかを決定しやすくなります。この規則に従う場合は、「マシン・マッチング式」フィールドに「WCCHOST*」と入力します。

    この規則に従わない場合、クラスタ・メンバーはタスク18「マシンの作成」で定義する各マシンで起動します。これには、ADMINHOSTも含まれます。この状況は、2つのクラスタ・メンバーが同じ物理サーバー上で動作するが2つの異なるドメイン・ホームにアタッチされる結果となるため、望ましくありません。

  6. 「計算済リスニング・ポート」 フィールドと「動的クラスタ」フィールドを選択します。

    注意:

    「計算済リスニング・ポート」オプションが選択された動的クラスタの場合、自動的に作成される動的管理対象サーバーごとに増分ポート番号が使用されます。つまり、動的サーバー1にはリスニング・ポート+1、動的サーバー2にはリスニング・ポート+2が使用されます。

    構成されたリスニング・ポートが8000で、計算済のポートが選択されているので、SOA動的サーバーは次のポート番号を使用します。

    • WLS_SOA1サーバーは、ポート8001でリスニングします

    • WLS_SOA2サーバーは、ポート8002でリスニングします

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

注意:

構成ウィザードで、動的サーバーに対して特定のリスニング・アドレスを指定することはできません。動的クラスタのメンバーであるWebLogicサーバーへの特定リスニング・アドレスの設定については、「動的クラスタ・サーバー・テンプレートでのリスニング・アドレスの構成」を参照してください。

タスク13   クラスタへのサーバーの割当て

この画面は、現在の拡張に新しい静的サーバーが含まれていない場合でも、静的な構成済クラスタと管理対象サーバーが存在するときには、動的クラスタの構成中に表示されます。

動的クラスタによるSOAの拡張の際には、変更する必要はありません。

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

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

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

注意:

Coherenceライセンス情報については、『Oracle Fusion Middlewareライセンス情報ユーザー・マニュアル』のOracle Coherence製品に関する項を参照してください。

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

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

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

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

タスク17   仮想ターゲット

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

タスク18   パーティション

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

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

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

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

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

終了したら、「構成の進行状況」画面で「次へ」をクリックします。

ヒント:

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

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

「構成に成功しました」画面には、構成したドメインに関する次のような項目が表示されます。

  • ドメインの場所

  • 管理サーバーURL

どちらの項目も後で必要になるためメモしてください。ドメインの場所は、管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、管理サーバーのURLはWebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlへのアクセスで必要になります。

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

ドメイン拡張プロセスの間に管理サーバーを実行していた場合は、続行する前にサーバーを再起動します。

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

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

手動でのアダプタのターゲット指定

構成ウィザードの実行後は、コア・アダプタのみがSOAクラスタにターゲット指定されます。必要ベースで、二義的なアダプタも手動でターゲット指定する必要があります。

次に示す二義的なアダプタは手動でターゲット設定する必要があります。

注意:

これらのアダプタの一部は、デフォルトのインストールでは使用できないことがあります。使用可能なアダプタについてはOracle Technology Networkを参照してください。

  • MSMQAdapter

  • SocketAdapter

  • OracleBamAdapter

  • CoherenceAdapter

  • SAPAdapter

  • SiebelAdapter

  • ERPAdapter

  • Oracle SalesCloudAdapter

  • RightNowAdapter

  • EloquaAdapter

  • NetSuiteAdapter

  • LdapAdapter

  • JDEWorldAdapter

二義的なアダプタを手動でターゲット指定するには:

  1. Oracle WebLogic Server管理コンソールに移動してログインします。例: http://ADMINVHN:7001/console.

    注意:

    Web層がすでに構成されている場合は、http://admin.example.com/consoleを使用します。

  2. 管理コンソールの左ペインで、「デプロイメント」をクリックします。
  3. 「デプロイメント」表の「サマリー」で、アダプタの名前を見つけてクリックします。
  4. 「ロックして編集」をクリックします。
  5. 「ターゲット」タブで、SOA_Clusterを選択します。

    注意:

    MFTをデプロイする場合は、ターゲットとしてMFT_Clusterを選択します。

  6. 「保存」をクリックします。
  7. 変更をアクティブ化します。
  8. コンソールの左ペインで「デプロイメント」をクリックし、アダプタが「アクティブ」状態であることを確認します。

親トピック: Oracle SOA Suiteを含めるエンタープライズ・デプロイメント・ドメインの拡張

ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

Oracle WebCenter Portalインスタンスを含めることでドメインを拡張し、WCPHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリとマシンに伝播する必要があります。

表14-1は、変更をすべてのドメイン・ディレクトリとマシンに伝播するために必要なステップをまとめたものです。

更新済ドメインをWEBHOST1およびWEBHOST2マシンに伝播する必要はありません。それらのホスト・コンピュータ上のOracle HTTP Serverインスタンスに対する変更はないためです。

表14-1 ドメイン変更をドメイン・ディレクトリおよびマシンに伝播するために必要なタスクのサマリー

タスク 説明 詳細情報

WCPHOST1での拡張済ドメインの圧縮

packコマンドを使用して、新しいOracle SOA Suite管理対象サーバー構成が含まれる新しいテンプレートJARファイルを作成します。

ドメインを圧縮する際には、wcpdomaintemplateExtSOA.jarというテンプレートJARファイルを作成します。

WCPHOST1での拡張済ドメインの圧縮

WCPHOST1の管理対象サーバー・ディレクトリでのドメインの解凍

WCPHOST1のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。

WCPHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍

WCPHOST2でのドメインの解凍

WCCHOST1およびWCCHOST2でのドメインの解凍

WCPHOST2のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。

後で、WCCHOST1およびWCCHOST2のローカル記憶域上の管理対象サービス・ディレクトリにJARファイルを解凍します。

WCPHOST2でのドメインの解凍

親トピック: Oracle SOA Suiteを含めるドメインの拡張

WCCHOST1での拡張済ドメインの圧縮

次のステップを使用して、ドメイン構成情報が含まれるテンプレートJARファイルを作成します。

  1. WCCHOST1にログインし、次のようにpackコマンドを実行してテンプレートJARファイルを作成します。
    cd ORACLE_COMMON_HOME/common/bin
 
./pack.sh -managed=true \ 
          -domain=ASERVER_HOME \ 
          -template=full_path/wcpdomaintemplateExtSOA.jar \
          -template_name=wcp_domain_template_extension_soa \
	  -log=/tmp/pack_soa.log \
	  -log_priority=debug

    この例では、次のようになります。

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

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

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

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

  2. packコマンドで作成したテンプレートJARファイルの場所を書き留めます。

    ヒント:

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

親トピック: ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

WCCHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍

更新したドメイン構成情報を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播する手順は次のとおりです。

  1. WCCHOST1にログインしていない場合は、ログインします。
  2. まだ作成していない場合は、WCCHOST1のローカル記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。
  3. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。
    cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME \
    -overwrite_domain=true \
    -template=/full_path/wcpdomaintemplateExtSOA.jar \
    -log_priority=DEBUG \
    -log=/tmp/unpack.log \
    -app_dir=APPLICATION_HOME

    注意:

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

    また、ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverridesLate.shという名前のファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のJavaコマンド行オプションの指定、追加の環境変数の指定などを実施するように構成できます。このファイルに追加されたカスタマイズは、ドメインのアップグレード操作中も保持され、packおよびunpackコマンドの使用時にはリモート・サーバーに継承されます。

    この例では、次のようになります。

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

    • /full_path/wcpdomaintemplateExtSOA.jarを、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したドメイン・テンプレートJARファイルの完全なパスとファイル名に置き換えます。

    • APPLICATION_HOMEを、共有記憶域上のそのドメインのapplicationsディレクトリの完全なパスに置き換えます。「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください

    ヒント:

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

  4. ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがWCCHOST1のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

親トピック: ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

WCPHOST2でのドメインの解凍

この手順では、以前に作成したファイルを、アプリケーション層の各ホストからアクセスできる場所(各ホストに対してローカルな場所であるか共有記憶域上の場所であるかにかかわらず)にコピーしていることを前提としています。

  1. WCCHOST2にログインします。

  2. まだ作成していない場合は、WCCHOST2の記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。

    「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。

  3. create_domain.jarが、WCCHOST2からアクセス可能であることを確認します。

    たとえば、WCCHOST2のために別の共有記憶域ボリュームまたはパーティションを使用している場合は、WCCHOST2にマウントされているボリュームまたはパーティションにテンプレートをコピーします。

  4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。 

    cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME \
            -overwrite_domain=true \
            -template=/full_path/create_domain.jar \ 
            -log_priority=DEBUG \
            -log=/tmp/unpack.log \
            -app_dir=APPLICATION_HOME

    注意:

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

    また、ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverridesLate.shという名前のファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のJavaコマンド行オプションの指定、追加の環境変数の指定などを実施するように構成できます。このファイルに追加されたカスタマイズは、ドメインのアップグレード操作中も保持され、packおよびunpackコマンドの使用時にはリモート・サーバーに継承されます。

    この例では、次のようになります。

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

    • /full_path/create_domain.jarを、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したドメイン・テンプレートJARファイルの完全なパスとファイル名に置き換えます。

    • APPLICATION_HOMEを、共有記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

    ヒント:

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

  5. ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがWCCHOST2のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

  6. WCPHOST1およびWCPHOST2に対してこの手順を繰り返します。

親トピック: ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

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

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

注意:

各ホストのMSERVER_HOME/nodemanager/nodemanager.propertiesファイルについて、次のことを実行します。
  1. 正しいListenAddressパラメータ値を確認して、必要な場合は値を再設定します。
    grep ListenAddress MSERVER_HOME/nodemanager/nodemanager.properties
  2. 次のコマンドの参照として、ドメイン構成ファイルから構成済アイデンティティ別名のリストを確認します。
    grep server-private-key-alias ASERVER_HOME/config/config.xml | sort | uniq

    注意:

    動的クラスタの使用時には、このリストにADMINVHNとワイルドカードの証明書アイデンティティ別名のみが表示されます。

    次の手順でnodemanger.properties CustomIdentityAliasプロパティを更新するときには、適切なホスト固有の証明書アイデンティティ別名を使用してください。

  3. 現在のnodemanager.properties CustomIdentityAliasパラメータの値がホストの別名と一致していることを確認します。
    grep CustomIdentityAlias MSERVER_HOME/nodemanager/nodemanager.properties
  4. 必要に応じて、CustomIdentityAliasパラメータ値を、現在のホストに適した正しい別名文字列に再設定します。
  5. nodemanagerプロセスを再起動します。
    kill `ps -eaf | grep weblogic.NodeManager | grep MSERVER_HOME | grep -v grep | awk '{print $2}' `
nohup MSERVER_HOME/bin/startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

注意:

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

親トピック: Oracle SOA Suiteを含めるドメインの拡張

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

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

ドメインが拡張され、すべてのサーバーのMSERVER_HOMEディレクトリに解凍されたので、既存のコンポーネントの管理対象サーバーを再起動します。
  1. WebLogic Serverコンソールから、WebServices Manager Policy ManagerのWLS_WSMn管理対象サーバーを再起動します。
  2. 別のブラウザ・ウィンドウから、URLを正常にロードすることで、WSM-PMアプリケーションが応答していることを確認します。
    http://wcpinternal.example.com/wsm-pm/validator
  3. 必要に応じてその他の既存の管理対象サーバーを再起動します。他の製品機能は、この段階では不要です。

親トピック: Oracle SOA Suiteを含めるドメインの拡張

エンタープライズ・デプロイメントでのuploadおよびstageディレクトリの絶対パスへの変更

ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。また、AdminServerのアップロード・ディレクトリを、相対パスではなく、同じ絶対パスを持つように更新します。そうしないと、デプロイメントの問題が発生する可能性があります。動的クラスタを実装する場合、新しく追加した各クラスタに割り当てられたサーバー・テンプレートの構成を検証および更新する必要があります。そうでない場合、新しく追加したクラスタの静的に定義された各管理対象サーバーを検証および構成します。

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

デプロイメント・ステージおよびアップロードの場所のディレクトリ・パスを更新するには、次のステップを実行します。

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

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

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

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

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

    2. 動的クラスタの場合、「クラスタ」→「サーバー・テンプレート」に移動し、編集するサーバー・テンプレートの名前をクリックします。

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

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

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

      MSERVER_HOME/servers/server_or_template_name/stage

      MSERVER_HOMEを MSERVER_HOMEディレクトリのフルパスに置き換えます。

      静的クラスタを使用する場合、編集対象の管理対象サーバーの正しい名前を使用して更新します。

      動的クラスタを使用する場合、テンプレート名はそのままにしておきます。例: /u02/oracle/config/domains/wcpedg_domain/servers/XYZ-server-template/stage

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

      ASERVER_HOME/servers/AdminServer/upload

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

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

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

  6. 新しい管理対象サーバーまたは動的クラスタ・サーバー・テンプレートごとに前のステップを繰り返します。

  7. AdminServerの「アップロード・ディレクトリ名」に移動して、その値を更新します。

    1. 「サーバー」に移動してAdminServerを選択します。

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

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

      ASERVER_HOME/servers/AdminServer/stage

    4. 「アップロード・ディレクトリ名」を次の絶対パスに更新します。

      ASERVER_HOME/servers/AdminServer/upload

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

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

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

注意:

これ以上のドメイン構成を直接続行する場合、この時点ではstageおよびuploadディレクトリの変更を有効にするための再起動は厳密には必要ありません。

親トピック: Oracle SOA Suiteを含めるドメインの拡張

動的クラスタを使用する際のリスニング・アドレスの構成

動的クラスタにおける動的な管理対象サーバーのデフォルト構成では、使用可能なネットワーク・インタフェースすべてでリスニングするようになっています。ほとんどの場合、デフォルトの構成は望ましくありません。動的クラスタを使用する際に、リスニング・アドレスを特定のアドレスに限定するには、「動的クラスタ・サーバー・テンプレートでのリスニング・アドレスの構成」を参照してください。リスニング・アドレスを変更した後に前の項で指定したテストURLを再確認し、クラスタ化された管理対象サーバーを再起動します。

親トピック: Oracle SOA Suiteを含めるドメインの拡張

WLS_SOA1管理対象サーバーの起動および検証

これでドメインの拡張、管理サーバーの起動、およびドメインの他のホストへの伝播を完了したので、新しく構成したOracle SOA Suite管理対象サーバーを起動できます。

このプロセスには、次の各項で説明する3つのタスクが含まれます。

親トピック: Oracle SOA Suiteを含めるドメインの拡張

管理対象サーバーWLS_SOA1の起動

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

  1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。
    http://ADMINVHN:7001/em

    注意:

    Web層がすでに構成されている場合は、http://admin.example.com/consoleを使用します。

  2. 管理者のアカウントを使用してFusion Middleware Controlにサインインします。例: weblogic_wcp
  3. 「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。
  4. WLS_SOA1管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。

    注意:

    SOAサーバーは、ポリシー・アクセス・サービスに依存して機能します。これは、SOAサーバーが起動する前に、ドメイン内のWSM-PM管理対象サーバーが稼働していてアクセス可能になっている必要があることを意味します。

  5. 起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_SOA1管理対象サーバーが稼働中であることを確認します。

親トピック: WLS_SOA1管理対象サーバーの起動および検証

AdministratorsグループへのSOAAdminロールの追加

WLS_SOA1管理対象サーバーのOracle SOA Suite構成を検証する前に、SOAAdmin管理ロールをエンタープライズ・デプロイメント管理グループ(WCPAdministrators)に追加します。

このタスクを実行するには、「エンタープライズ・デプロイメントの管理用のロールの構成」を参照してください。

親トピック: WLS_SOA1管理対象サーバーの起動および検証

SOAインフラストラクチャへのログインによる管理対象サーバーの検証

SOAAdminロールをSOA Administratorsグループに追加した後、次のようにWLS_SOA1管理対象サーバーのOracle SOA Suiteソフトウェアの構成を検証できます。

  1. Webブラウザを使用して次のURLに移動します。
    http://WCCHOST1:8001/soa-infra/
  2. エンタープライズ・デプロイメント管理者ユーザー資格証明(weblogic_wcp)を使用してログインします。

    次のようなタイトルのWebページが表示されます。

    Welcome to the Oracle SOA Platform on WebLogic

親トピック: WLS_SOA1管理対象サーバーの起動および検証

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

WLS_SOA1管理対象サーバーの正常な構成と起動を検証したら、WLS_SOA2管理対象サーバーを起動して検証できます。

WLS_SOA2管理対象サーバーを起動して検証するには、WLS_SOA2管理対象サーバーに対して「WLS_SOA1管理対象サーバーの起動および検証」の手順を使用します。

URLを検証するために、Webブラウザに次のURLを入力し、エンタープライズ・デプロイメント管理者ユーザー(weblogic_wcp)を使用してログインします。

静的クラスタの場合:
http://WCCHOST2:8001/soa-infra/
動的クラスタの場合:
http://WCCHOST2:8002/soa-infra/

親トピック: Oracle SOA Suiteを含めるドメインの拡張

拡張したドメイン用のOracle HTTP Serverの構成

次の項では、パブリックURLおよび内部URLの両方のリクエストを、エンタープライズ・トポロジ内の正しクラスタにルーティングするようにOracle HTTP Serverインスタンスを構成する方法について説明します。

親トピック: Oracle SOA Suiteを含めるドメインの拡張

Oracle WebCenter Portalエンタープライズ・デプロイメントにおけるSOAのためのOracle HTTP Serverの構成

ワークフロー機能のためにSOAをWebCenter Portalと統合する場合、SOA Suiteリソースへの内部アクセスとエンドユーザー・アクセスの両方を構成する必要があります。

次の手順を使用して、リクエストをOracle SOA Suiteクラスタに正しくルーティングするようにWeb層のOracle HTTP Serverインスタンスを構成します。この手順では、「アプリケーション層にリクエストをルーティングするためのOracle HTTP Serverの構成」で説明されているOracle HTTP Server構成タスクが実行済であることを想定しています。

リクエストがOracle SOA Suiteクラスタに正しくルーティングされるように仮想ホスト構成ファイルを構成します。

  1. WEBHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(ohs1)の構成ディレクトリに変更します。
    cd WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/
  2. wcpinternal_vh.confファイルを編集し、次のディレクティブを<VirtualHost>タグ内に追加します。

    注意:

    • /workflowのURLエントリは省略可能です。これは、Oracle ADFタスク・フォームと関連付けられたワークフロー・タスク用です。/workflowのURL自体は、フォームに応じた別の値とすることができます。

    • 静的または動的クラスタに割り当てられているとおり適切にポート番号を構成します。「計算済リスニング・ポート」オプションが選択された動的クラスタの場合、作成される動的管理対象サーバーごとに増分ポート番号が使用されます。

    • 一部停止が発生した場合に初期接続を保証するためにWebLogicClusterディレクティブに必要なのは、十分な数の冗長なserver:portの組合せのみです。クラスタ・メンバーの実際の合計リストは、任意のノードとの初回の接続時に自動的に取得されます。 

    # soa-infra
<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# Worklist
<Location /integration>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# Workflow
<Location /workflow>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

#Required if attachments are added for workflow tasks
 <Location /ADFAttachmentHelper> 
    WLSRequest ON 
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001 
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# SOA composer application 
 <Location /soa/composer> 
    WLSRequest ON 
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001 
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

 <Location /frevvo> 
    WLSRequest ON 
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001 
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>
</VirtualHost>
  3. wcp_vh.confファイルを編集し、次のディレクティブを<VirtualHost>タグ内に追加します。

    注意:

    • /workflowのURLエントリは省略可能です。これは、Oracle ADFタスク・フォームと関連付けられたワークフロー・タスク用です。/workflowのURL自体は、フォームに応じた別の値とすることができます。

    • 静的または動的クラスタに割り当てられているとおり適切にポート番号を構成します。「計算済リスニング・ポート」オプションが選択された動的クラスタの場合、作成される動的管理対象サーバーごとに増分ポート番号が使用されます。

    • 一部停止が発生した場合に初期接続を保証するためにWebLogicClusterディレクティブに必要なのは、十分な数の冗長なserver:portの組合せのみです。クラスタ・メンバーの実際の合計リストは、任意のノードとの初回の接続時に自動的に取得されます。 

    # soa-infra
<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# Worklist
<Location /integration>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# Workflow
<Location /workflow>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

#Required if attachments are added for workflow tasks
 <Location /ADFAttachmentHelper> 
    WLSRequest ON 
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001 
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# SOA composer application 
 <Location /soa/composer> 
    WLSRequest ON 
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001 
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

 <Location /frevvo> 
    WLSRequest ON 
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001 
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>
</VirtualHost>
  4. wcpinternal_vh.confファイルおよびwcp_vh.confファイルを、2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします。
    WEB_DOMAIN_HOME/config/fmwconfig/components/ohs2/moduleconf/
  5. wcpinternal_vh.confおよびwcp_vh.confを編集して、<VirtualHost>ディレクティブ内のWEBHOST1への参照をWEBHOST2への参照に変更します。
  6. 両方のOracle HTTP Serverを再起動します。

例14-1 wcpinternal_vh.confファイルの内容の例

注意:

次のサンプル構成ファイルの内容には、SOA SuiteおよびOracle WebServices Managerのリソースのみが含まれます。これまでの章で構成してきた他の製品のリソースは、ここには表示されません。 
<VirtualHost WEBHOST1:7777>
    ServerName http://wcpinternal.example.com:80
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit

# WSM-PM 
<Location /wsm-pm>
     WebLogicCluster WCPHOST1:7010,WCPHOST2:7010
     WLSRequest ON
     WLProxySSL OFF
     WLProxySSLPassThrough OFF
</Location>

#soa-infra
<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# Worklist
<Location /integration>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# Workflow
<Location /workflow>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

#Required if attachments are added for workflow tasks
 <Location /ADFAttachmentHelper> 
    WLSRequest ON 
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001 
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# SOA composer application 
 <Location /soa/composer> 
    WLSRequest ON 
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001 
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

 <Location /frevvo> 
    WLSRequest ON 
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001 
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>
</VirtualHost>

例14-2 wcp_vh.confファイルの内容の例 

<VirtualHost WEBHOST1:7777>
    ServerName http://wcp.example.com:443
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit

# WSM-PM 
<Location /wsm-pm>
     WebLogicCluster WCPHOST1:7010,WCPHOST2:7010
     WLSRequest ON
     WLProxySSL ON
     WLProxySSLPassThrough ON
</Location>

#soa-infra
<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# Worklist
<Location /integration>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# Workflow
<Location /workflow>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

#Required if attachments are added for workflow tasks
 <Location /ADFAttachmentHelper> 
    WLSRequest ON 
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001 
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# SOA composer application 
 <Location /soa/composer> 
    WLSRequest ON 
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001 
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

 <Location /frevvo> 
    WLSRequest ON 
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001 
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>
</VirtualHost>

親トピック: 拡張したドメイン用のOracle HTTP Serverの構成

ロード・バランサを使用したOracle SOA Suite URLの検証

Oracle HTTP Server仮想ホストの構成を検証し、ハードウェア・ロード・バランサがOracle HTTP Serverインスタンスを経由してアプリケーション層にリクエストをルーティングできることを確認する手順は次のとおりです。

  1. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。

    サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。

  2. 次のURLにアクセスできることを確認します。

    • https://wcp.example.com:443/soa-infra

    • https://wcp.example.com:443/integration/worklistapp

    • https://wcp.example.com:443/sdpmessaging/userprefs-ui

    • https://wcp.example.com:443/soa/composer

親トピック: 拡張したドメイン用のOracle HTTP Serverの構成

Oracle SOA Suiteの構成後ステップ

Oracle SOA Suiteをインストールして構成した後、次のような構成後タスクを検討します。

親トピック: Oracle SOA Suiteを含めるドメインの拡張

Oracle SOA Suite用のOracleアダプタの構成

開発しているOracle SOA Suiteアプリケーションで、Oracle SOA Suite用のOracleアダプタのいずれかを利用する場合は、それらのアダプタがエンタープライズ・トポロジで効率的かつセキュアに機能するように構成されていることを確認する必要があります。

詳細は、次の各項を参照してください。

親トピック: Oracle SOA Suiteの構成後ステップ

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

開発またはデプロイするOracle SOA Suiteアプリケーションで、OracleファイルおよびFTPアダプタが必要な場合は、エンタープライズ・デプロイメント・トポロジで高可用性が得られるようにそれらのアダプタを構成する必要があります。

次の各項を使用してこのタスクを完了します。

OracleファイルおよびFTPアダプタ構成の理解

OracleファイルおよびFTPアダプタを使用すると、プライベート・ファイル・システムやリモート・ファイル・システムのファイルをFTP(ファイル転送プロトコル)を使用してBPELプロセスまたはOracle Mediatorで読取りまたは書込みできるようになります。

適切に構成した場合、これらのアダプタは、Oracle BPEL Process ManagerおよびOracle Mediatorサービス・エンジンでのアクティブ/アクティブ・トポロジに対する高可用性機能を、インバウンドおよびアウトバウンドの両方の操作でサポートします。

このタスクの一般情報は、テクノロジ・アダプタの理解のOracleファイルおよびFTPアダプタの構成に関する項を参照してください。ここで説明する手順は、Oracle SOA Suiteエンタープライズ・デプロイメントに固有のものです。

注意:

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

管理コンソールでのOracleファイル・アダプタの構成

Oracleファイル・アダプタの高可用性を実現するには、最初に、eis/HAFileAdapterに対応する接続インスタンスのOracleファイル・アダプタのデプロイメント・ディスクリプタを変更します。

このタスクは、Oracle WebLogic Serverコンソールから実行できます。

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

    次に例を示します。

    http://ADMINVHN:7001/console

    注意:

    Web層がすでに構成されている場合は、http://admin.example.com/consoleを使用します。

  2. 管理コンソールの左ペインで、「デプロイメント」をクリックします。

  3. 「デプロイメントのサマリー」表でFileAdapterリソース・アダプタを見つけます。

  4. 「FileAdapter」をクリックし、「FileAdapterの設定」ページを表示します。

  5. 「構成」をクリックします。

  6. 「アウトバウンド接続プール」をクリックします。

  7. javax.resource.cci.ConnectionFactoryを開き、構成済の接続ファクトリを表示します。

  8. 「eis/HAFileAdapter」をクリックします。

    接続ファクトリの「アウトバウンド接続のプロパティ」が表示されます。

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

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

  10. 表14-2に示されている値を入力します。

    注意:

    controlDirを更新し、その他の値を、表14-2に示されているデフォルト値と照合します。

    表14-2 javax.resource.cci.Connectionfactoryに入力する値

    パラメータ 説明

    controlDir

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

    ORACLE_RUNTIME/domain_name/cluster_name/fadapter

    inboundDataSource

    値をjdbc/SOADataSourceに設定します。

    outboundDataSource

    値をjdbc/SOADataSourceに設定します。

    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の完全修飾クラス名の値を指定した新規バインディング・プロパティを構成する必要があります。

    workingDirectory

    このデフォルト値を保持します。

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

  12. DEPLOY_PLAN_HOMEディレクトリを作成します。

    mkdir -p DEPLOY_PLAN_HOME/wcpedg_domain

    この例では、DEPLOY_PLAN_HOMEを、「このガイドで使用するファイル・システムとディレクトリ変数」で定義されているデプロイメント・プラン・ディレクトリの実際のパスに置き換えます。

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

    DEPLOY_PLAN_HOME/wcpedg_domain/FileAdapterPlan.xml

  14. 「OK」をクリックして、記憶域の場所を削除します。

  15. 「保存」をクリックしてファイル・アダプタへの変更を保存して、「変更のアクティブ化」をクリックしてファイル・アダプタに変更を適用します。

  16. コンソールでデプロイメントを更新します。

    1. 「デプロイメント」をクリックします。

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

    3. ファイル・アダプタのデプロイメントに対応するチェック・ボックスを選択します。

    4. 「更新」をクリックします。

    5. オプションの「このアプリケーションを新しいデプロイメント・プランの変更とあわせた場所に更新します(このオプションには、デプロイメント・プランを指定する必要があります)。」を選択します。

    6. 「パスの変更」ボタンをクリックして、共有記憶域の場所へのパスからFileAdapterPlan.xmlファイルを選択します。

    7. 「終了」をクリックします。

    8. 変更をアクティブ化します。

  17. FileAdapterデプロイメントがアクティブ化されて稼働中であることを確認します。

    1. 管理コンソールの左ペインで、「デプロイメント」をクリックします。

    2. 「デプロイメント」表のFileAdapterデプロイメントを見つけます。

    3. アクティブな状態でない場合は、「デプロイメントのサマリー」の下の「制御」タブをクリックしてから、「デプロイメント」の下の「FileAdapter」をクリックします。「開始」→「すべてのリクエストを処理」を選択します。

    4. 「はい」をクリックします。

コンポジット・アプリケーション内でのJCAファイルの編集

管理コンソールでFileAdapterデプロイメントを構成したら、例14-3に示すように、デプロイするコンポジット・アプリケーションに含まれている.jcaファイルを編集し、それらが前のステップで構成した接続ファクトリを使用できるようにすることができます。

注意:

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

例14-3 エンタープライズ・デプロイメント用のファイル・アダプタ.JCAファイルの変更の例

<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>
Oracle FTPアダプタの構成

アプリケーションでFTPアダプタが必要な場合、「管理コンソールでのOracle File Adapterの構成」および「コンポジット・アプリケーション内でのJCAファイルの編集」の各手順を繰り返します(ただし、次の点が異なります)。

  • 管理コンソールのデプロイメントのリストで「FtpAdapter」デプロイメントを探します。

  • 「FtpAdapter」をクリックすると、FtpAdapterページの「設定」が表示されます。

  • 「構成」をクリックします。

  • 「アウトバウンド接続プール」をクリックします。

  • javax.resource.cci.ConnectionFactoryを開き、構成済の接続ファクトリを表示します。

  • eis/Ftp/HAFtpAdapterをクリックします。

    接続ファクトリの「アウトバウンド接続のプロパティ」が表示されます。

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

  • アダプタのプロパティを高可用性用に変更します。表14-2を参照してください。

  • 次の場所を指すように、ControlDirプロパティを更新します。

    ORACLE_RUNTIME/domain_name/cluster_name/ftpadapter
  • デプロイメント・プランの共有記憶域場所を入力します。そのディレクトリ構造は次のとおりです。
    DEPLOY_PLAN_HOME/wcpedg_domain/FtpAdapterPlan.xml
Oracle JMSアダプタの高可用性化

Oracle JMSアダプタがクラスタ内の複数のサーバーと通信する場合、アダプタの通信ファクトリのプロパティFactoryPropertiesに使用可能なサーバーがリストされている必要があります。サーバーがリストされていない場合は、ランダムな1サーバーとの接続が確立されます。そのサーバーが停止しても、追加のメッセージは処理されません。

この問題を回避するために、メンバーの静的リストを使用するかわりに、アダプタのFactoryPropertiesでクラスタ名構文を使用できます。クラスタ名構文は、次のとおりです。 

cluster:t3://cluster_name

cluster:t3://cluster_nameを使用すると、この呼び出しによって任意の時点でクラスタに存在するメンバーの完全なリストがフェッチされるため、初期サーバーへの依存性が回避され、その時点でクラスタ内の有効なすべてのメンバーが判明します。このクラスタ構文は、クラスタが同じドメイン内に存在する場合にのみ使用できる点に注意してください。

アダプタのJCA接続ファクトリを変更するには:

  1. 次のURLを使用して、Oracle WebLogic Server管理コンソールにログインします。

    http://ADMINVHN:7001/console

    注意:

    Web層がすでに構成されている場合は、http://admin.example.com/consoleを使用します。

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

  3. 右ペインの「デプロイメントのサマリー」でJmsAdapterをクリックします。

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

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

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

  7. 使用中の特定のインスタンス(例: eis/wls/Queue)をクリックします。接続ファクトリの「アウトバウンド接続のプロパティ」が開きます。

  8. FactoryPropertiesフィールドで(プロパティ値の該当するセルをクリックして)、次を入力します。セミコロンで区切ってすべてを1行に入力してください。 

    java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;
java.naming.provider.url=cluster:t3://SOA_Cluster;
java.naming.security.principal=weblogic;
java.naming.security.credentials=mypassword

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

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

    DEPLOY_PLAN_HOME/wcpedg_domain/JMSAdapterPlan.xml

  11. 「OK」をクリックして、更新した記憶域パスをコミットします。

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

  13. すべての必要な接続ファクトリごとに、ステップ7からステップ9を繰り返します。

  14. 「変更のアクティブ化」をクリックします。

  15. コンソールでデプロイメントを更新します。

    1. 「デプロイメント」をクリックします。

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

    3. JMSアダプタに対応するチェック・ボックスを選択します。

    4. 「更新」をクリックします。

    5. 「このアプリケーションを新しいデプロイメント・プランの変更とあわせた場所に更新します(このオプションには、デプロイメント・プランを指定する必要があります)。」を選択し、共有記憶域の場所に保存されたデプロイメント・プランを選択します。クラスタ内のすべてのサーバーは、このプランにアクセスできる必要があります。

    6. 「終了」をクリックします。

    7. 変更をアクティブ化します。

Oracle Databaseアダプタの高可用性の有効化

Oracle Databaseアダプタを利用しながら高可用性を確保するために、通常は、物理削除より高速な論理削除ポーリング方式が使用されます。しかし、複数のノードが同じデータをポーリングするクラスタ化環境では、1つのレコードが複数回処理されることがあります。この問題を回避するために、Oracle Databaseアダプタでは、「ロックのスキップ」と呼ばれるOracle Database機能を使用する分散ポーリング技術を使用します。

以前に論理削除ポーリング方式のアプローチを使用していた場合は、MarkReservedValueを(db.jca内で)削除するか、(ウィザードの「論理削除」ページで)消去できます。それによってロックが自動的にスキップされるようになります。

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

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

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

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

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

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

SOAサーバーとハードウェア・ロード・バランサ間のSSL通信の有効化

Oracle SOA Suiteを含めてドメインを拡張した後、管理サーバーと管理対象サーバーがハードウェア・ロード・バランサのフロントエンドのSSL URLにアクセスできることを確認する必要もあります。

これにより、SOAコンポジット・アプリケーションとWebサービスが、フロントエンドのセキュアURLとのコールバックやその他の通信を起動できるようになります。「中間層とハードウェア・ロード・バランサ間のSSL通信の有効化」を参照してください。

親トピック: Oracle SOA Suiteの構成後ステップ

SOAクラスタ内の同期/非同期相互作用に関する考慮事項

SOAクラスタでは、次のシナリオはサポートされていません。

  • mid-process receiveを持つ同期BPELプロセス

  • 非同期サービスをコールする同期BPELプロセス。

  • 同期プロセスからのコールバック。

親トピック: Oracle SOA Suiteの構成後ステップ

FusionAppsFrontendHostUrlの更新

デフォルトのTo-Doタスクとカスタム・タスクの詳細でフロントエンド・ロード・バランサを使用してタスク表示URLが作成されるように、適切なURLでOracle Workflowを構成する必要があります。

適切なURLを構成する手順は次のとおりです。

  1. boot.propertiesファイルで指定したユーザー名とパスワードを使用してOracle Enterprise Manager Fusion Middleware Controlにログインします。「boot.propertiesファイルの作成」を参照してください。
  2. 左側のナビゲーション・ツリーで、「WebLogicドメイン」を選択し、「システムMBeanブラウザ」をクリックします。
  3. 「アプリケーション定義のMBean」→ oracle.as.soainfra.configに移動します。
    1. 静的クラスタを構成している場合は、「サーバー: WLS_SOA1」→「WorkflowConfig」に移動します。
    2. 動的クラスタを構成する場合は、「ドメイン: wcpedg_domain」→「WorkflowConfig」に移動します。
  4. 「human-workflow」をクリックします。

    注意:

    クラスタ環境では、クラスタ内のサーバーごとに1つずつ、複数のhuman-workflow Mbeanが存在します。それらのいずれか1つを変更して、クラスタ全体のMDSで一元的にプロパティを更新します。

  5. 右パネルで、FusionAppsFrontendHostUrl属性を探します。
  6. FusionAppsFrontendHostUrl属性の値には、*=https://wcp.example.com:443を指定します。
  7. 「適用」をクリックします。

親トピック: Oracle SOA Suiteの構成後ステップ

JDBC永続ストアの有効化

Oracleデータベースの一貫性、データ保護および高可用性機能を活用し、クラスタ内のすべてのサーバーによるリソースの使用を可能にする、JDBCストアを使用することをお薦めします。

静的クラスタまたは動的クラスタを使用するときには、次のガイドラインに従って確実にJDBCストアを使用してください。

  • 静的クラスタの場合

    このガイドで静的クラスタに対してお薦めしたように、「高可用性のオプション」画面で、次のとおりに選択した場合は、すでにJMSとTLOGSの両方のJDBC永続ストアが構成されています。

    • 「JTAトランザクション・ログ永続性」を「JDBC TLogストア」に設定します。

    • 「JMSサーバー永続性」を「JMS JDBCストア」に設定します。

  • 動的クラスタの場合

    構成ウィザードを使用して動的クラスタ用に構成できるのはJMSサーバー永続性のみです。JTAトランザクション・ログ永続性は、手動で構成する必要があります(この永続性が必要な場合)。このガイドで動的クラスタに対してお薦めしたように、「高可用性のオプション」画面で、次のとおりに選択した場合は、すでにJMSのJDBC永続ストアが構成されています。

    • 「JMSサーバー永続性」を「JMS JDBCストア」に設定します。

    • 「JTAトランザクション・ログ永続性」が「デフォルトの永続ストア」に設定されていることを確認します。

    JDBCストアでJTAトランザクション・ログを構成するには、追加のステップが必要になります。「TLOG用のJDBC永続ストア構成のロードマップ」を参照してください。

「高可用性のオプション」画面で、JMSとTLOGSの永続のためにJDBCを選択していなかった場合でも、その後のステップでJDBCストアを手動で構成できます。手動で構成する際の具体的な手順は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用」を参照してください。

注意:

「高可用性のオプション」画面は、自動サービス移行とJDBCストアの両方またはどちらかを使用するクラスタの作成時に、構成ウィザードの初回のセッション中に表示されます。それ以降、構成ウィザードを使用してドメインに追加されるクラスタには、選択済のHAオプションが自動的に適用されます。

親トピック: Oracle SOA Suiteを含めるドメインの拡張

自動サービス移行の有効化

この章でインストールした製品の高可用性を実現するには、適切にサービス移行を構成する必要があります。

静的クラスタまたは動的クラスタを使用するときには、次のガイドラインに従ってWebLogicサービスに必要な高可用性を指定していることを確認してください。

  • 静的クラスタの場合

    自動サービス移行は、「高可用性のオプション」画面の「データベース・ベース」で「自動サービス移行の有効化」を選択していると、すでに構成されています。

    データベース・リースはすでに構成されていて、移行可能ターゲットはクラスタの適切なポリシーで作成されます。この設定が実施済の場合は、構成を検証します。検証の詳細は、「静的クラスタでの自動サービス移行の検証」を参照してください。

    構成ウィザードのセッション中に、このオプションを選択していない場合でも、その後のステップで自動移行を手動で構成できます。静的クラスタに対する完全なステップについては、「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照してください。

  • 動的クラスタの場合

    動的クラスタのサービス移行は、構成ウィザードを使用して構成することはできません。手動で構成する必要があります。次のステップを実行する必要があります。

    • クラスタのデータベース・リースを構成します。

    • JTAサービスとJMS永続ストアに適切な移行ポリシーを設定します。

    動的クラスタに対する完全なステップについては、「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照してください。

注意:

「高可用性のオプション」画面は、自動サービス移行とJDBCストアの両方またはどちらかを使用するクラスタの作成時に、構成ウィザードの初回のセッション中に表示されます。それ以降、構成ウィザードを使用してドメインに追加されるクラスタには、選択済のHAオプションが自動的に適用されます。

親トピック: Oracle SOA Suiteを含めるドメインの拡張

構成のバックアップ

ベスト・プラクティスとして、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。ここまでのインストールが正常に行われたことを確認したら、バックアップを作成します。これは、後のステップで問題が発生した場合に即座にリストアするための迅速なバックアップになります。

バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

構成をバックアップする方法の詳細は、「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。

親トピック: Oracle SOA Suiteを含めるドメインの拡張