weblogic_soa
)をLDAPディレクトリ内のBusiness Process Management Administrators
グループに追加します。この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。
いくつかのディレクトリ変数の値については、「このガイドで使用するファイル・システムとディレクトリ変数」に定義されています。
ORACLE_HOME
ASERVER_HOME
MSERVER_HOME
OHS_DOMAIN_HOME
JAVA_HOME
さらに、「エンタープライズ・トポロジによって必要とされる物理および仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスを参照することになります。
ADMINVHN
この章のアクションは、次のホスト・コンピュータで実行します。
SOAHOST1
SOAHOST2
WEBHOST1
WEBHOST2
現在のドメインを拡張する前に、既存のデプロイメントが次の前提条件を満たしていることを確認します。
インストールのバックアップ - 既存のFusion Middlewareホームとドメインをバックアップしていない場合は、今すぐバックアップすることをお薦めします。
既存のFusion Middlewareホームとドメインをバックアップするには、「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」を参照してください。
既存のWL_HOMEおよびSOA ORACLE_HOME (バイナリ)は、共有記憶域に関する章でインストールされており、SOAHOST1およびSOAHOST2にあります。
ノード・マネージャ、管理サーバー、SOAサーバーおよびWSMサーバーが存在し、前の章の説明のように、SOAシステムを実行するように構成されていること。
RCUを実行して、BPM用の追加のスキーマをロードする必要はありません。これらは、SOAリポジトリの一部であり、SOAに関する章でDBにロードされています。
次の各項では、エンタープライズ・デプロイメント用のOracle SOA Foundation and Business Process Managementソフトウェアのインストール方法を説明します。
インストール・プログラムでは、表15-1に記載された順番で一連の画面が表示されます。
インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。
表15-1 Oracle Business Process Managementのインストール画面
画面 | 説明 |
---|---|
インストール・インベントリの設定 |
この画面は、UNIXオペレーティング・システムで、このホストに初めてOracle製品をインストールする場合に表示されます。中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名には、中央インベントリの場所への書込み権限があることを確認してください。 中央インベントリの詳細は、Oracle Universal InstallerによるソフトウェアのインストールでOracle中央インベントリの理解に関する項を参照してください。 |
自動更新 |
この画面では、使用可能なパッチを探してMy Oracle Supportを自動的に検索するか、組織にすでにダウンロードしたパッチを探してローカル・ディレクトリを自動的に検索します。 |
インストールの場所 |
この画面を使用してOracleホーム・ディレクトリの位置を指定します。Oracleホームの場合は、 Oracle Fusion Middlewareディレクトリ構造の詳細は、Oracle Fusion Middlewareのインストールのプランニングでインストールと構成のディレクトリの選択に関する項を参照してください。 |
インストール・タイプ |
この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。
注意: このドキュメントのトポロジには、例は含まれていません。例を本番環境にインストールしないことを強くお薦めします。 |
前提条件のチェック |
この画面では、ご使用のシステムが最小要件を満たしていることを検証します。 警告メッセージまたはエラー・メッセージが表示された場合は、第1.4項に記載されているドキュメントのいずれかを参照してください。 |
インストール・サマリー |
この画面を使用して、選択したインストール・オプションを確認します。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。レスポンス・ファイルは、今後、サイレント・インストールを実行する場合に使用できます。 サイレント・インストールやコマンド行インストールの詳細は、Oracle Universal Installerによるソフトウェアのインストールでサイレント・モードにおけるOracle Universal Installerの使用方法に関する項を参照してください。 「インストール」をクリックしてインストールを開始します。 |
インストールの進行状況 |
この画面では、インストールの進行状況を参照できます。 進捗バーが100%完了になった後で、「次へ」をクリックします。 |
インストール完了 |
この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。 |
インストールの完了後、次のタスクを正常に実行することでインストールを検証できます。
インストール・ログ・ファイルの内容を確認し、何も問題が発生していないことを確認します。ログ・ファイルの説明とその場所の詳細は、Oracle Universal Installerを使用したソフトウェアのインストールのインストール・ログ・ファイルの理解に関する項を参照してください。
インストールの内容は、インストール中に選択したオプションによって異なります。
BPMを追加すると、ORACLE_HOME
/soa/bpm
ディレクトリに次のディレクトリとサブディレクトリが追加されます。
composites helpsets lib modules
インストール後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解の「Oracle Fusion Middlewareの主要ディレクトリとは」を参照してください。ls -lart
ORACLE_COMMON_HOMEディレクトリで構成ウィザードを実行して、管理サーバー、Oracle Web Services ManagerおよびSOAを含むドメインを拡張し、BPMのコンポーネントをサポートするようにします。
注意:
ドメインで起動スクリプトに直接カスタマイズを追加した場合、それらのカスタマイズは構成ウィザードによって上書きされます。ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverrides.sh
という名前のファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のjavaコマンド行オプションの指定、追加の環境変数の指定などを行うように構成できます。このファイルに追加されたカスタマイズはドメインのアップグレード操作中に保存され、packおよびunpackコマンドを使用する際にリモート・サーバーに継承されます。
構成ウィザードを起動する手順は次のとおりです。
この項の手順に従って、BPM用にドメインを拡張します。
注意:
この手順では、既存のドメインを拡張することを想定しています。この手順の説明では要件が満たされない場合は、その要件に応じた選択を行うか、サポート・ドキュメントで追加の詳細を参照してください。
ドメインを作成して構成するためのタスクは次のとおりです。
「構成タイプ」画面で、「既存ドメインの更新」を選択します。
「ドメインの場所」フィールドで、ASERVER_HOME
変数の値を選択します。これは、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。
ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください
ヒント:
この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。
「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。
Oracle BPM Suite - 12.2.1.1.0 [soa]
また、次の追加のテンプレートも、初期ドメインの作成と初期ドメインのSOAへの拡張に使用されているため、すでに選択されているはずです。
Basic Weblogic Server Domain - 12.2.1.1.0 [wlserver]
Oracle SOA Suite 12.2.1.1.0 [soa]
Oracle Enterprise Manager - 12.2.1.1.0 [em]
Oracle WSM Policy Manager - 12.2.1.1.0 [oracle_common]
Oracle JRF - 12.2.1.1.0 [oracle_common]
WebLogic Coherenceクラスタの拡張 - 12.2.1.1.0 [wlserver]
前にOracle Service Busを含めることでドメインを拡張した場合は、次のテンプレートも選択されています。
WebLogic Advanced Web Services for JAX-RPC Extension - 12.2.1.1.0 [oracle_common]
ODSI XQuery 2004 Components - 12.1.3.0 [oracle_common]
注意:
ODSI用の12.2.1.1.0テンプレートはありません。12.1.3テンプレートは12.2.1.1.0構成に役立ちます。
ヒント:
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のテンプレートに関する項を参照してください。
Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。BPMは既存のSOAのデータソースを使用するため、新しいデータソースをドメインに追加する必要はありません。
注意:
拡張前に作成されたカスタム・データソース(リース・データソースなど)は、この画面の前に表示されます。「データソース」行を確認し、「次へ」をクリックします。テスト・データソース画面で、その妥当性が確認されます。「次へ」をクリックします。
トポロジのドメイン構成を完了するには、「拡張構成」画面で追加のオプションを選択しないで、「次へ(N)」をクリックします。BPMアプリケーションと必要なアーティファクトは、自動的に既存のSOAサーバーをターゲットとします。
「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。
変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することによって前のいずれかの画面に戻ることができます。
「更新」をクリックするまで、ドメインの作成は開始されません。
ヒント:
この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。
「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。
ドメインの場所
管理サーバーURL
いずれの項目も後で必要になるため、メモしておいてください。ドメインの場所は管理サーバーを開始するために使用するスクリプトへのアクセスに必要で、URLは管理サーバーへのアクセスに必要です。
「終了」をクリックして、構成ウィザードを閉じます。
管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。
Oracle BPM Suiteでは、WebLogic Serverの起動スクリプトに多少の更新が必要です。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。
表15-2は、変更をすべてのドメイン・ディレクトリとマシンに伝播するために必要な手順をまとめたものです。
更新済ドメインをWEBHOST1およびWEBHOST2マシンに伝播する必要はありません。それらのホスト・コンピュータ上のOracle HTTP Serverインスタンスに対する変更はないためです。
表15-2 ドメイン変更をドメイン・ディレクトリおよびマシンに伝播するために必要なタスクのサマリー
タスク | 説明 | 詳細情報 |
---|---|---|
SOAHOST1での拡張済ドメインの圧縮 |
Packコマンドを使用して、新しいOracle BPM Suite管理対象サーバー構成が含まれる新しいテンプレートJARファイルを作成します。 ドメインを圧縮する場合は、 |
|
SOAHOST1の管理対象サーバー・ディレクトリでのドメインの解凍 |
SOAHOST1のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。 |
|
SOAHOST2でのドメインの解凍 |
SOAHOST2のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。 |
MSERVER/bin/startManagedWebLogic.sh
ファイルを編集します。
次のコードをstartManagedWeblogic.sh
ファイルに挿入します。
if [ "$1" = "WLS_SOA1" ] ; then export cache_port=8001 export host_bind=SOAHOST1 fi if [ "$1" = "WLS_SOA2" ] ; then export cache_port=8001 export host_bind=SOAHOST2 fi
注意:
スケール・シナリオでは、サーバー、ホストおよびポートを更新する必要があります。JAVA_OPTIONS= -Djgroups.tcpping.bind_port="${cache_port}" -Djgroups.tcpping.initial_hosts=SOAHOST1[8001],SOAHOST2[8001] -Dfrevvo.metadata.cache-config=/WEB-INF/cache-clustered.xml -Dfrevvo.cache.config.file=cache-tcp.xml -Dfrevvo.cluster=SOA_Cluster -Djgroups.tcpping.num_members=2 -Djgroups.bind_addr=host_bind -Djava.net.preferIP4Stack=true
JAVA_OPTIONSセクションの残りの部分は、元の内容のままとする必要があります。
構成変更および起動スクリプトを有効にするには、BPMが追加されたWLS_SOAnサーバーを再起動する必要があります。
BPMでは既存のSOAシステムが拡張されているので、管理サーバーおよびそれぞれのノード・マネージャはSOAHOST1およびSOAHOST2で稼働しています。
WLS_SOA1管理対象サーバーを再起動する手順は次のとおりです。
管理対象サーバーのOracle Business Process Management構成を検証する前に、エンタープライズ・デプロイメント管理ユーザー(weblogic_soa
)をLDAPディレクトリ内のBusiness Process Management Administrators
グループに追加します。
このタスクを実行するには、「Oracle SOA Suite製品の管理のためのロールの構成」を参照してください。
Business Process Management ComposerまたはBusiness Process Management Worklistアプリケーションに初めてログインするときは、Administratorsグループのメンバーであるユーザーとしてログインする必要があります。初回ログイン後、ユーザーは次のロールが付与されていれば管理ユーザーになることができます。
OracleBPMComposerRolesApp/BPMComposerAdmin
また、初回ログイン後、認証済ユーザーであれば、Business Process Managementアプリケーションにアクセスできるようになります。
次の項では、Web層のWebサーバー・インスタンスを構成して、拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをルーティングする方法について説明します。
このドメインでOracle Traffic Directorを構成した場合、状況によっては、Oracle Traffic Director構成に別のオリジン・サーバー・プール、仮想サーバーまたはルートを追加する必要があります。各Oracle Fusion Middleware製品のOracle Traffic Directorの要件を理解するには、「オリジン・サーバーおよび仮想ホストのサマリー」を参照してください。
オリジン・サーバー・プール、仮想サーバーおよびルートを追加する手順は、「エンタープライズ・デプロイメント用のOracle Traffic Director仮想サーバーの定義」を参照してください。
Oracle HTTP Serverインスタンス構成ファイルに次の変更を行って、Web層のOracle HTTP ServerインスタンスがOracle Business Process ManagementリクエストをOracle Business Process Managementソフトウェアに正しくルーティングできるようにします。
Oracle HTTP ServerがBPM ComposerまたはBPM Workspaceコンソールにリクエストをルーティングできるようにする手順は次のとおりです。
Business Process Managementを含めてドメインを拡張した後、管理サーバーと管理対象サーバーがハードウェア・ロード・バランサのフロントエンドのSSL URLにアクセスできることを確認する必要もあります。
これにより、Business Process Managementが、Webサービスを使用してフロントエンドのセキュアURLとのコールバックやその他の通信を起動できるようになります。
Oracle SOA Suite (WLS_SOA)管理対象サーバーに対してすでにこの通信を構成している場合は、「ハードウェア・ロード・バランサを使用したBusiness Process Managementへのアクセスの検証」の検証手順を使用し、この構成を検証できます。
ハードウェア・ロード・バランサとのSSL通信をまだ構成していない場合は、検証手順に進む前に「中間層とハードウェア・ロード・バランサ間のSSL通信の有効化」を参照してください。
SOA_Clusterのクラスタ・アドレスは前の章ですでに設定されているので、Business Process ManagementコンテキストURLをWebLogic ServerにルーティングするようにOracle HTTP Server構成ファイルを変更した後にのみBusiness Process Managementシステムを検証できます。
次の手順を使用して、Business Process Management URLを検証し、ハードウェア・ロード・バランサからOracle HTTP Serverインスタンスを経由してBusiness Process Management管理対象サーバーに至るルーティングとフェイルオーバーが適切に機能することを確認します。
BPMJMSModule JMSモジュールを構成するには、モジュール内の一部のデフォルト値をこの項に示すように変更する必要があります。
BPMJMSModule JMSモジュールは、Oracle Business Process ManagementをOracle WebLogic Serverドメインに構成すると自動的にデプロイされます。
ただし、Oracle Business Process ManagementサーバーをOracle WebLogic Serverクラスタの一部としてデプロイした場合は、BPMJMSModule JMSモジュール内の個々のJMSリソースについて割当および再配信の制限のデフォルト値を変更する必要があります。
具体的には、次の表に示されているJMSトピック・リソースを変更する必要があります。
JMSリソース | プロパティ | 説明 | 推奨設定 |
---|---|---|---|
クラスタ構成内の「測定」分散トピック:
|
割当 |
大量のメッセージが「測定」jmsトピックにパブリッシュされ、メッセージの消費が比較的遅い場合に、この設定が原因で問題が発生することがあります。 JMSの最大メッセージサイズのデフォルトのしきい値に到達すると、それ以上メッセージをパブリッシュできなくなり、一切のパブリッシュの試みは次の例外を受信して失敗します。 ResourceAllocationException |
「割当」をMeasurementQuotaに設定します。 |
クラスタ構成内の「測定」分散トピック:
|
再配信の制限 |
クラスタ構成では、このプロパティはデフォルトで「-1」に設定されます。 この設定が原因で、JMSが確認応答を受信するまでメッセージの送信を再試行することがあります。 トランザクションのロールバックを引き起こすシステム・エラーが発生したために、「測定」トピックのコンシューマがメッセージを処理できない場合、システムでパフォーマンスの問題が発生したり、繰り返される例外でログが一杯になったりすることがあります。 |
再配信の制限を |
クラスタ構成内の「測定」分散トピック:
|
転送ポリシー |
クラスタ・インストール内の分散測定トピックは、デフォルトでは転送ポリシーが「レプリケート」に設定されて構成されていますが、これはBPM分析の最善のパフォーマンス・オプションではありません。 詳細は、パフォーマンスのチューニングのOracle Business Process Managementのチューニングに関する項を参照してください。 |
転送ポリシーを「パーティション化」に変更します。 |
BPMJMSModuleリソースの設定を変更する手順:
Oracleのベスト・プラクティスとしては、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。
バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。
構成をバックアップする方法の詳細は、「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」を参照してください。
Oracle Business Process Managementが高可用性を実現するように構成するには、フェイルオーバーおよびゼロ・データ損失を実現する自動サービス移行で管理対象サーバーを構成します。
サーバー移行の有効化の詳細は、「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照してください。
WLS_SOA管理対象サーバーに対してすでに自動サービス移行が構成されている場合、この手順は不要です。
可用性を高めるために、データベース内にトランザクション・ログ・ストアとJMSストアを構成することもできます。詳細は、「エンタープライズ・デプロイメントでのTLOGおよびJMSに対するJDBC永続ストアの使用」を参照してください。