Oracle® Business Transaction Management

インストレーション・ガイド

12.1.0.5

E53008-01(原本部品番号:E51101-01)

2014年1月

Oracle Business Transaction Managementインストレーション・ガイド12.1.0.5

E53008-01

Copyright (C) 2013, 2014, Oracle and/or its affiliates.All rights reserved.

原本著者: Alan Davidson

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要

- 1.1 アーキテクチャ

- 1.2 パッケージ

2 Business Transaction Managementのアップグレード

- 2.1 概要

- 2.1.1 アップグレード・ステップの順序

- 2.1.2 オブザーバのアップグレードの重要性

- 2.1.3 アップグレード後の問題の解決

- 2.2 セントラル・サーバーおよびモニターのアップグレード

- 2.3 オブザーバのアップグレード

- 2.3.1 WebLogic 10.3上のオブザーバのアップグレード

- 2.3.1.1 12.1.0.4、12.1.0.3または12.1.0.2.2のオブザーバ、OSB 10gR3用オブザーバ、JavaEE用12.1.0.2.0オブザーバのアップグレード

- 2.3.1.2 ノード・マネージャ構成サーバー上のSOAまたはOSB 11gR1用12.1.0.2.0オブザーバあるいはJavaEE用11または12.1.0.1オブザーバのアップグレード

- 2.3.1.3 スクリプト構成サーバー上のSOAまたはOSB 11gR1用12.1.0.2.0オブザーバあるいはJavaEE用11または12.1.0.1オブザーバのアップグレード

- 2.3.2 WCF用のオブザーバのアップグレード

- 2.3.3 Oracle Enterprise Gateway用のオブザーバのアップグレード

3 インストールの概要

- 3.1 インストールの概要

4 セキュリティの構成

- 4.1 通信プロトコルおよびデプロイメント・シナリオ

- 4.2 ネットワーク・レベルのセキュリティ設定

- 4.2.1 HTTPSの構成

- 4.2.2 WebLogic ServerのJSEEプロパティ設定

- 4.2.3 コマンドライン・インタフェース用のJSEEプロパティ設定

- 4.2.4 ファイアウォールの構成

- 4.3 アサーション秘密および暗号化鍵の構成

- 4.3.1 Oracle Walletによるセキュリティ構成

- 4.3.2 拡張プロパティによるセキュリティ構成

- 4.3.2.1 拡張プロパティ・ファイルの設定

- 4.3.2.2 ポインタの設定

- 4.4 監視メッセージ用のセキュア・ソケット(SSL)の設定

5 前提条件および予備設定

- 5.1 Webブラウザの要件

- 5.2 WSDLおよびスキーマ・リソースへのアクセス

- 5.3 WebLogic環境の設定

- 5.4 Business Transaction Managementデータベースの設定

- 5.4.1 モニター・グループ・データベースの設定

- 5.4.2 データベース・リソース要件の見積り

6 セントラル・サーバーのインストールおよび構成

- 6.1 セントラル・サーバーのインストールおよび構成の概要

- 6.2 永続記憶域ディレクトリの構成

- 6.2.1 永続記憶域ディレクトリの場所の再構成

- 6.3 セントラル・サーバーのデプロイ

- 6.4 ユーザーのロールへのマッピング

- 6.4.1 Business Transaction Managementアプリケーション・ロール

- 6.4.1.1 プライマリ・ロール

- 6.4.1.2 補助ロール

- 6.4.2 WebLogicユーザーのBusiness Transaction Managementロールへのマッピング

- 6.5 Business Transaction Managementの初期構成

- 6.6 Enterprise Managerへの接続の構成

7 モニターのインストール

- 7.1 モニターのインストールの概要

- 7.2 モニターのデプロイおよび登録

- 7.3 モニター・グループの設定

- 7.4 ロード・バランサの構成

- 7.5 オブザーバ通信ポリシーの適用

- 7.5.1 オブザーバ通信ポリシーについて

- 7.5.2 オブザーバ通信ポリシーの適用手順

- 7.5.2.1 オブザーバ通信ポリシーのモニター関連フィールドの構成

- 7.5.2.2 オブザーバ通信ポリシーのオブザーバ関連フィールドの構成

- 7.5.3 適用する必要があるオブザーバ通信ポリシーの数

- 7.5.4 事前構成済オブザーバ通信ポリシー

- 7.5.5 オブザーバのターゲット指定についての参考情報

- 7.5.5.1 オブザーバ構成ラベル

- 7.5.5.2 オブザーバ通信ポリシーの拒否

- 7.5.5.3 優先順位

- 7.5.5.4 オブザーバのターゲット指定フィールドについての参考情報

- 7.6 モニター・グループ・メンバーの追加および削除

- 7.6.1 モニター・グループへのメンバーの追加

- 7.6.2 モニター・グループからのメンバーの削除

8 オブザーバのインストールの概要

- 8.1 前提条件および予備設定チェックリスト

- 8.2 一般的なオブザーバのインストール手順

- 8.3 オブザーバ・ライブラリのデフォルトの場所のオーバーライド

9 WebLogicへのオブザーバ・ライブラリのインストール

- 9.1 ノード・マネージャ構成のサーバーへのインストール

- 9.2 スクリプト構成のサーバーへのインストール

- 9.3 WebLogicからのオブザーバ・ライブラリのアンインストール

- 9.3.1 ノード・マネージャで構成された管理対象サーバーからのアンインストール

- 9.3.2 ローカル・スクリプトで構成されたサーバーからのアンインストール

10 WCF用のオブザーバ・ライブラリのインストール

- 10.1 オブザーバ配布ファイル

- 10.2 WCF 3.5および4.0用のオブザーバ・ライブラリのインストール

- 10.3 machine.configファイルの編集

- 10.4 web.configファイルの編集

- 10.5 WCF 3.5および4.0用のオブザーバ・ライブラリのアンインストール

11 Oracle Enterprise Gatewayへのオブザーバ・ライブラリのインストール

- 11.1 オブザーバ配布ファイル

- 11.2 Enterprise Gateway 11.1.1.6へのオブザーバ・ライブラリのインストール

- 11.3 Enterprise Gateway 11.1.1.6からのオブザーバ・ライブラリのアンインストール

12 Business Transaction Managementの起動および停止

- 12.1 Business Transaction Managementコンポーネントの起動

- 12.2 Business Transaction Managementコンポーネントの停止

- 12.3 モニター・グループ・メンバーの停止および再起動

- 12.3.1 モニター・グループ・メンバーの停止

- 12.3.2 モニター・グループ・メンバーの再起動

- 12.4 管理コンソールのロギング

- 12.5 管理コンソールからのログアウト

- 12.6 オンライン・ヘルプ

13 オブザーバ・エラーおよびデバッグ情報のロギング

14 Oracle Business Transaction Managementのスクリプトによる構成

- 14.1 configureコマンド

- 14.2 CLIの起動

15 datastoreUtilユーティリティ

- 15.1 使用方法

- 15.2 コマンド

- 15.2.1 generateSchema (またはgenerate)

- 15.2.2 connect

- 15.2.3 createSchema (またはcreate)

- 15.2.4 close

- 15.2.5 exit

- 15.2.6 help

索引

はじめに

Oracle Business Transaction Managementインストレーション・ガイドでは、セントラル・サーバー、モニターおよびオブザーバを含むBusiness Transaction Management 12.1.0.5のインストール方法について説明しています。

対象読者

このドキュメントは、システム管理者およびその他のBusiness Transaction Management 12.1.0.5インストール担当者を対象にしています。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要

このガイドでは、Oracle Business Transaction Managementのインストール方法を説明します。このガイドでは、システムの機能およびユースケースの試行に適した汎用Business Transaction Managementシステムのインストールおよび構成に役立つ情報を提供しています。本番環境に必要なデプロイ構成およびリソースは、予測されるスループット、メッセージのサイズおよびタイプ、適用される監視ポリシーの数など、様々な要素によって異なります。Oracleコンサルタントが、お客様固有のニーズに適した構成およびリソース要件を決定するお手伝いをいたします。

この章では、製品アーキテクチャの概要、製品パッケージおよび一般的なデプロイのガイドラインについて説明します。

1.1 アーキテクチャ

Business Transaction Managementは、次の3種類の最上位コンポーネントから構成されています。

- セントラル・サーバー – セントラル・サーバーは、アプリケーション・サーバーにデプロイするアプリケーションEARファイルです。セントラル・サーバーは3つあります。これらのサーバーは一括でデプロイすることもできますが、パフォーマンスを考慮してそれぞれ別々のWebLogic Serverインスタンスにデプロイすることが推奨されます。モニター用のサービスまたはコンポーネントをホストしているWebLogic Serverインスタンスには、いかなるセントラル・サーバーもデプロイしてはいけません。セントラル・サーバーには、以下のものがあります。

- メイン・サーバー(btmMain.ear) – スフィアを含む、すべての集中Business Transaction Managementシステム・サービスおよびユーザー・インタフェース・アプリケーションが含まれています。スフィアは、Business Transaction Management環境を管理するBusiness Transaction Managementコンポーネントです。さらに、btmMain.earには、F5仲介用のサブデプロイメントが含まれています。

- パフォーマンス・サーバー(btmPerformanceServer.ear) – サービス・レベル管理コンポーネントが含まれています。btmPerformanceServer.earは、btmMain.earおよびbtmTransactionServer.earがデプロイされていないアプリケーション・サーバーにデプロイします。

- トランザクション・サーバー(btmTransactionServer.ear) – トランザクション管理コンポーネントが含まれています。btmTransactionServer.earは、btmMain.earおよび btmPerformanceServer.earがデプロイされていないアプリケーション・サーバーにデプロイします。

- オブザーバ – オブザーバは、監視するビジネス・アプリケーションをホストしているアプリケーション・サーバーにインストールする一連のライブラリです。オブザーバはアプリケーション・コンポーネント間のメッセージおよび呼出しを監視します。オブザーバは様々なタイプのコンポーネントの監視が可能で、監視対象のタイプやオブザーバを実行するアプリケーション・サーバーによって分類されます。

- モニター (btmMonitor.ear) – モニターは、アプリケーション・パフォーマンスおよび使用状況の測定結果をオブザーバから収集します。モニターは、アプリケーション・サーバーにデプロイするアプリケーションEARファイルです。大規模システムには、シングルトンまたはレプリケートのいずれかとして、複数のモニターをデプロイすることも可能です。パフォーマンスの点から、モニターはセントラル・サーバーがデプロイされているアプリケーション・サーバーにはデプロイしないでください。

Business Transaction Managementは、パフォーマンス測定結果の格納、メッセージのロギング、環境モデルおよびBusiness Transaction Managementの構成の保持のために、Oracle RDBMSにアクセスできる必要があります。

下の図には、標準的な分散アプリケーション環境と、Business Transaction Managementコンポーネントとその環境との関係が示されています。

図1-1 標準的なアプリケーション環境でのBusiness Transaction Managementコンポーネントのデプロイ

Business Transaction Managementは、様々なBusiness Transaction Managementコンポーネントが複数台のマシンおよびアプリケーション・サーバーにデプロイされる分散アプリケーション環境で使用できるように設計されています。

技術的には、すべてのセントラル・サーバーを1台のアプリケーション・サーバーにインストールすることも可能ですが、本番環境ではそのようなデプロイメント・シナリオは推奨されません。1台のアプリケーション・サーバーにインストールした場合、デモや製品の使用方法の学習には役立ちますが、このシナリオはたとえば大量のビジネス・サービスやメッセージ・トラフィックには対応できない場合があります。

それぞれのセントラル・サーバーは、別々のアプリケーション・サーバーにデプロイすることが推奨されます。特に、パフォーマンスおよびトランザクションのコンポーネントは、通常大量のパフォーマンス分析計算を行います。アプリケーション・サーバー間でプロセスを分割することによって、メモリーおよびプロセッサのリソースを制御することができます。

また、モニターもセントラル・サーバーとは別のアプリケーション・サーバーにデプロイする必要があります。監視要件によっては、複数のモニターのデプロイが必要になることもあります。モニターは、シングルトンまたはロード・バランサの背後のレプリケートのいずれかとしてデプロイできます。モニターのレプリケートの詳細は、第7章「モニターのインストール」を参照してください。

オブザーバは、セントラル・サーバーまたはモニターをホストしているアプリケーション・サーバーの外側にインストールする必要があります。

1.2 パッケージ

Business Transaction Managementは、ZIPファイルとして配布されています。セントラル・サーバーおよびモニターは、BTM_Servers_*.zip内に一緒にパッケージ化されています(「*」はBusiness Transaction Managementのバージョン番号を指します)。ZIPファイルのアーカイブ・ディレクトリに、セントラル・サーバーおよびモニターのデプロイメントが含まれています。表 1-1に、含まれるデプロイメントを示します。

表1-1 BTM_Servers_*.zipのアーカイブ・ディレクトリに含まれるEARファイル(セントラル・サーバーおよびモニターが含まれる)

デプロイメント名

サブデプロイメント

デプロイメント戦略

btmMain.ear

btmcentral.war

btmcontainer.war

btmhelp.war

btmui.war

f5Intermediary.war

Business Transaction Management環境ごとに1回デプロイ

btmPerformanceServer.ear

btmcontainer.war

btmperformance.war

btmMain.earおよびbtmTransactionServer.earとは別のアプリケーション・サーバーに、Business Transaction Management環境ごとに1回デプロイ

btmTransactionServer.ear

btmcontainer.war

btmtransaction.war

btmMain.earおよびbtmPerformanceServer.earとは別のアプリケーション・サーバーに、Business Transaction Management環境ごとに1回デプロイ

btmMonitor.ear

btmmonitor.war

いずれのセントラル・サーバーとも別のアプリケーション・サーバーに、必要な数をデプロイ

オブザーバは、プラットフォームおよびオブザーバ・タイプに応じた個別のZIPファイルにパッケージ化されています。表1-2は、リリース12.1.0.5のオブザーバの一覧です。ZIPファイル名の「*」は、オブザーバのバージョン番号、たとえば12.1.0.5を指しています。

表1-2 リリース12.1.0.5で配布されるオブザーバ

オブザーバのZIPファイル名

説明

BTMObserver_Wls_10.3_Universal_*.zip

WebLogic 10.3サーバーで実行されるJavaEE、Oracle SOA Suite、Oracle Service Bus 11gR1およびOracle Fusion Applications (ADF-UI、ADF-BCおよびSOAデプロイメント)用のオブザーバが含まれます。

BTMObserver_Wls_12_JavaEE_*.zip

WebLogic 12サーバーで実行されるJavaEE用のオブザーバが含まれます。

BTMObserver_Wls_10.3_Osb11gR1_*.zip

WebLogic 10.3上のOracle Service Bus 10gR3用オブザーバが含まれます。

注: ZIPファイル名には文字列「Osb11gR1」が含まれていますが、このオブザーバはOracle Service Bus 10gR3をサポートしています。このオブザーバは、Oracle Service Bus 11gR1では推奨されません(11gR1では、BTMObserver_Wls_10.3_Universal_*.zipを使用する必要があります)。

BTMObserver_OEG_11.1.1.6_OEG_*.zip

Oracle Enterprise Gateway 11.1.1.6用のオブザーバが含まれています。

BTMObserver_Iis_7.5_DotNet4_*.zip

Microsoft IISバージョン7.5上のWCF 3.5および4.0用オブザーバが含まれています。

表1-3および表1-4に示されているオブザーバは、以前のリリースの一部として配布されています。これらのオブザーバは、リリース12.1.0.5には含まれていませんが、リリース12.1.0.5に対応しています。対象のプラットフォームを監視する必要がある場合、これらのオブザーバをインストールする必要があります。(各ZIPファイル名の「*」は、オブザーバのバージョン番号、たとえば12.1.0.1.0を指しています。)これらのオブザーバのインストール手順は、現在のリリースのインストレーション・ガイドには含まれていません。これらのオブザーバのインストール手順は、対象リリースのインストレーション・ガイドに記載されています。

表1-3 リリース12.1.0.5に含まれないが対応しているリリース12.1.0.3オブザーバ

オブザーバのZIPファイル名

説明

BTMObserver_Oc4j_10.1_Soa10g_*.zip

Oracle SOA Suite 10g内で実行されるOracle Containers for Java (OC4J)インスタンス用のオブザーバが含まれています。

表1-4 リリース12.1.0.5には含まれないが対応しているリリース12.1.0.1オブザーバ

オブザーバのZIPファイル名

説明

BTMObserver_Wls_9.2_JavaEE_*.zip

WebLogic 9.2上のJavaEE用のオブザーバが含まれています。

BTMObserver_Was_6.1_JavaEE_*.zip

WebSphere 6.1上のJavaEE用のオブザーバが含まれています。

BTMObserver_Jboss_4.3_JavaEE_*.zip

JBossEAP 4.3上のJavaEE用のオブザーバが含まれています。

2 Business Transaction Managementのアップグレード

この章では、リリース11または12のすべてのバージョンのBusiness Transaction Managementをリリース12.1.0.5へインプレース・アップグレードする方法について説明します。インプレース・アップグレードとは、構成の設定を編集せずにコンポーネントを単に新しいものと置き換えるアップグレードです。

2.1 概要

次のコンポーネントをアップグレードすると、Business Transaction Managementを完全にアップグレードすることになります。

- 3つのすべてのセントラル・サーバー、つまりメイン・サーバー(btmMain.ear)、パフォーマンス・サーバー(btmPerformanceServer.ear)およびトランザクション・サーバー(btmTransactionServer.ear)

- すべてのモニター(btmMonitor.ear)

- すべてのオブザーバ

これらのコンポーネントのいずれかがリリース11よりも古い場合は、この章の手順でアップグレードを実行しないでください。かわりに、My Oracle Support (http://support.oracle.com)で、インストールのアップグレードの支援を依頼するサービス・リクエストを入力してください。

2.1.1 アップグレード・ステップの順序

Business Transaction Managementシステムのコンポーネントをアップグレードする順序は重要で、インストールしたコンポーネントのリリース・バージョンおよびリリース12.1.0.5のモニターがオブザーバをサポートしているかどうかに依存します。そのため、次に進む前に以下のステップを完了してください。

1. セントラル・サーバー、モニターおよびオブザーバのリリース番号を書きとめます。
インストール済のオブザーバのリリースを判別するには、オブザーバのNanoAgent.logファイルを開き、リリース番号を表示している次の行を探します。次に例を示します。

INFO: Release 11.1.0.4: build 25237 of b21 (11.1.0.4/147754) on 2011-05-13

NanoAgent.logファイルの場所の詳細は、第13章「オブザーバ・エラーおよびデバッグ情報のロギング」を参照してください。

セントラル・サーバーおよびモニターのリリース番号は、配布ZIPファイルのnanoagentディレクトリにあるREADME.txtファイルにあります。

2. リリース12.1.0.5のモニターがオブザーバをサポートしているかどうかを判別します。
オブザーバがリリース12.1.0.2以上の場合、サポートされています。

オブザーバがリリース11.xの場合、サポートされていません。

オブザーバがリリース12.xで12.1.0.2より古い場合、Business Transaction Management (BTM)保証マトリックスを確認する必要があります。このドキュメントは、http://support.oracle.comからオンラインで参照できます。オブザーバがこの文書に表示されている場合、リリース12.1.0.5でサポートされています。表示されていない場合、サポートされていません。

次のシナリオを読んでアップグレード手順のステップの順番を決定し、第2.2項「セントラル・サーバーおよびモニターのアップグレード」および第2.3項「オブザーバのアップグレード」でアップグレード手順についての詳しい説明を参照します。

すべてのコンポーネントが最新である場合

セントラル・サーバーおよびモニターがリリース12.1.0.3以上で、リリース12.1.0.5がオブザーバをサポートしている場合、次のようにローリング・アップグレードを実行できます。

1. セントラル・サーバー – すべてのセントラル・サーバーを一斉に停止してアップグレードし、再起動します。

2. モニター – モニターを停止してアップグレードし、再起動します。モニターは1つずつ、または一斉にアップグレードできます。

3. オブザーバ – (省略可能)オブザーバを停止してアップグレードし、再起動します。オブザーバは1つずつ、または一斉にアップグレードできます。

セントラル・サーバーおよびモニターは古いが、オブザーバはサポートされている場合

セントラル・サーバーおよびモニターがリリース12.1.0.3より古く、リリース12.1.0.5がオブザーバをサポートしている場合、次の順序でアップグレード手順を実行します。

1. セントラル・サーバーおよびモニター – すべてのセントラル・サーバーおよびモニターを一斉に停止してアップグレードし、再起動します。

2. オブザーバ – (省略可能)オブザーバを停止してアップグレードし、再起動します。オブザーバは1つずつ、または一斉にアップグレードできます。

オブザーバがサポートされていない場合

オブザーバが古く、リリース12.1.0.5でサポートされていない場合、次のどちらかのアップグレード・パスに従います。

- すべてのセントラル・サーバー、モニターおよびオブザーバを一斉に停止してアップグレードし、再起動します。

- まず、オブザーバをリリース12.1.0.5がサポートしているが、モニターより新しくないリリース(オブザーバは関連付けられているモニターよりも新しいリリースにしてはいけません)にアップグレードします。次に、セントラル・サーバーおよびモニターをリリース12.1.0.5にアップグレードします。(省略可能)最後に、オブザーバをリリース12.1.0.5にアップグレードします。

注意:
オブザーバとモニターのバージョン番号を比較する際には、最後(4つ目)のドット後の数字は無視してかまいません。たとえば、「11.2.0.1.3」では、「3」は無視することができます。最後の数字はパッチを示し、オブザーバとモニターの互換性の判断においては重要ではありません。

2.1.2 オブザーバのアップグレードの重要性

セントラル・サーバーおよびモニターの両方のアップグレードした後に、可能なかぎりオブザーバをアップグレードする必要があります。オブザーバがリリース12よりも古い場合、アップグレードは必須です。オブザーバがリリース12でまだサポートされている場合、アップグレードは省略可能です。なお、オブザーバをアップグレードしない場合は、アップグレードされたオブザーバによる新機能を活用することはできません。

注意:
リリース12.1.0.3よりも古いセントラル・サーバーをアップグレードすると、新しく作成したオブザーバ通信ポリシーにオブザーバ認証フィールドが追加されます。このオブザーバ認証フィールドは、デフォルトで有効になっています。オブザーバ認証を使用する場合、オブザーバもアップグレードする必要があります。12.1.0.3より古いリリースのオブザーバは、自分自身を認証することができません。オブザーバを12.1.0.3以上にアップグレードしない場合は、作成するすべての新しいポリシーでオブザーバ認証フィールドを無効にする必要があります。そうしないと、オブザーバはモニターに接続できません。

2.1.3 アップグレード後の問題の解決

Business Transaction Managementシステムのアップグレード完了後に、「機能のアップグレードの問題」という名前のオンライン・ヘルプのトピックに目を通してください。このトピックでは、実行可能なアップグレードに関するタスクおよびアップグレード後のシステムの動作変更点についての情報が提供されています。最初に管理コンソールで「ヘルプ」→「ヘルプ」を選択することによって、このトピックを見つけることができます。オンライン・ヘルプが開いたら、目次ペインで「Oracle Business Transaction Managementの概要」に進み、「機能のアップグレードの問題」の項までスクロール・ダウンします。

「機能のアップグレードの問題」のトピックでは、次のような問題について説明しています。

- 新しいプローブ・タイプの活用

- 破損したトランザクションの修復

- 非推奨のプローブに関連するアーティファクトの識別と削除

2.2 セントラル・サーバーおよびモニターのアップグレード

注意:
RMIコールを監視する必要がない場合、アップグレード手順を開始する前にRMIプローブを非アクティブ化することを推奨します。ほとんどのアプリケーションは、JAX-RPC、JAX-WS、EJBおよびJMSのような高レベルAPIを通してRMIを使用しています。ご使用のアプリケーションがこれらの高レベルAPIを通してのみRMIを使用している場合、RMIプローブを非アクティブ化する必要があります。ただし、ご使用のアプリケーションが直接RMIを呼び出している場合、アクティブ化したままにしておく必要があります。
RMIプローブを非アクティブ化するには、最初にオブザーバ通信ポリシーを開きます。ポリシーの「アクティブ・プローブ」セクションには、各プローブ・タイプに対して「検出の有効化」および「検出時に監視」チェック・ボックスが表示されています。RMIについて、両方のチェック・ボックスを選択解除します。複数のオブザーバ通信ポリシーを使用している場合、各ポリシーについてこの作業を実行する必要があります。

RMIプローブの非アクティブ化後、検出されているすべてのRMIコンポーネントを登録解除する必要があります。RMIコンポーネントを登録解除するには、Business Transaction Managementコンソールでコンポーネント(サービスとしてモデル化)を選択し、「変更」→「Your_Service 登録の削除」を選択します。Your_ServiceはRMIコンポーネントの名前です。または、unregister CLIコマンドを使用することもできます。詳細は、Business Transaction Managementオンライン・ヘルプを参照してください。

インストール済のBusiness Transaction Managementをアップグレードするには、以下の手順を実行します。

1. Business Transaction Managementデータベースおよび構成データをバックアップします。
このタスクの実行方法については、オンライン・ヘルプのトピック「Business Transaction Managementのバックアップおよび復元」を参照してください。最初に管理コンソールで「ヘルプ」→「ヘルプ」を選択することによって、このトピックを見つけることができます。オンライン・ヘルプが開いたら、目次ペインで「Oracle Business Transaction Managementの管理」→「Business Transaction Managementのバックアップおよび復元」に進みます。

注意:
オンライン・ヘルプにアクセスするには、セントラル・サーバーが実行中である必要があります。

2. 各セントラル・サーバーおよびモニターの永続記憶域ディレクトリをバックアップします。
永続記憶域ディレクトリの場所については、オンライン・ヘルプのトピック「永続的データ」を参照してください。最初に管理コンソールで「ヘルプ」→「ヘルプ」を選択することによって、このトピックを見つけることができます。オンライン・ヘルプが開いたら、目次ペインで「Oracle Business Transaction Managementの管理」→「永続的データ」に進みます。

3. Business Transaction Managementセントラル・サーバーおよびモニターがインストールされているすべてのWebLogicドメインが、Java Required Files (JRF)テンプレートを含んでいることを確認します。(12.1.0.3のインストールをアップグレードしている場合は、この要件をすでに満たしています。)
これらのドメインのいずれかがJRFテンプレートを含んでいない場合、ドメインを拡張してテンプレートを追加します。JRFテンプレートがドメインに含まれてない場合は、サーバーを開始する際に次の例外が発生します。

java.lang.ClassNotFoundException: oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener

注意:
JRFテンプレートは、Oracle Application Development Framework (ADF)ランタイムの一部です。つまり、JRFテンプレートを含むようにドメインを拡張する前に、ADFランタイムをWebLogicにインストールする必要があります。ADFランタイムをインストールする際には、WebLogicのバージョンと一致したリリース・バージョンをインストールするよう注意してください。ADFランタイムは、次の場所からダウンロードできます。

http://www.oracle.com/technetwork/developer-tools/adf/downloads/index.html

4. Business Transaction Managementセントラル・サーバーおよびモニターを含む配布アーカイブを見つけ、任意のディレクトリ(以降、Install_Dirと表記)に解凍します。
配布アーカイブはBTM_Servers_*.zipという名前です。「*」はBusiness Transaction Managementのバージョン番号です。

5. UNIX系オペレーティング・システム向けの省略可能なセキュリティ・ステップ – 配布アーカイブの構成ファイルに、機能を維持できる最も制限の厳しいレベルの権限を設定したい場合、次のステップを実行します。

1. Install_Dirのトップ・レベルにあるsetPermissions.shを探します。
このスクリプトには、すべての標準ファイルのファイル権限を「所有者 – read/delete」、すべてのディレクトリを「所有者 - read/execute/delete」、すべてのスクリプトを「所有者 – read/execute/delete」に設定するコマンドが含まれています。

注意:
これらは非常に制限の厳しい権限レベルです。たとえば、ファイルを読み取ることができるのは所有者のみです。

2. コマンドラインで、Install_Dirのトップ・レベルから次のコマンドを実行します。

source setPermissions.sh

このコマンドによって、スクリプト・ファイル内のコマンドが実行され、解凍したアーカイブ内のすべてのファイルおよびディレクトリの権限が設定されます。

6. セントラル・サーバーおよびモニターのEARファイルをアップグレードします。
リリース12.1.0.3以上からアップグレードする場合、すべてのセントラル・サーバーおよびモニターのEARファイルを一斉にアップグレードするか、すべてのセントラル・サーバーのEARファイルをアップグレードした後にモニターのEARファイルを1つずつアップグレードすることができます。

12.1.0.3より古いリリースからアップグレードする場合、すべてのセントラル・サーバーおよびモニターのEARファイルを一斉にアップグレードする必要があります。

セントラル・サーバーおよびモニターのEARファイルを一斉にアップグレードする場合は、次の手順を実行します。

1. すべてのセントラル・サーバーおよびモニター(btmMain.ear、btmPerformanceServer.ear、btmTransactionServer.earおよびbtmMonitor.ear)を停止します。
すべてを停止する必要があります。

Business Transaction Managementコンポーネントの停止については、第12章「Business Transaction Managementの起動および停止」を参照してください。

2. アプリケーション・サーバーのデプロイメント・ツールとInstall_Dir\archivesにある新しいEARファイルを使用して、各セントラル・サーバーおよびモニターを再デプロイします。

3. セントラル・サーバーおよびモニターを再起動します。
12.1.0.5より古いリリースからアップグレードする場合、セントラル・サーバーの再起動によってBusiness Transaction Managementデータのインプレース・アップグレードが開始されます。このプロセスの間、システムにパフォーマンスの低下が発生したり、データが一時的に使用できなくなる可能性があります。このプロセスは、30分以内に完了します。単に12.1.0.5のインストールにパッチを適用する場合、システムは通常の速度で起動します。

Business Transaction Managementコンポーネントの起動については、第12章「Business Transaction Managementの起動および停止」を参照してください。

4. すべてのBusiness Transaction Managementユーザーに、Webブラウザのキャッシュをフラッシュするよう通知します。
管理コンソールには、多くのAdobe Flashウィジェットが含まれています。Webブラウザは通常このようなウィジェットをキャッシュし、キャッシュをフラッシュするかWebブラウザを再起動するまでキャッシュされた古いウィジェットを使用し続けます。

セントラル・サーバーのEARファイルをアップグレードしてからモニターのEARファイルをアップグレードする場合は、次の手順を実行します。

1. すべてのセントラル・サーバー(btmMain.ear、btmPerformanceServer.earおよびbtmTransactionServer.ear)を停止します。
Business Transaction Managementコンポーネントの停止については、第12章「Business Transaction Managementの起動および停止」を参照してください。

2. アプリケーション・サーバーのデプロイメント・ツールとInstall_Dir\archivesにある新しいEARファイルを使用して、各セントラル・サーバーを再デプロイします。

3. セントラル・サーバーを再起動します。
12.1.0.5より古いリリースからアップグレードする場合、セントラル・サーバーの再起動によってBusiness Transaction Managementデータのインプレース・アップグレードが開始されます。このプロセスの間、システムにパフォーマンスの低下が発生したり、データが一時的に使用できなくなる可能性があります。このプロセスは、30分以内に完了します。単に12.1.0.5のインストールにパッチを適用する場合、システムは通常の速度で起動します。

Business Transaction Managementコンポーネントの起動については、第12章「Business Transaction Managementの起動および停止」を参照してください。

4. すべてのBusiness Transaction Managementユーザーに、Webブラウザのキャッシュをフラッシュするよう通知します。
管理コンソールには、多くのAdobe Flashウィジェットが含まれています。Webブラウザは通常このようなウィジェットをキャッシュし、キャッシュをフラッシュするかWebブラウザを再起動するまでキャッシュされた古いウィジェットを使用し続けます。

5. モニター(btmMonitor.ear)を停止し、Install_Dir\archivesにある新しいEARファイルを使用して再デプロイし、再起動します。
この手順は、すべてのモニターに対して一斉に実行することも、各モニターに対して個別に実行することも可能です。

(省略可能)セントラル・サーバーおよびモニターのアップグレードが完了してシステムが落ち着いた後、次の項の手順に従ってオブザーバをアップグレードすることができます。

2.3 オブザーバのアップグレード

前の項で説明されているように、オブザーバのアップグレードの前にBusiness Transaction Managementセントラル・サーバーおよびモニターをアップグレードする必要があります。

注意:
本インストレーション・ガイドでは、オブザーバをリリース12.1.0.5に含まれているバージョンにアップグレードする手順を説明しています。オブザーバを以前のリリースのバージョンにアップグレードしたい場合は、以前のリリースのインストレーション・ガイドを参照してください。特に、WebLogic 9.2、WebSphere、JBossまたはASP.NET向けのオブザーバをアップグレードする場合は、リリース12.1.0.2.2向けのインストレーション・ガイドを参照してください。

オブザーバのアップグレード手順は、アプリケーション・サーバーおよびオブザーバのタイプによって異なります。オブザーバをアップグレードする手順の詳細は、次の項を参照してください。

- 第2.3.1項「WebLogic 10.3上のオブザーバのアップグレード」

- 第2.3.2項「WCF用のオブザーバのアップグレード」

- 第2.3.3項「Oracle Enterprise Gateway用のオブザーバのアップグレード」

注意:
特定のオブザーバの互換性および機能の詳細は、ZIPファイルを展開した後、オブザーバのnanoagentディレクトリにあるREADME.txtファイルを参照してください。

2.3.1 WebLogic 10.3上のオブザーバのアップグレード

この項では、WebLogic 10.3アプリケーション・サーバーにインストールされたオブザーバをアップグレードする方法について説明します。

リリース12.1.0.3以前では、WebLogic 10.3サーバーにインストールする様々なオブザーバが提供されていました。各オブザーバには、特定の種類のコンポーネントを監視することができる一連のプローブが含まれていました。たとえば、JavaEEオブザーバにはJavaEEコンポーネントを監視するプローブが含まれ、SOAオブザーバにはSOAコンポーネントを監視するプローブが含まれていました。現在のリリースでは、WebLogic 10.3サーバーへのインストール用に提供されているのは、「ユニバーサル」オブザーバおよびOracle Service Bus 10gR3用オブザーバの2つのみです。これらのオブザーバは、次のZIPファイルにパッケージ化されています。

- BTMObserver_Wls_10.3_Universal_*.zip – このZIPファイルには、ユニバーサル・オブザーバが含まれています。次のオブザーバをアップグレードする際に、このZIPファイルを使用します。

- WebLogic 10.3用のJavaEEオブザーバ

- Oracle Fusion Applicationsオブザーバ

- Oracle SOA Suiteオブザーバ

- Oracle Service Bus 11gR1オブザーバ

ユニバーサル・オブザーバは、JavaEE、Oracle SOA Suite、Oracle Service Bus 11gR1およびOracle Fusion Applications (ADF-UI、ADF-BCおよびSOAデプロイメント)を監視できます。

- BTMObserver_Wls_10.3_Osb11gR1_*.zip – このZIPファイルは、Oracle Service Bus 10gR3用のオブザーバをWebLogic 10.3サーバーへインストールする際に使用します。ZIPファイル名には文字列「Osb11gR1」が含まれていますが、このオブザーバはOracle Service Bus 10gR3をサポートしていることに注意してください。このオブザーバは、Oracle Service Bus 11gR1では推奨されません(11gR1では、BTMObserver_Wls_10.3_Universal_*.zipを使用する必要があります)。

制限付きのオブザーバ(JavaEEオブザーバなど)をユニバーサル・オブザーバにアップグレードすると、システムは新しいタイプのコンポーネントを検出して監視できるようになります。システムおよび監視要件によっては、新しいタイプのコンポーネントを監視する必要があるかもしれません。ユニバーサル・オブザーバにアップグレードする前に、必要に応じてオブザーバ通信ポリシーのアクティブなプローブの見直しおよび調整をする必要があります。このトピックの詳細は、「機能のアップグレードの問題」という名前のオンライン・ヘルプのトピックに目を通してください。最初に管理コンソールで「ヘルプ」→「ヘルプ」を選択することによって、このトピックを見つけることができます。オンライン・ヘルプが開いたら、目次ペインで「Oracle Business Transaction Managementの概要」に進み、「機能のアップグレードの問題」の項までスクロール・ダウンします。

注意:
JavaEE、Oracle Fusion Applications、Oracle SOA SuiteまたはOracle Service Busのみを監視する更新されたバージョンのオブザーバが必要な場合は、My Oracle Support (http://support.oracle.com)で支援を依頼するサービス・リクエストを入力してください。

3つのアップグレード・パスに対して、別々の手順が提供されています。使用する手順は、インストール済のオブザーバのタイプおよびリリース・バージョン、WebLogicサーバーがノード・マネージャ構成かスクリプト構成かによって異なります。選択できる手順は、次のとおりです。

- 第2.3.1.1項「12.1.0.4、12.1.0.3または12.1.0.2.2のオブザーバ、OSB 10gR3用オブザーバあるいはJavaEE用12.1.0.2.0オブザーバのアップグレード」

- 第2.3.1.2項「ノード・マネージャ構成サーバー上のSOAまたはOSB 11gR1用12.1.0.2.0オブザーバあるいはJavaEE用11または12.1.0.1オブザーバのアップグレード」

- 第2.3.1.3項「スクリプト構成サーバー上のSOAまたはOSB 11gR1用12.1.0.2.0オブザーバあるいはJavaEE用11または12.1.0.1オブザーバのアップグレード」

2.3.1.1 12.1.0.4、12.1.0.3または12.1.0.2.2のオブザーバ、OSB 10gR3用オブザーバ、JavaEE用12.1.0.2.0オブザーバのアップグレード

WebLogicサーバー上の次のオブザーバをアップグレードするには、この手順を使用します。

- リリース12.1.0.4ユニバーサル・オブザーバ

- リリース12.1.0.3ユニバーサル・オブザーバ

- リリース12.1.0.2.2のすべてのオブザーバ

- JavaEE用リリース12.1.0.2.0オブザーバ

- Oracle Service Bus 10gR3用オブザーバ

1. お使いの環境および監視ニーズに適切なオブザーバ配布ZIPファイルを探します。

2. オブザーバがインストールされているWebLogicアプリケーション・サーバーを停止します。

3. WL_HOME\nanoagentディレクトリのバックアップ・コピーを作成します。
文字列WL_HOMEはWebLogicサーバーのホーム・ディレクトリを表し、WebLogicのインストール・ディレクトリにあるweblogic92、wlserver_10.0またはwlserver_10.3のいずれかのディレクトリです。

4. WL_HOME\nanoagentディレクトリを削除します。

5. オブザーバの配布ZIPファイルをWL_HOMEに解凍します。
ZIPファイルを解凍すると、nanoagentおよびsecurity_add_onsという名前のディレクトリが作成されます。nanoagentディレクトリには、bin、configおよびlibという名前の3つのサブディレクトリが含まれています。

6. WebLogicを実行しているユーザー・アカウントが、最低でも以下の権限を持っていることを確認します。

- nanoagent/configおよびnanoagent/libディレクトリの読取り権限(UNIX系システムでは、トラバース権限も必要)

- libディレクトリ内のすべてのJARファイルの読取り権限

7. 最初にオブザーバをインストールする際に、ノード・マネージャを使用したのではなくスクリプト・ファイルを編集した場合は、新しいオブザーバのスクリプト・ファイルをnanoagentディレクトリにあるバックアップ・コピーのオブザーバ・スクリプト・ファイルで置き換えます。ノード・マネージャを使用する場合は、この手順をスキップします。
Windowsシステムでは、オブザーバ・スクリプト・ファイルは次の場所にあります。

WL_HOME\nanoagent\bin\nanoEnvWeblogic.cmd

UNIX系システムでは、オブザーバ・スクリプト・ファイルは次の場所にあります。

WL_HOME/nanoagent/bin/nanoEnvWeblogic.sh

8. WebLogicサーバーを再起動します。

2.3.1.2 ノード・マネージャ構成サーバー上のSOAまたはOSB 11gR1用12.1.0.2.0オブザーバあるいはJavaEE用11または12.1.0.1オブザーバのアップグレード

WebLogic 10.3ノード・マネージャ構成環境で次のオブザーバを最新のリリースにアップグレードするには、この手順を使用します。

- Oracle SOA Suite用リリース12.1.0.2.0オブザーバ

- Oracle Service Bus 11gR1用リリース12.1.0.2.0オブザーバ

- JavaEE用リリース11または12.1.0.1オブザーバ

1. ユニバーサル・オブザーバ用の配布ZIPファイル(BTMObserver_Wls_10.3_Universal_*.zip)を探します。

2. WebLogic管理コンソール(デフォルトのURLは、http://machine_name:7001/console)を開きます。

3. 管理対象サーバーのクラスパスから、WL_HOME/nanoagent/lib/bootstrap/ap-nano-bootstrap.jarを削除します(この設定はアップグレード元のバージョンのオブザーバによってリクエストされましたが、最新のリリース用に削除する必要があります)。

1. 「ドメイン構造」ペイン(左側)で、「環境」→「サーバー」に移動します。

2. 「サーバー」表で、管理対象サーバーをクリックします。

3. 「構成 / サーバーの起動」タブを表示します。

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

注意:
この手順は、本番環境での操作を想定しているため、WebLogicサーバーの「ロックを自動取得して変更をアクティブ化」の設定は無効になっていることを前提としています。ただし、開発環境ではこの設定が有効である場合も考えられます。その場合は、変更を行うために「ロックして編集」をクリックする必要はなく、保存後に変更をアクティブ化する必要もありません。

5. クラスパス・フィールドから次のようにエントリを削除します。
Windowsシステムでは、次の文字列を削除します。

WL_HOME\nanoagent\lib\bootstrap\ap-nano-bootstrap.jar

UNIX系システムでは、次の文字列を削除します。

WL_HOME/nanoagent/lib/bootstrap/ap-nano-bootstrap.jar

6. このページは開いたままにします。

4. 「構成 / サーバーの起動」タブが表示された状態で、WebLogic起動引数を次のように編集します。

1. 次のように、「引数」フィールドからJVM引数を削除します(これらの設定は以前のリリースのオブザーバによってリクエストされましたが、最新のリリース用に削除する必要があります)。
Windowsシステムでは、次の引数を削除します。

-Daspectwerkz.classloader.preprocessor=com.amberpoint.nanoagent.plugins.APAspectPreProcessor -javaagent:WL_HOME\nanoagent\lib\bootstrap\aspectwerkz-jdk5-2.0.jar

UNIX系システムでは、次の引数を削除します。

-Daspectwerkz.classloader.preprocessor=com.amberpoint.nanoagent.plugins.APAspectPreProcessor -javaagent:WL_HOME/nanoagent/lib/bootstrap/aspectwerkz-jdk5-2.0.jar

2. 次のようにJVM引数を「引数」フィールドに追加することによって、オブザーバ・ブートストラップ・モジュールをサーバーに構成します。
Windowsシステムでは、次の引数を追加します。

-javaagent:WL_HOME\nanoagent\lib\bootstrap\ap-nano-bootstrap.jar

UNIX系システムでは、次の引数を追加します。

-javaagent:WL_HOME/nanoagent/lib/bootstrap/ap-nano-bootstrap.jar

5. 「保存」をクリックし、「変更のアクティブ化」をクリックします。
次のステータスを受信します。

「すべての変更がアクティブ化されました。再起動は不要です。設定が正常に更新されました。」

6. オブザーバがインストールされているWebLogic管理対象サーバーを停止します。

7. WL_HOME\nanoagentディレクトリをWebLogic管理対象サーバーから削除します。
文字列WL_HOMEはサーバーのホーム・ディレクトリを表し、サーバーのインストール・ディレクトリにあるwlserver_10.3ディレクトリです。この手順を忘れないようにするため、文字列WL_HOMEをWebLogicホーム・ディレクトリの実際のパスで置き換えます。

8. オブザーバの配布ZIPファイルをWL_HOMEに解凍します。
ZIPファイルを解凍すると、bin、configおよびlibの3つのサブディレクトリを含むnanoagentという名前のディレクトリが作成されます。

9. WebLogicサーバーを実行しているユーザー・アカウントが、最低でも以下の権限を持っていることを確認します。

- nanoagent/configおよびnanoagent/libディレクトリの読取り権限(UNIX系システムでは、トラバース権限も必要)

- libディレクトリ内のすべてのJARファイルの読取り権限

10. オブザーバを最初にインストールする際に<filter>および<filter-mapping>要素をWebアプリケーションのweb.xmlファイルに挿入した場合は、これらの要素を削除する必要があります。
web.xmlファイルから削除する要素は、次のとおりです。

<filter>
<filter-name>ORACLE_BTM_WEB_APP_OBSERVER</filter-name>
<filter-class>
com.amberpoint.nanoagent.bootstrap.servlet.FilterHandlerBootstrap
</filter-class>
</filter>
<filter-mapping>
<filter-name>ORACLE_BTM_WEB_APP_OBSERVER</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

11. WebLogicサーバーを再起動します。

2.3.1.3 スクリプト構成サーバー上のSOAまたはOSB 11gR1用12.1.0.2.0オブザーバあるいはJavaEE用11または12.1.0.1オブザーバのアップグレード

WebLogic 10.3スクリプト構成環境で次のオブザーバを最新のリリースにアップグレードするには、この手順を使用します。

- Oracle SOA Suite用リリース12.1.0.2.0オブザーバ

- Oracle Service Bus 11gR1用リリース12.1.0.2.0オブザーバ

- JavaEE用リリース11または12.1.0.1オブザーバ

注意:
最初にオブザーバをインストールした際は、WebLogicインストールで定義されているすべてのサーバーにインストールしたか、特定のドメインのサーバーにインストールしたかのどちらかです。グローバル・インストールという用語は、オブザーバをすべてのサーバーにインストールすることを示し、ドメイン・インストールという用語はオブザーバを特定のドメインにインストールすることを示します。

次の手順で、nanoagentディレクトリおよびその内容を置換します。オブザーバをグローバル・インストールでインストールした場合、nanoagentディレクトリはWebLogicサーバーのホーム・ディレクトリ、すなわちWebLogicのインストール・ディレクトリにあるwlserver_10.3ディレクトリにあります。

オブザーバをドメイン・インストールでインストールした場合、nanoagentディレクトリはドメイン・ディレクトリの中にあります。この場合、オブザーバをインストールした各ドメインでこの手順を繰り返す必要があります。

1. ユニバーサル・オブザーバ用の配布ZIPファイル(BTMObserver_Wls_10.3_Universal_*.zip)を探します。

2. オブザーバがインストールされているWebLogicアプリケーション・サーバーを停止します。

3. オブザーバ・スクリプト・ファイルのバックアップ・コピーを作成します。
オブザーバ・スクリプト・ファイルとは、nanoagent/binディレクトリ内にあるnanoEnvWeblogic.cmdまたはnanoEnvWeblogic.shファイルです。

4. nanoagentディレクトリを削除します。

5. nanoagentディレクトリを削除したディレクトリにオブザーバ配布ZIPファイルを解凍します。
ZIPファイルを解凍すると、bin、configおよびlibの3つのサブディレクトリを含むnanoagentという名前のディレクトリが作成されます。

6. WebLogicを実行しているユーザー・アカウントが、最低でも以下の権限を持っていることを確認します。

- nanoagent/configおよびnanoagent/libディレクトリの読取り権限(UNIX系システムでは、トラバース権限も必要)

- libディレクトリ内のすべてのJARファイルの読取り権限

7. 新しいオブザーバ・スクリプト・ファイルを編集用に開き、設定をコピーするためにバックアップ・コピーを開きます。

8. 新しいオブザーバ構成ファイルのNANOAGENT_HOMEおよびNANOAGENT_CONFIGURATION_URL変数の値が、バックアップ・コピーの値と一致していることを確認します。

9. オブザーバを最初にインストールする際に<filter>および<filter-mapping>要素をWebアプリケーションのweb.xmlファイルに挿入した場合は、これらの要素を削除する必要があります。
web.xmlファイルから削除する要素は、次のとおりです。

<filter>
<filter-name>ORACLE_BTM_WEB_APP_OBSERVER</filter-name>
<filter-class>
com.amberpoint.nanoagent.bootstrap.servlet.FilterHandlerBootstrap
</filter-class>
</filter>
<filter-mapping>
<filter-name>ORACLE_BTM_WEB_APP_OBSERVER</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

10. WebLogicサーバーを再起動します。

2.3.2 WCF用のオブザーバのアップグレード

この項では、WCF用オブザーバをアップグレードする方法について説明します。

1. オブザーバ配布ファイル(BTMObserver_Iis_7.5_DotNet4_*.zip)を一時ディレクトリ(以降、observer_tempと表記)に解凍します。
ZIPファイルを解凍すると、configおよびlibの2つのサブディレクトリを含むnanoagentディレクトリが作成されます。libディレクトリには、オブザーバのDLLファイルが含まれています。

2. 新しいDLLのバージョン番号を書きとめます。
バージョン番号を調べるには、いずれか1つのDLLファイルのWindowsプロパティ・ダイアログ・ボックスを開き、バージョン・タブをクリックします。

3. gacutil.exeまたはWindowsエクスプローラを使用して、observer_temp\nanoagent\libからグローバル・アプリケーション・キャッシュ(GAC、通常はC:\WINDOWS\assembly)にすべてのDLLファイルをコピーします。

4. テキスト・エディタを使用して、最初にオブザーバをインストールする際に追加したオブザーバ構成コードを含むアプリケーション構成ファイルを開きます。
ファイルは、machine.configまたはweb.configファイルのどちらかです。

5. アプリケーション構成ファイルで、2回出現し、オブザーバのDLLバージョン番号を示しているVersion属性を探します。
Version属性を含む要素は </behaviorExtensions>要素の中にあり、次のようになっています。

<add name="APEPInterceptor" type="AmberPoint.NanoAgent.DotNet.Wcf.APEPBehaviorExtnElem, AmberPoint.NanoAgentWCF, Version=64000.64000.25233.19024, Culture=neutral, PublicKeyToken=d8685c0afbb35893"/>

<add name="APServiceInterceptor" type="AmberPoint.NanoAgent.DotNet.Wcf.APServiceBehaviorExtnElem, AmberPoint.NanoAgentWCF, Version=64000.64000.25233.19024, Culture=neutral, PublicKeyToken=d8685c0afbb35893"/>

6. 新しいオブザーバDLLのバージョン番号と一致するようにVersion属性の設定を編集し、保存してファイルを閉じます。

注意:
オブザーバをマシン上の複数のweb.configファイルに構成した場合は、各ファイルのVersion属性を編集します。

7. 省略可能 – 古いオブザーバのDLLをGACから削除します(マシン上の他のオブザーバに使用されている場合を除く)。
各オブザーバDLLの名前は、文字列「AmberPoint」で始まります。DLLを削除するには、右クリックしてアンインストールを選択します。

注意:
ASP.NET用のオブザーバは、WCF用のオブザーバと同じDLLの多くを使用します。マシン上にASP.NET用のオブザーバをインストールしている場合は、そこで使用されているバージョンのDLLは削除しないでください。

2.3.3 Oracle Enterprise Gateway用のオブザーバのアップグレード

この項では、Oracle Enterprise Gateway用オブザーバをアップグレードする方法について説明します。

1. Enterprise Gatewayサーバーを停止します。

2. オブザーバに関係するすべてのJARファイルをOEG_HOME/ext/libから削除します。OEG_HOMEはEnterprise Gatewayサーバーのホーム・ディレクトリ(最上位のインストール・ディレクトリ)です。
オブザーバ関連のJARファイルは、「ap-」から始まるファイルと、次のファイルです。

orahttp_client_1.0.0.jar
orawsdl_1.0.0.jar
xstream-1.2.2.jar

3. オブザーバZIPファイル(BTMObserver_OEG_11.1.1.6_OEG_*.zip)を一時ディレクトリ(以降、observer_tempと表記します)に解凍します。
ZIPファイルを解凍すると、config、libおよびscriptsという名前の3つのディレクトリが作成されます。

4. libディレクトリにあるすべてのJARファイルをOEG_HOME/ext/libにコピーします。

5. テキスト・エディタで、OEG_HOME/system/conf/jvm.xmlを開き、<JVMSettings>要素内を次のように変更します。

1. 次の行(<JVMSettings>要素の最初の子要素)を探します。

<SystemProperty name="AP_NANO_CONFIG_URL" value="http://Host_Name:Port_Number/btmmonitor/agent/agent/"/>

2. <JVMSettings>要素の2番目、3番目および4番目の子要素として、次の行を追加します。

<SystemProperty name="AP_NANO_HOME" value="$VDISTDIR/NanoAgent"/>
<SystemProperty name="AP_NANO_LOG_BASEDIR" value="$VDISTDIR/NanoAgent"/>
<SystemProperty name="AP_NANO_CLASSLOADER_BASEDIR" value="$VDISTDIR/ext/lib"/>

3. 省略可能 – オブザーバ構成ラベルでオブザーバのターゲットを指定する場合は、<JVMSettings>要素の5番目の子要素として次の行を追加します。

<SystemProperty name="ap.nano.config.label" value="My_Label_String"/>

My_Label_Stringは、このオブザーバで使用するラベルの文字列で置換します。オブザーバのターゲット指定の詳細は、第7.5項「オブザーバ通信ポリシーの適用」を参照してください。

6. Enterprise Gatewayサーバーを再起動します。

3 インストールの概要

この章では、Business Transaction Managementのインストール手順全体の概要を示します。

3.1 インストールの概要

1. セントラル・サーバーのインストールおよび初期構成は、次の手順に従います。

1. 省略可能 – セントラル・サーバーのセキュリティを構成します。必要な場合は、この段階でモニターおよびオブザーバのセキュリティ構成も実行できます。
第4章「セキュリティの構成」を参照してください。

2. サポートされているWebブラウザがインストールされていることを確認します。
第5.1項「Webブラウザの要件」を参照してください。

3. オブザーバがWSDLおよびスキーマ・リソースにアクセスできることを確認します。
第5.2項「WSDLおよびスキーマ・リソースへのアクセス」を参照してください。

4. セントラル・サーバーをホストするアプリケーション・サーバーを構成します。
第5.3項「WebLogic環境の設定」を参照してください。

5. Business Transaction Managementデータベースを設定します。
第5.4項「Business Transaction Managementデータベースの設定」を参照してください。

6. 省略可能 – 永続記憶域ディレクトリを構成します。
第6.2項「永続記憶域ディレクトリの構成」を参照してください。

7. セントラル・サーバーをデプロイします。
第6.3項「セントラル・サーバーのデプロイ」を参照してください。

8. 必要に応じて、アプリケーション・サーバーでBusiness Transaction Managementユーザー・ロールを再マッピングします。
第6.4項「ユーザーのロールへのマッピング」を参照してください。

9. Business Transaction Managementの初期構成を実行します。
セントラル・サーバーのデプロイ後、ブラウザ・ベースの構成ウィザードを使用してセントラル・サーバーを構成します(第6.5項「Business Transaction Managementの初期構成」を参照)。

または、コマンドライン・スクリプトを使用することも可能です(第14章「Oracle Business Transaction Managementのスクリプトによる構成」を参照)。ただし、初回の構成にはブラウザ・ベースのウィザードの使用を推奨します。ウィザードは、コマンドライン・スクリプトによる以降の構成に使用できるXMLの出力ファイルを生成します。

10. Oracle Enterprise Managerサーバーの場所を構成します。
第6.6項「Enterprise Managerへの接続の構成」を参照してください。

2. モニターのインストールおよびオブザーバ通信ポリシーの構成(第7章「モニターのインストール」を参照)は、次の手順に従います。

1. 省略可能 – まだ行っていない場合は、モニターのセキュリティを構成します。
第4章「セキュリティの構成」を参照してください。

2. モニターをホストするアプリケーション・サーバーを構成します。
第5.3項「WebLogic環境の設定」を参照してください。

3. モニターをデプロイします。

4. オブザーバ通信ポリシーを使用して、モニターとオブザーバ間の通信を構成します。

3. オブザーバのインストール(第8章「オブザーバのインストールの概要」を参照)は、次の手順に従います。

1. 省略可能 – まだ行っていない場合は、オブザーバのセキュリティを構成します。
第4章「セキュリティの構成」を参照してください。

2. オブザーバ・ライブラリをインストールします。

3. オブザーバで、モニターを見つけるための構成を行います。

4 セキュリティの構成

この章では、Business Transaction Managementのセキュリティ構成の方法を説明します。この章の内容は必ずよく読むようにしてください。また、セキュリティを構成する場合は、Business Transaction Managementコンポーネントをインストールする前に、関連する実行環境のセキュリティ構成を行う必要があります。

Business Transaction Managementのセキュリティは、次のメカニズムを使用して構成することができます。

- HTTPSで通信を行うようにアプリケーション・サーバーを構成するネットワーク・レベルのセキュリティ。
HTTPSを使用して通信する管理コンポーネントでは、このセキュリティ・メカニズムによって、一方向または双方向の認証、メッセージの整合性および通信経路上のメッセージ・データの暗号化が実現されています。詳細は、第4.2項「ネットワーク・レベルのセキュリティ設定」を参照してください。

- Business Transaction Managementコンポーネント間でHTTP(S)通信を行うためのBusiness Transaction Managementのビルトイン・セキュリティ。
このセキュリティ・メカニズムによって、HTTP(S)を使用して通信する管理コンポーネント間に信頼関係ができ、機密の通信データ要素をシリアライズする前(すなわち、回線に送信されたりディスクに格納される前)に暗号化できるようになります。詳細は、第4.3項「アサーション秘密および暗号化鍵の構成」を参照してください。

- Observation Protocol Secure (OPS)を使用してオブザーバからモニターへ監視メッセージを送信するためのBusiness Transaction Managementのビルトイン・セキュリティ。OPSとは、オラクル社が独占的な権利を有するセキュア・ソケット(SSL)によるObservation Protocol (OP)です。
このセキュリティ・メカニズムによって、オブザーバとモニター間の認証、メッセージの整合性および通信経路上の監視メッセージの暗号化が実現されています。サーバー認証(オブザーバに対するモニターの認証)は、SSLによって提供されます。クライアント認証(モニターに対するオブザーバの認証)はOPSによって提供されます。詳細は、第4.4項「監視メッセージ用のセキュア・ソケット(SSL)の設定」を参照してください。

4.1 通信プロトコルおよびデプロイメント・シナリオ

Business Transaction Managementは分散環境での使用を前提に設計されています。そのため、遠隔データ・センター、DMZまたは集中データベースにアクセスできないネットワークにデプロイされるコンポーネントが存在する可能性もあります。次の表では、様々なBusiness Transaction Managementコンポーネント間や、それらのコンポーネントとビジネス・サービス間で必要になるアクセスのタイプについて説明しています。

表4-1 Business Transaction Management通信プロトコル

通信元コンポーネント

必要なプロトコル

通信先コンポーネント

説明

図での表示

各セントラル・サーバー(メイン、トランザクションおよびパフォーマンス・サーバー)

HTTPまたはHTTPS

他のセントラル・サーバー

セントラル・サーバーは相互に通信できる必要があります。通常のデプロイメント・トポロジでは、各セントラル・サーバーは同じネットワーク・ゾーンに配置されます。

A

各セントラル・サーバー

HTTPまたはHTTPS

すべてのモニター

各セントラル・サーバーはすべてのモニターと通信できる必要があります。セントラル・ネットワーク・ゾーンの外側にデプロイされているモニターも同様です。

B

メイン・サーバー

TCP、HTTPまたはHTTPS

すべての監視対象ビジネス・サービス

「稼働中」であるか(動作しているか停止しているか)を判断するために、メイン・サーバーは監視対象のビジネス・サービスと通信できる必要があります。なお、稼働ステータスを判断するために使用する厳密なプロトコルは、サービスごとに構成できます。(このプロトコルの構成の詳細は、My Oracle Supportでサービス・リクエストを入力してください。)

C

各モニター

HTTPまたはHTTPS

すべてのセントラル・サーバー

モニターは各セントラル・サーバーと通信できる必要があります。

D

各モニター

JDBC

メッセージ・ログ・データベース(messageLogDB)

各モニターは、JDBCを使用してメッセージ・ログ・データベースの書込みおよび読込みができる必要があります。メッセージ・ログ・データベースは、すべてのモニターが使用する信頼できるネットワーク内の単一データベースでも構いません。または、モニターがDMZや集中データベースにアクセスできないネットワークにある場合は、リモート・モニター用に1つ以上のデータベースをデプロイすることもできます。

E

各オブザーバ

TCPおよびHTTPまたはHTTPS

関連付けられたモニター

各オブザーバには、関連付けられたモニターへのコネクションが2つ必要です。オブザーバは、モニターから構成をダウンロードするためにHTTP(S)コネクションを使用します。監視メッセージをモニターに送信するために、オブザーバはTCPによるObservation Protocol (OP)またはセキュア・ソケットによるObservation Protocol Secure (OPS)を使用して接続します。モニター・グループに対しては、これらのコネクションはモニター・グループの前にあるロード・バランサに対して作成されます。ソケット・ポート番号は、オブザーバ通信ポリシーで構成します。

F

トランザクション・サーバー

JDBC

すべてのメッセージ・ログ・データベース

省略可。トランザクション・サーバーは、メッセージ・ログ・データベースに直接アクセスできる必要はありません。ただし、このようなアクセスを可能にすることによって、メッセージ・ログ問合せのパフォーマンスを改善できます。可能な場合は常にこの通信チャネルを有効にしてください。

G

メイン・サーバー

JDBC

スフィア・データベース(sphereDB)

メイン・サーバーは、JDBCを使用してスフィア・データベースに書き込みできる必要があります。

H

パフォーマンス

JDBC

測定データベース(measurementDB)

パフォーマンス・サーバーは、JDBCを使用して測定データベースに書き込みできる必要があります。

I

トランザクション

JDBC

トランザクション・データベース(transactionDB)

トランザクション・サーバーは、JDBCを使用してトランザクション・データベースに書き込みできる必要があります。

J

(モニター・グループ内の)モニター

JDBC

モニター・グループ・データベース

特定のモニター・グループ内の各モニターは、JDBCを使用して同じモニター・グループ・データベースに書き込みができる必要があります。

K

次の図に、様々なデプロイメント・シナリオでBusiness Transaction Managementコンポーネントに必要となるアクセスのタイプを示します。なお、図中の丸印のついた文字は、表4-1「Business Transaction Management通信プロトコル」との相互参照用です。

- 図4-1「デプロイされたBusiness Transaction Managementコンポーネントおよびビジネス・サービス」

- 図4-2「セントラル・サーバー内およびセントラル・サーバーとモニター間の通信コネクション」

- 図4-3「Business Transaction Managementコンポーネントとデータベース間のコネクション」

- 図4-4「モニターとオブザーバ間の通信コネクション」

- 図4-5「メイン・サーバーとビジネス・サービス間の通信コネクション」

図4-1 デプロイされたBusiness Transaction Managementコンポーネントおよびビジネス・サービス

図4-2 セントラル・サーバー内およびセントラル・サーバーとモニター間の通信コネクション

図4-3 Business Transaction Managementコンポーネントとデータベース間のコネクション

図4-4 モニターとオブザーバ間の通信コネクション

図4-5 メイン・サーバーとビジネス・サービス間の通信コネクション

4.2 ネットワーク・レベルのセキュリティ設定

Business Transaction Managementコンポーネントに対してネットワーク・レベルのセキュリティを有効にしたい場合、コンポーネントがデプロイされているアプリケーション・サーバーが提供するSSL/TLSを使用して実現することができます。SSLによってあるサーバーから別のサーバーへと流れる管理トラフィックが暗号化され、分散管理コンポーネント間の通信におけるメッセージの整合性および機密保持が実現されています。クライアント証明書とともに構成すると、SSLによる管理コンポーネント間の相互認証も実現できます。Business Transaction ManagementはSSLの特殊なサポートは行わないため、標準のSSL構成の妨げにはなりません。そのため、Business Transaction Managementのトラフィックの安全性を高めるために、アプリケーション・サーバーでサポートされているすべての構成を使用することができます。Business Transaction Managementコンポーネントをインストールする前に、まずアプリケーション・サーバーがSSL用に適切に構成されていることを確認することを強くお薦めします。

Business Transaction Managementをデプロイするアプリケーション・サーバーでSSLを構成し、テストした後、Business Transaction Managementをインストールし、その後にブラウザ・ベースの初期構成ウィザードを使用してBusiness Transaction Managementを構成します。初期構成の際には、必要なSSLアドレスおよびポート番号を指定します。Business Transaction Managementコンポーネントは自動的に安全な転送方法で通信します。

注意:
オブザーバおよびモニターは、監視メッセージの送信に使用するソケット接続および管理系のメッセージに使用するHTTP/HTTPS接続という2つの個別のチャネルで相互に通信します。ソケット接続用のSSLの設定は、第4.4項「監視メッセージ用のセキュア・ソケット(SSL)の設定」で説明しています。HTTPS接続の設定はこれとは無関係の別のタスクで、アプリケーション・サーバーのセキュリティ機能を使用して行います。

4.2.1 HTTPSの構成

この項は、コマンドライン・インタフェース(CLI)を含むすべてのBusiness Transaction Managementコンポーネントに関係しています。

セントラル・サーバーをHTTPSのみの環境(すなわち、コンポーネント間にHTTPトラフィックが発生しない環境)にインストールする場合、次のいずれかを実行する必要があります。

- セントラル・サーバーをホストしているアプリケーション・サーバーが、HTTPSポートのみをリスニングしていることを確認します。
または

- HTTPSアクセスのみを許可していることを指定するために、各セントラル・サーバーのWARファイルにパッケージ化されている各web.xmlファイルを変更します。これは、前述のファイルで提供されている次の<security-constraint>要素のコメントを解除することのみで実現できます。

<security-constraint>
<display-name>Require SSL communication</display-name>
<web-resource-collection>
<web-resource-name>All AmberPoint system services</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>

4.2.2 WebLogic ServerのJSEEプロパティ設定

WebLogicサーバーでHTTPS通信を行うための構成の一部として、サーバーで多くのJavaシステム・プロパティを設定する必要があります。これらのプロパティは、WebLogicサーバーがセキュリティ・ストアにアクセスするために必要な情報を指定するものです。プロパティ内で指定する情報は、次のとおりです。

注意:
次のリストにおいて、双方向SSLとは、相互認証を必要とするSSL接続を指しています。一方向SSLとは、サーバー認証のみを必要とするSSL接続を指しています。

- クライアントのトラスト・ストアの場所(一方向または双方向SSLに必要)

- トラスト・ストアのタイプ(一方向または双方向SSLに必要)

- トラスト・ストアにアクセスするためのパスワード(一方向または双方向SSLに必要)

- サーバーのキー・ストアの場所(双方向SSLに必要)

- キー・ストアのタイプ(双方向SSLに必要)

- キー・ストアにアクセスするためのパスワード(双方向SSLに必要)

WebLogicサーバーでは、javax.net.ssl.* (JSEE)プロパティまたはweblogic.security.* プロパティのどちらかによって、この情報を指定できます。WebLogicサーバーは、どちらのタイプのプロパティからでもこの情報を読み込むことができます。一方、Business Transaction Managementも同じ情報へのアクセスが必要ですが、JSEEプロパティ以外からは読み込むことができません。このため、JSEEプロパティのみ、またはweblogic.security.*およびJSEEプロパティの両方を設定して、必要な情報を提供できます。JSEEプロパティが設定されていない場合、Business Transaction Managementコンポーネントの起動は失敗します。

注意:
WebLogic管理コンソールの「環境」→「サーバー」→「サーバー名」→「構成」→「SSL」→「詳細」タブで「JSSE SSLの使用」チェック・ボックスの選択を解除している場合でも、JSEEプロパティを設定する必要があります。

WebLogic管理コンソールまたはWebLogicサーバー起動スクリプトによって、JavaオプションとしてJSEEプロパティを設定します。次の例は、双方向SSL設定のためのオプションです。

-Djavax.net.ssl.trustStore=path_to_my_trustStore

-Djavax.net.ssl.trustStoreType=type_of_my_trustStore

-Djavax.net.ssl.trustStorePassword=my_trustStore_password

-Djavax.net.ssl.keyStore=path_to_my_keyStore

-Djavax.net.ssl.keyStoreType=type_of_my_keyStore

-Djavax.net.ssl.keyStorePassword=my_keyStore_password

次の例は、WindowsのWebLogicサーバー起動スクリプトでWebLogic Demoセキュリティ・ストアを使用して双方向SSL用のJSEEプロパティを設定する方法を示しています。

set JAVA_OPTIONS=-Djavax.net.ssl.trustStore=C:\Oracle\Middleware\wlserver_10.3\server\lib\DemoTrust.jks -Djavax.net.ssl.trustStoreType=JKS -Djavax.net.ssl.trustStorePassword=MyTrustStorePassword -Djavax.net.ssl.keyStore=C:\Oracle\Middleware\wlserver_10.3\server\lib\DemoIdentity.jks -Djavax.net.ssl.keyStoreType=JKS -Djavax.net.ssl.keyStorePassword=MyKeyStorePassword %JAVA_OPTIONS%

これらのプロパティをWebLogicサーバー起動スクリプトで設定する場合、必ず次の行の前に前述の行を挿入してください。そうしないと、JAVA_OPTIONSの値が上書きされる可能性があります(最初の例はWindows用で、次の例はUNIX系オペレーティング・システム用です)。

set SAVE_JAVA_OPTIONS=%JAVA_OPTIONS%

SAVE_JAVA_OPTIONS="${JAVA_OPTIONS}"

注意:
HTTPS環境でWebLogic Scripting Tool (WLST)を使用するには、weblogic.security.*プロパティが必要です。

4.2.3 コマンドライン・インタフェース用のJSEEプロパティ設定

HTTPS環境でBusiness Transaction Managementコマンドライン・インタフェース(CLI)を使用している場合は、第4.2.2項でWebLogicサーバーに設定したものと同じJSSEプロパティを設定する必要があります。次の例は、CLIのビルトイン変数であるAP_OPTSを使用したJSSEプロパティの設定方法を示しています。この例は、WebLogic Demoセキュリティ・ストアを使用しています。

set AP_OPTS=-Djavax.net.ssl.trustStore=C:\Oracle\Middleware\wlserver_10.3\server\lib\DemoTrust.jks -Djavax.net.ssl.trustStoreType=JKS -Djavax.net.ssl.trustStorePassword=MyTrustStorePassword -Djavax.net.ssl.keyStore=C:\Oracle\Middleware\wlserver_10.3\server\lib\DemoIdentity.jks -Djavax.net.ssl.keyStoreType=JKS -Djavax.net.ssl.keyStorePassword=MyKeyStorePassword

4.2.4 ファイアウォールの構成

この項は、セントラル・サーバー、モニターおよびオブザーバに関係しています。

ファイアウォールを使用している場合、Business Transaction Managementコンポーネントが通信を受け取る各ポートにアクセスできるように構成する必要があります。対象となるポートには、次のものがあります。

- ホストとなるアプリケーション・サーバーがリスニングしているポート

- モニターがオブザーバからの監視メッセージを受信するソケット

- Business Transaction ManagementデータベースへのJDBC接続に使用されるポート。このデータベースについては、第5.4項「Business Transaction Managementデータベースの設定」を参照

4.3 アサーション秘密および暗号化鍵の構成

注意:
この項で説明されている構成を選択する場合、Business Transaction Managementセントラル・サーバー、モニターまたはオブザーバをホストしているすべてのアプリケーション・サーバーでこの構成を選択する必要があります。Business Transaction Managementコマンドライン・インタフェース(CLI)を使用する実行環境でも、この構成を行う必要があります。

Business Transaction Managementコンポーネント間の通信は、信頼できるアサーションによって安全なものとなります。つまり、Business Transaction Managementコンポーネントが相互に通信し、インストールされたBusiness Transaction Managementが正しく機能するためには、すべてのBusiness Transaction Managementコンポーネントが同じ値のアサーション秘密で構成されている必要があります。

Business Transaction Managementは、コンポーネント間の通信に含まれる機密データの暗号化も行います。データの暗号化は、通信経路上およびBusiness Transaction Managementデータベースの記憶域の両方で行われます。

このようなセキュリティ・メカニズムはデフォルトで有効で、すべてのBusiness Transaction Managementコンポーネントはデフォルトのアサーション秘密および暗号化鍵であらかじめ構成されています。このデフォルトのセキュリティ構成によって、セキュリティ・メカニズムが完全に有効化されているとともにBusiness Transaction Managementのインストールが簡単になっています。

一方、すべてのインストールされたBusiness Transaction Managementは同じデフォルト値を持っているため、デフォルト値を使用することは潜在的なセキュリティの脅威となります。デモ用、または開発環境では、デフォルト値で十分かもしれません。ただし、本番環境では、一意の値を指定してセキュリティを強固にする必要があります。また、Business Transaction Managementを本番環境にデプロイする前に使用するテスト環境でも独自の値を使用する必要があります。アサーション秘密および暗号化鍵に独自の値を指定する場合は、コンポーネントをデプロイする前にBusiness Transaction Managementコンポーネントをホストしている各アプリケーション・サーバーで構成を行う必要があります。

WebLogicサーバーにデプロイするコンポーネントでは、これらのセキュリティ設定を構成し格納するために使用する方法を、Oracle Wallet (第4.3.1項を参照)またはBusiness Transaction Management拡張プロパティ(第4.3.2項を参照)のどちらかから選択することができます。(Oracle Walletは、Oracle資格証明ストア・フレームワークすなわちOCSFの実装で、Javaプラットフォーム・セキュリティすなわちJPSのコンポーネントです。)その他のJavaアプリケーション・サーバーおよびOracle Enterprise Gatewayでは、Business Transaction Management拡張プロパティを使用します。必要に応じて、これらのセキュリティ構成方法を混在させることも可能です。たとえば、あるアプリケーション・サーバーではOracle Walletを使用し、別のアプリケーション・サーバーではBusiness Transaction Management拡張プロパティを使用することも可能です。

4.3.1 Oracle Walletによるセキュリティ構成

この項は、WebLogicアプリケーション・サーバーにデプロイするセントラル・サーバー、モニターおよびオブザーバに関係しています。ここでは、Oracle Walletを使用したBusiness Transaction Managementコンポーネント用のアサーション秘密および暗号化鍵の構成方法について説明します。この手順は、Oracle Walletを使用してアサーション秘密および暗号化鍵を構成する各セントラル・サーバー、モニターおよびオブザーバで繰り返す必要があります。

1. Business Transaction ManagementコンポーネントをインストールするWebLogicドメインに、Java Required Files (JRF)テンプレートが含まれていることを確認します。
ドメインが存在しない場合は、ドメインを作成する際に必ずJRFテンプレートを追加するようにします。ドメインがすでに存在し、JRFテンプレートが含まれていない場合は、ドメインを拡張してテンプレートを追加します。

JRFテンプレートには、後の手順で参照するJPS JARファイルが含まれています。(JPSはOracle Platform Security Servicesのコンポーネントです。)

2. アサーション秘密および暗号化鍵を格納する資格証明の名前を決定します。

名前は自由に選択できますが、それぞれの2つの資格証明は別の名前とする必要があります。また、すべてのBusiness Transaction Managementコンポーネントで同じ2つの資格証明の名前を使用する必要があります。

3. 発行者名および発行者のアサーション秘密の値を決定します。

この文字列の値は自由に選択できますが、すべてのBusiness Transaction Managementコンポーネントで同じ値を使用する必要があります。

4. Business Transaction Managementセントラル・サーバー用の配布アーカイブを探し、セキュリティを構成するセントラル・サーバー、モニターまたはオブザーバをホストしているマシン上のディレクトリ(以降、このディレクトリをBTM_Central_Expandedと表記します)に展開します。
配布アーカイブはBTM_Servers*.zipという名前です。「*」はバージョン番号です。

5. 以下の手順に従い、setBtmOverriderEnv_via_CredStoreスクリプト・ファイルを構成します。

setBtmOverriderEnv_via_CredStoreスクリプト・ファイルを構成することによって、アプリケーション・サーバーのクラスパスへのJPS JARファイルの追加、デフォルトの資格証明ストアのオーバーライド、共通秘密鍵および暗号化鍵が格納されている資格証明の名前の指定(なお、資格証明は後の手順で作成します)が実現できます。

1. BTM_Central_Expanded/security_add_onsの中から、setBtmOverriderEnv_via_CredStoreスクリプト・ファイルを探します。
Windowsシステムでは、setBtmOverriderEnv_via_CredStore.cmdを使用します。UNIX系システムでは、setBtmOverriderEnv_via_CredStore.shを使用します。

2. スクリプト・ファイルをWebLogicサーバーにコピーします。
すべてのドメインでセキュリティを構成する場合は、スクリプト・ファイルをWebLogicサーバーのホーム・ディレクトリにコピーします。ホーム・ディレクトリとは、WebLogicのインストール・ディレクトリにあるweblogic92またはwlserver_10.3ディレクトリで、たとえばC:\bea\wlserver_10.3です。

特定のドメインに対してセキュリティを構成する場合は、スクリプト・ファイルをドメインのディレクトリのトップ・レベルにコピーします。

3. テキスト・エディタでスクリプト・ファイルを開きます。

4. 文字列>>> YOUR_ISSUER_SECRET_CREDENTIAL_NAME_HERE <<<をアサーション秘密の資格証明の名前で置換して、BTM_TIS_CRED_NAME変数にアサーション秘密が格納されている資格証明の名前を設定します。

5. 文字列>>> YOUR_ENCRYPT_KEY_CREDENTIAL_NAME_HERE <<<を暗号化鍵の資格証明の名前で置換して、BTM_ENCKEY_CRED_NAME変数に暗号化鍵が格納されている資格証明の名前を設定します。

6. スクリプト・ファイルを保存して閉じます。

6. 次の手順に従い、setBtmOverriderEnv_via_CredStoreスクリプト・ファイルを呼び出すように、WebLogicのドメイン起動スクリプトを構成します。

注意:
この手順では、startWebLogicスクリプトを変更していないことを仮定しています。スクリプトを変更している場合は、それに応じたインストール手順の変更が必要な場合があります。

1. セキュリティを構成するWebLogicドメインの1つでbinディレクトリに移動し、テキスト・エディタで起動スクリプトを開きます(Windowsシステムではbin\startWebLogic.cmdを、UNIX系システムではbin/startWebLogic.shを開きます。ドメイン・ディレクトリの直下にある起動スクリプトは編集しないでください)。

2. 次の行を探します(最初の行はWindowsの場合、次の行はUNIX系システムの場合)。

call "%DOMAIN_HOME%\bin\setDomainEnv.cmd"

. ${DOMAIN_HOME}/bin/setDomainEnv.sh

3. この行の直後に、setBtmOverriderEnv_via_CredStoreスクリプト・ファイルを呼び出す行を追加します。
Windowsシステムですべてのドメインのセキュリティを構成する場合は、次の行を追加します。

call "%WL_HOME%\setBtmOverriderEnv_via_CredStore.cmd"

UNIX系システムですべてのドメインのセキュリティを構成する場合は、次の行を追加します(最初のピリオドと空白に注意してください)。

. ${WL_HOME}/setBtmOverriderEnv_via_CredStore.sh

Windowsシステムで特定のドメインのセキュリティを構成する場合は、次の行を追加します。

call "%DOMAIN_HOME%\setBtmOverriderEnv_via_CredStore.cmd"

UNIX系システムで特定のドメインのセキュリティを構成する場合は、次の行を追加します(最初のピリオドと空白に注意してください)。

. ${DOMAIN_HOME}/setBtmOverriderEnv_via_CredStore.sh

4. セキュリティを構成する各ドメインで、この手順を繰り返します。

7. 次の手順に従い、ポリシー・ストアにBusiness Transaction Managementコンポーネント用の権限付与を追加します。

1. セキュリティを構成するWebLogicドメインの1つでconfig\fmwconfigディレクトリに移動します。
このディレクトリは、JRFテンプレートを含めるようにドメインを拡張した際に作成されたもので、oracle.security.jps.configプロパティが検索するデフォルトの場所となっています。

2. テキスト・エディタでsystem-jazn-data.xmlファイルを開きます。

3. セキュリティを構成するドメイン内の各デプロイメントで、次の例のように文字列Your Deployment Name Hereをデプロイメント名で置換し、<jazn-data>/<jazn-policy>要素の子要素として<grant>要素を追加します。

<jazn-data>
<jazn-policy>
(... other <grant> elements, etc. ...)

<!-- Begin of Business Transaction Management grants -->
<grant>
<grantee>
<codesource>
<url>file:${domain.home}/servers/${weblogic.Name}/tmp/_WL_user/Your Deployment Name Here/-</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>
oracle.security.jps.service.credstore.CredentialAccessPermission
</class>
<name>context=SYSTEM,mapName=BTM,keyName=*</name>
<actions>read,write</actions>
</permission>
</permissions>
</grant>
<!-- End of Business Transaction Management grants -->

(... other <grant> elements, etc. ...)
</jazn-policy>
</jazn-data>

表1-1は、セントラル・サーバーおよびモニターのデプロイメント名の一覧です。オブザーバには、監視するビジネス・アプリケーションを含むデプロイメント名を使用します。

4. ファイルを保存して閉じます。

5. セキュリティを構成する各ドメインで、この手順を繰り返します。

8. 次の手順に従い、Business Transaction Managementコマンドライン・インタフェース(CLI)を使用してアサーション秘密を含む「信頼できる発行者と秘密」の資格証明を作成し、先ほど構成したポリシー・ストアに関連付けられたOracle Wallet資格証明ストアに追加します。
次の手順では、最初にCLI用の環境を設定し、次にCLIをOracle Wallet資格証明ストアに向け、最後にCLIを使用してアサーション秘密用の資格証明を作成し、ストアに追加しています。

1. コマンド・シェルまたはコマンド・ウィンドウを開き、JAVA_HOMEおよびJPS_11_HOME環境変数が正しく設定されていることを確認します。
これらの変数は、システムまたはシェルおよびウインドウ・レベルで設定されます。JAVA_HOME変数は、バージョン6以上のJDKを指している必要があります。JPS_11_HOME変数は、次の例のようにoracle.jpsファイルを指している必要があります。

oracle\Middleware\oracle_common\modules\oracle.jps_11.1.1

2. テキスト・エディタでBTM_Central_Expanded/security_add_ons/jps_config_dir/jps-config.xmlファイルを開き、次の行を探します。

<serviceInstance name="credstore" provider="credstoressp" location="./">

3. 次の例のように、location属性の値を./からWebLogicドメイン・ディレクトリ内の/config/fmwconfig/ディレクトリに変更します。

<serviceInstance name="credstore" provider="credstoressp" location="C:/Oracle/Middleware/user_projects/domains/my_domain/config/fmwconfig/">

location属性の値は、手順7でドメイン用にポリシー・ストアを構成した%DOMAIN_HOME%\config\fmwconfigディレクトリの場所と一致している必要があります。

4. コマンド・シェルまたはウィンドウでBTM_Central_Expanded/toolsディレクトリに移動し、次のコマンドを実行します(my_credential_nameは、手順5dで選択したこの資格証明の名前で置換します)。

btmcli credStoreTool -createCred my_credential_name -credType is

CLIから、「信頼できるアサーション発行者」および「信頼できるアサーション秘密」が求められます。後者は、入力した文字がアスタリスクで表示されます。

5. 「信頼できるアサーション発行者」および「信頼できるアサーション秘密」の値を入力します(次の手順のために、コマンド・シェルまたはウィンドウは開いたままにします)。
手順3で選択した値を使用します。

注意:
対話モードを使用したくない場合は、コマンドラインに-credValue my_issuer:my_secretを追加することによって発行者名およびアサーション秘密を指定することも可能です。ただし、対話モードを使用する方が、マスキングされるため安全です。

この時点で、アサーション秘密の資格証明は作成され、Oracle Wallet資格証明ストアに追加されています。

9. 同じコマンド・シェルまたはウィンドウで、CLIを使用して次のコマンドを実行し、暗号化鍵用の資格証明を作成します(my_credential_nameは、手順5eで選択したこの資格証明の名前で置換します)。

btmcli credStoreTool -createCred my_credential_name -credType bin -genKey AES:128

このコマンドによって、指定された名前の資格証明が作成され、AES 128ビット乱数暗号化鍵が生成され、Oracle Wallet資格証明ストアに追加されます。

10. 次のコマンドを実行して、システム内の他のマシンの構成に使用するために暗号化鍵を検索します(my_credential_nameは、資格証明の名前で置換します)。

btmcli credStoreTool -getCred my_credential_name -credType bin -showSecret

このコマンドは、暗号化鍵の文字列値を返します。この文字列は、システム内の他のマシンを構成する際にコピーする必要があります。

11. Oracle Walletを使用してアサーション秘密および暗号化鍵を構成する各セントラル・サーバー、モニターおよびオブザーバで、必要な手順を繰り返します。ただし、繰り返す際には次の点を変更します。

- 手順2および3はスキップします(最初のマシンで使用したものと同じ資格証明の名前、発行者名および発行者アサーション秘密の値を使用します)。

- 手順9および10のコマンドのかわりに、次のCLIコマンドを実行します(my_credential_nameは資格証明の名前で、my_encryption_key_stringは手順10で取得した文字列で置換します)。

btmcli credStoreTool -createCred my_credential_name -credType bin -credValue my_encryption_key_string

このコマンドによって、指定された名前および暗号化鍵の資格証明が作成され、Oracle Wallet資格証明ストアに追加されます。

4.3.2 拡張プロパティによるセキュリティ構成

この項は、セントラル・サーバー、モニターおよびオブザーバに関係しています。ここでは、Business Transaction Management拡張プロパティを使用したアサーション秘密および暗号化鍵の構成方法について説明します。この手順は、拡張プロパティを使用してアサーション秘密および暗号化鍵を構成する各セントラル・サーバー、モニターおよびオブザーバで繰り返す必要があります。

このセキュリティ・メカニズムには、次の2つの基本的な部分があります。

- このメカニズムの最初の部分は、拡張プロパティを宣言し、値を設定する一連のファイルです。
アサーション秘密および暗号化鍵のそれぞれに拡張プロパティ・ファイルが必要です。両方を設定する場合、2つの拡張プロパティ・ファイルが必要になります。両方の拡張プロパティ・ファイルを同じディレクトリに配置し、オペレーティング・システムのファイル・セキュリティ・メカニズムでファイルを保護します。Business Transaction Managementコンポーネントが実行されるアプリケーション・サーバーは、拡張プロパティ・ファイルを読み込むためのアクセス権を持っている必要があります。詳細は、第4.3.2.1項「拡張プロパティ・ファイルの設定」を参照してください。

- このメカニズムの2つ目の部分は、拡張プロパティ・ファイルを含むディレクトリを指すJavaシステム・プロパティ(.NET環境のオブザーバでは、Windows環境変数)です。詳細は、第4.3.2.2項「ポインタの設定」を参照してください。

4.3.2.1 拡張プロパティ・ファイルの設定

1. 拡張プロパティ・ファイルを格納するディレクトリを作成します。
ディレクトリには、任意の名前が使用できます。(以降の手順では、ディレクトリの名前をext_propsと仮定します。)

2. アサーション秘密を構成する場合は、次の手順を実行します。

1. ext_propsディレクトリ内に、com.amberpoint.SimpleIdentityAssertion.propertiesという名前のファイルを作成します。

2. 次の行をファイルに追加します。

TrustedIssuerOverriderClassName=com.amberpoint.wsclient.TrustedIssuerOverriderByExtProp

3. さらに、次の行をファイルに追加します。

TrustedIssuerSecretOverride=MySecret

MySecretは秘密の文字列です。

4. デフォルトでは、セキュリティ・アサーションの発行者名はAmberPointです。デフォルトの発行者名をオーバーライドする場合、ファイルの3行目に次の行を追加します。

TrustedIssuerNameOverride=MyIssuerName

MyIssuerNameはセキュリティ・アサーションの発行者名です。

5. ファイルを閉じます。

3. 暗号化鍵を構成する場合は、次の手順を実行します。

1. ext_propsディレクトリ内に、com.amberpoint.security.encryption.propertiesという名前のファイルを作成します。

2. ファイルに次の2行を追加します。

SystemDefaultAESKeyOverriderClassName=com.amberpoint.security.util.SystemDefaultAESKeyOverriderByExtProp

aes.defaultKeySize=128

3. さらに、次の行をファイルに追加します。

aes.defaultKey=MyEncryptionKey

MyEncryptionKeyはbase 64でエンコードされたAES 128ビット鍵です。

base 64でエンコードされた暗号化鍵を生成した後、コピー・アンド・ペーストでこのプロパティの値を設定できます。鍵に特殊文字が含まれている場合は、次のように二重引用符で囲む必要があります。

aes.defaultKey="oylJKoTGXTHasOYwtjwA7g=="

4. ファイルを閉じます。

4. オペレーティング・システムのファイル・セキュリティ・メカニズムを使用して、拡張プロパティ・ファイル(com.amberpoint.SimpleIdentityAssertion.propertiesおよびcom.amberpoint.security.encryption.properties)をセキュリティ保護します。
Business Transaction Managementコンポーネントが実行されるアプリケーション・サーバーが、拡張プロパティ・ファイルを読み込むためのアクセス権を持っていることを確認します。

4.3.2.2 ポインタの設定

ポインタを拡張プロパティ・ファイルに設定するために使用する手順は、Business Transaction Managementがデプロイされるサーバーのタイプによって異なります。この項では、次の環境でのポインタの設定方法を説明します。

- Javaアプリケーション・サーバー(第4.3.2.2.1項を参照)

- Oracle Enterprise Gatewayサーバー(第4.3.2.2.2項を参照)

- .NET環境(第4.3.2.2.3項を参照)

4.3.2.2.1 Javaアプリケーション・サーバーへのポインタ設定

1. テキスト・エディタでサーバーの起動スクリプトを開きます。

2. 「com.amberpoint.util.Extension.dir」という名前のJavaシステム・プロパティを作成し、次のように値に拡張プロパティ・ディレクトリの場所を設定します。
Windowsシステムの場合は、次のようにします。

set JAVA_OPTIONS=-Dcom.amberpoint.util.Extension.dir=C:\btm\ext_props %JAVA_OPTIONS%

UNIX系システムの場合は、次のようにします。

JAVA_OPTIONS=-Dcom.amberpoint.util.Extension.dir="/home/btm/ext_props" "${JAVA_OPTIONS}"

注意:
WebLogicサーバーでは、startWebLogicスクリプトのsetDomainEnvを呼び出す部分の後に、この行を追加します。

4.3.2.2.2 Oracle Enterprise Gatewayサーバーへのポインタ設定

1. テキスト・エディタでOEG_HOME/system/conf/jvm.xmlファイルを開きます(OEG_HOMEは、インストールしたEnterprise Gatewayサーバーのトップ・レベル・ディレクトリです)。

2. 「com.amberpoint.util.Extension.dir」という名前のJavaシステム・プロパティを作成し、値に拡張プロパティ・ディレクトリの場所を設定します。
<JVMSettings>要素の子要素として<SystemProperty>要素を追加し、次のようにこのプロパティを設定します。

Windowsシステムの場合は、次のようにします。

<SystemProperty name="com.amberpoint.util.Extension.dir" value="C:\btm\ext_props"/>

UNIX系システムの場合は、次のようにします。

<SystemProperty name="com.amberpoint.util.Extension.dir" value="/home/btm/ext_props"/>

4.3.2.2.3 .NET環境へのポインタ設定

1. 「com.amberpoint.util.Extension.dir」という名前のWindows環境変数を作成し、次のように値に拡張プロパティ・ディレクトリの場所を設定します。

set = C:\btm\ext_props

4.4 監視メッセージ用のセキュア・ソケット(SSL)の設定

オブザーバは、ソケット接続によるオラクル社が独占的な権利を有するObservation Protocol (OP)を使用し、関連付けられたモニターに監視メッセージを送信します。この通信チャネルにセキュア・ソケット(SSL)を設定することによって、監視メッセージをセキュリティ保護することができます。SSLを使用するOPは、Observation Protocol Secure (OPS)と呼ばれています。

このセキュリティ・メカニズムでは、サーバーのみの認証または相互認証を選択することができ、メッセージの整合性、送信中の監視メッセージの暗号化が実現されています。サーバー認証(オブザーバに対するモニターの認証)は、SSLによって提供されます。クライアント認証(モニターに対するオブザーバの認証)はOPSによって提供されます。

サーバー認証には、モニターがアクセスできる正しく構成されたキー・ストアと、オブザーバがアクセスできる正しく構成されたトラスト・ストアが必要です。SSLを有効化するための設定を最小限にとどめるために、Business Transaction Managementはビルトインの事前構成済鍵およびトラスト・ストアを提供しています(構成済のサーバー証明書は、.NETベースのオブザーバにも提供されています)。デモ用、または開発環境には、ビルトインのセキュリティ・ストアで十分かもしれません。ただし、本番環境では、独自のセキュリティ・ストアを指定してセキュリティを強固にする必要があります。なお、これらのセキュリティ・ストアはHTTPS用のネットワーク・レベルのセキュリティ・ストアとは別であることに注意してください。

注意:
クライアント認証メカニズムは、完全にOPSに組み込まれています。いかなる環境でも、クライアント認証用にセキュリティ・ストアを提供する必要はありません。

デフォルトのオブザーバ通信ポリシーでは、監視メッセージ・チャネルがOPS/SSLを使用し、相互認証が必要となる(ビルトイン・セキュリティ・ストアがサーバー認証に使用されている)ように構成されます。独自のものでなくビルトイン・セキュリティ・ストアを使用し、Javaベースのオブザーバのみを使用する場合は、これらのデフォルト設定をそのまま使用することができます。その場合は、以降の構成を行う必要はありません。

サーバー認証に独自のセキュリティ・ストアを使用する場合は、ガイドとして次の手順を使用します。この手順では、自己署名証明書を含む独自のキー・ストアおよびトラスト・ストアの作成およびデプロイの方法を説明しています。

注意:
ビルトイン・セキュリティ・ストアを.NETベースのオブザーバとともに使用する場合は、手順4に飛び、.NETオブザーバをホストするマシンに事前構成済の証明書をデプロイします。事前構成済の証明書は、.NETベースのオブザーバを含むZIPファイルの中のnanoagent\config\ssl\server.cerにあります。

1. 次の手順に従い、適切な証明書および秘密鍵を含むキー・ストアおよびトラスト・ストアを準備します。

1. JDKのkeytoolアプリケーションを探します。

2. 証明書-秘密鍵のペアを含むキー・ストアを生成します。
たとえば、次のkeytoolコマンドによって、「mykeystore.ks」という名前のファイルに証明書-秘密鍵ペアを含むキー・ストアが生成されます。証明書-秘密鍵ペアの別名は「myks」、共通名は「MyMonitor」、アルゴリズムはRSA、証明書および秘密鍵へアクセスするパスワードは「mycertandprivkeypass」、キー・ストアにアクセスするパスワードは「mykeystorepass」です(ファイルが存在しない場合は、このコマンドによって作成されます)。

keytool -genkey -alias myks -dname "CN=MyMonitor" -keyalg RSA -keypass mycertandprivkeypass -storepass mykeystorepass -keystore mykeystore.ks

3. 証明書をキー・ストアから外部ファイルにエクスポートします。
たとえば、次のkeytoolコマンドによって、上の例で作成した証明書が「mycertificate.cer」というファイルにエクスポートされます。

keytool -export -alias myks -storepass mykeystorepass -file mycertificate.cer -keystore mykeystore.ks

4. 証明書を(関連付けられた秘密鍵なしに)トラスト・ストアにインポートします。
たとえば、次のkeytoolコマンドによって、上の例で作成した証明書がファイル「mytruststore.ks」に含まれるトラスト・ストアにインポートされます(トラスト・ストアが存在していない場合は、このコマンドによって作成されます)。

keytool -import -v -trustcacerts -alias myks -file mycertificate.cer -keystore mytruststore.ks -keypass mycertandprivkeypass -storepass mykeystorepass

2. キー・ストアをモニターをホストするマシンにデプロイします。
キー・ストア(たとえば、mykeystore.ks)を、モニターをホストするマシンまたはモニターがHTTP GETでアクセスできる場所にコピーします。

3. トラスト・ストアをJavaベースのオブザーバをホストするマシンにデプロイします(Javaベースのオブザーバがない場合は、この手順は無視します)。
次の2つのいずれかの方法で実行します。

- トラスト・ストア(たとえば、mytruststore.ks)をオブザーバをホストするマシンまたはオブザーバがHTTP GETでアクセスできる場所のどちらかにコピーします。

- トラスト・ストア(たとえば、mytruststore.ks)をモニターをホストするマシンまたはモニターがHTTP GETでアクセスできる場所のどちらかにコピーします。この2つ目の方法を使用する場合、オブザーバ通信ポリシーを構成する際に(第7.5項を参照)「トラスト・ストアをJavaオブザーバへ自動ディスパッチ」フィールドを有効化することによって、モニターが自動的にトラスト・ストアをオブザーバにディスパッチするように構成できます。

4. 証明書を.NETベースのオブザーバをホストするマシンにデプロイします(.NETベースのオブザーバがない場合は、この手順を無視します)。

Windowsの証明書インポート・ウィザードを使用して、証明書(たとえば、mycertificate.cer)を.NETベースのオブザーバをホストするマシンの証明書ストアの「Trusted Root Certification Authorities」フォルダにインポートします。

注意:
監視メッセージのSSL接続は、この項で選択したセキュリティ・ストアに対応する情報でオブザーバ通信ポリシーが構成されるまでは使用できません。オブザーバ通信ポリシーを構成する際には、この情報を参照用に準備しておく必要があります。その際に準備しておく必要がある情報の詳細は、第7.5項「オブザーバ通信ポリシーの適用」の手順4を参照してください。

5 前提条件および予備設定

この章では、Business Transaction Managementのインストールを始める前に満たす必要がある前提条件および予備設定について説明します。Business Transaction Managementは、数種類のコンポーネントで構成されています。次に示す要件には、すべてのBusiness Transaction Managementコンポーネントに関係するものも、一部のコンポーネントに関係するものもあります。

5.1 Webブラウザの要件

この項の要件は、Business Transaction Managementの初期構成およびBusiness Transaction Managementコンソールへのアクセスに使用するWebブラウザに関係します。

- Webブラウザには、Adobe Flashプラグイン・バージョン10.1以上が必要です。

- WebブラウザにInternet Explorerを使用している場合、Flash playerのActive Xコントロールを許可するように構成する必要があります。この設定の手順は、Internet Explorerのドキュメントを参照してください。

5.2 WSDLおよびスキーマ・リソースへのアクセス

Business Transaction Managementオブザーバは、ビジネス・サービスを検出し監視するために、サービスについて記述されているWSDLおよびスキーマ・リソースにアクセスする必要があります。これらのリソースがオブザーバがアクセスできないような方法で(たとえば、認証によって)保護されていないことを確認する必要があります。

たとえば、Oracle Service Bus環境では、sbresouce.warをアンデプロイしたり、オブザーバのWSDL情報へのアクセスを妨げるようなセキュリティ・ロールを適用してはいけません。

5.3 WebLogic環境の設定

注意:
WebLogicノード・マネージャを使用する場合は、スクリプトを編集するかわりにWebLogic管理コンソールを使用して設定を調整することも可能です。

1. Oracle WebLogic Serverをインストールします。
Business Transaction Managementには、WebLogic Serverリリース10.3.6を使用することを推奨します。ソフトウェアは次の場所からダウンロードできます。http://www.oracle.com/technetwork/middleware/weblogic/downloads/wls-main-097127.html

WebLogic Serverリリース10.3.6のインストールの手順は、次の場所にあります。http://docs.oracle.com/cd/E12839_01/doc.1111/e14142/toc.htm

2. Oracle Application Development Framework (ADF)をインストールし、Java Required Files (JRF)テンプレートを使用するようにWebLogic Serverを構成します。Business Transaction Managementには、ADFリリース11.1.1.7を使用することを推奨します。ソフトウェアは次の場所からダウンロードできます。http://www.oracle.com/technetwork/developer-tools/adf/downloads/index.html
ADF 11.1.1.7のインストールの手順は、次の場所にあります。http://docs.oracle.com/cd/E28280_01/install.1111/e14827/toc.htm

第2章に、ADFのインストールの手順の概略が示されています。なお、ADFには、Oracle WSM Policy ManagerおよびOracle WSM-PM Extensionが含まれています。これらのコンポーネントでは、インストールの前に、データベースにMDSスキーマが存在している必要があります。ただし、Business Transaction Managementにはこれらのコンポーネントは必要ではないため、MDSに関する手順はすべてスキップすることができます。

第3章には、JRFの適用に必要な手順の概略が示されています。既存のWebLogic ServerおよびJRFテンプレートを含まないWLSドメインを使用している場合は、サーバーを開始する際に次の例外が発生します。

java.lang.ClassNotFoundException: oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener

3. 各セントラル・サーバーおよびモニターで、WebLogicサーバーのクラスパスにOracle RDBMS用の適切なデータベース・ドライバがあることを確認します。
ドライバは、BTM_Servers_*.zipのjdbcディレクトリにあります。JDK 1.5ではojdbc5.jarを、JDK 1.6ではojdbc6.jarを使用します。

4. セントラル・サーバーおよびモニターをインストールするすべてのWebLogicドメインが、Java Required Files (JRF)テンプレートを含んでいることを確認します。
これらのドメインのいずれかがJRFテンプレートを含んでいない場合、ドメインを拡張してテンプレートを追加します。JRFテンプレートがドメインに含まれてない場合は、サーバーを開始する際に次の例外が発生します。

java.lang.ClassNotFoundException: oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener

注意:
JRFテンプレートは、Oracle Application Development Framework (ADF)ランタイムの一部です。つまり、JRFテンプレートを含むようにドメインを拡張する前に、ADFランタイムをWebLogicにインストールする必要があります。ADFランタイムをインストールする際には、WebLogicのバージョンと一致したリリース・バージョンをインストールするよう注意してください。ADFランタイムは、次の場所からダウンロードできます。

http://www.oracle.com/technetwork/developer-tools/adf/downloads/index.html

5. Business Transaction Managementセントラル・サーバーまたはモニターをインストールする各WebLogicサーバーは、セントラル・サーバーおよびモニターが確実にお互いと接続できるよう、一意に識別できることを確認します。次のいずれかを実行します。

- ホスト・マシンに割り当てられている各IPアドレスによって、そのマシンが一意に識別できることを確認します。

- WebLogicサーバーの「リスニング・アドレス」プロパティがサーバーを一意に識別するホスト名またはIPアドレスに設定されていることを確認します。
このプロパティを設定するには、WebLogic管理コンソールで「環境」→「サーバー」に移動し、対象のサーバーをクリックして「構成/一般」タブを表示します。

注意:
マシンがネットワーク上の他のマシンと共有のIPアドレスを持っている場合、またはマシンが別々の仮想マシンとして扱われる複数のIPアドレスを持っている場合は、ドメインの「リスニング・アドレス」プロパティを前述のように設定する必要があります。

6. セントラル・サーバーおよびモニターでは、WebLogicサーバーへのメモリー割当てが適切に設定されていることを確認します。以下で、メモリー割当てを制御するJavaオプションを設定する2つの方法を説明します。管理対象サーバーの起動および停止方法に応じた適切な方法を使用します。
ノード・マネージャを使用して管理対象のサーバーをリモートで開始および停止する場合は、サーバーのJavaメモリー・オプションを次の方法で設定します。

1. WebLogic Administration Consoleを開きます。

2. 管理対象サーバーを選択します。

3. 「構成」→「サーバーの起動タブを選択します。

4. 次のJavaオプションを「引数」フィールドに入力します。フィールド内のすべてのエントリはスペースで区切ります。
64ビットのホストでは、次のようにします。

-Xms5120m -Xmx5120m -XX:MaxPermSize=512m

32ビットのホストでは、次のようにします。

-Xms3072m -Xmx3072m -XX:MaxPermSize=256m

管理対象サーバーをローカル・スクリプト・ファイルを実行することによって開始および停止する場合は、サーバーのJavaメモリー・オプションを次の方法で設定します。

1. テキスト・エディタで、ドメイン用のsetDomainEnvスクリプト・ファイルを開きます。
WindowsシステムではsetDomainEnv.cmdを、UNIX系システムではsetDomainEnv.shを開きます。これらのスクリプト・ファイルは、インストールしたWebLogicのuser_projects\domains\domain_name\binディレクトリにあります。

2. 次の設定を見つけ、指定された値以上に設定されていることを確認します(環境によっては、これより高い値に設定する必要があるかもしれません)。
64ビットのホストでは、次のようにします。

MEM_ARGS=-Xms5120m -Xmx5120m

-XX:MaxPermSize=512m

32ビットのホストでは、次のようにします。

MEM_ARGS=-Xms3072m -Xmx3072m

-XX:MaxPermSize=256m

このようなエントリはいくつかあります。すべてに設定を行ってください。

WebLogicのバージョンによっては、次のように32ビットと64ビットの設定が別になっている可能性があります。

set WLS_MEM_ARGS_64BIT=-Xms5120m -Xmx5120m
set WLS_MEM_ARGS_32BIT=-Xms3072m -Xmx3072m
set MEM_MAX_PERM_SIZE_64BIT=-XX:MaxPermSize=512m
set MEM_MAX_PERM_SIZE_32BIT=-XX:MaxPermSize=256m

その場合は、すべてを指定された値に設定します。

7. メイン・サーバー(btmMain.ear)をインストールするWebLogicサーバー上に管理ユーザーを設定します。
Business Transaction Managementは、WebLogicで定義されたロールを自身のアプリケーション・ロールにマッピングします。詳細は、第6.4.2項「WebLogicユーザーのBusiness Transaction Managementロールへのマッピング」を参照してください。

5.4 Business Transaction Managementデータベースの設定

Business Transaction Managementシステム・サービスには、永続する情報やログ・メッセージを格納するためにデータベースを使用するものがあります。このデータベースには、Oracle 10gまたは11g RDBMSを使用し、SQL認証モードおよびTCP/IP接続をサポートするように構成する必要があります。

Business Transaction Managementを構成する前に、データベースをインストールし、構成します。

1. Oracle 10gまたはOracle 11gデータベースをインストールします。ソフトウェアは以下からダウンロードできます。http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html
Business Transaction Managementでは、Oracle 11gリリース11.2.0.4の使用が推奨されています。このリリースを簡単にインストールする方法は、My Oracle Supportのパッチ13390677を検索することです。このパッチをダウンロードすると、LinuxまたはSolaris用の完全なインストーラを入手できます。

2. 必要なデータベース・ユーザーを作成します。
次のSQL文を使用して、既存のユーザーを削除し、必要なユーザーを作成します。passwordはそのユーザーのパスワードです。

DROP USER sphereDB CASCADE;
DROP USER transactionDB CASCADE;
DROP USER measurementDB CASCADE;
DROP USER messageLogDB CASCADE;
CREATE USER sphereDB IDENTIFIED BY password;
GRANT CONNECT,
RESOURCE TO sphereDB;
GRANT ANALYZE ANY TO sphereDB;
GRANT
CREATE TABLE,
CREATE VIEW TO sphereDB;
CREATE USER transactionDB IDENTIFIED BY password;
GRANT CONNECT,
RESOURCE TO transactionDB;
GRANT ANALYZE ANY TO transactionDB;
GRANT
CREATE TABLE,
CREATE VIEW TO transactionDB;
CREATE USER measurementDB IDENTIFIED BY password;
GRANT CONNECT,
RESOURCE TO measurementDB;
GRANT ANALYZE ANY TO measurementDB;
GRANT
CREATE TABLE,
CREATE VIEW TO measurementDB;
CREATE USER messageLogDB IDENTIFIED BY password;
GRANT CONNECT,
RESOURCE TO messageLogDB;
GRANT ANALYZE ANY TO messageLogDB;
GRANT
CREATE TABLE,
CREATE VIEW TO messageLogDB;

データベース・ユーザーに関する注意

データベース・ユーザーは同じOracleインスタンスまたは別のインスタンスに作成することができます。ただし、各Business Transaction Managementコンポーネントが必要なデータベースにアクセスできるようにする必要があります。各Business Transaction Managementコンポーネントに必要なデータベース・アクセスの完全な明細は、表4-1「Business Transaction Management通信プロトコル」を参照してください。

Business Transaction Managementを構成する際に(第6.5項「Business Transaction Managementの初期構成」を参照)、システムによって自動的に適切なデータベース表が作成されます。

最初の3つのデータベース(sphereDB、measurementDBおよびtransactionDB)用のスキーマを手動で作成したい場合は、DBAが事前に作成することができます(下記の注意を参照)。これらの表および索引をシステムに自動的に作成させる場合は、データベース・ユーザーに表の作成、索引の作成、ビューの作成および分析の権限が必要です。4番目のスキーマ(messageLogDB)は、監視対象のアプリケーションの変化に応じてシステムが表を動的に作成および削除する必要があるため、事前に手動で作成することはできません。このデータベース用に、ユーザーは表の作成、表の削除、索引の作成、ビューの作成および分析の権限が必要です。なお、ユーザーに関連付けられたロールに権限を割り当てるのみでは十分ではありません。明示的に権限をユーザーに割り当てる必要があります。

注意:
DBAは、datastoreUtilユーティリティを使用してsphereDB、measurementDBおよびtransactionDBデータベース用の表および索引を手動で作成できます。このユーティリティは、適切なスキーマ定義を生成します。このユーティリティを使用したスキーマ定義の生成についてのドキュメントは、第15章「datastoreUtilユーティリティ」にあります。

5.4.1 モニター・グループ・データベースの設定

モニター・グループをデプロイする場合は、モニター・グループのメンバーが、グループ内で情報を共有するためのデータベースを提供する必要があります。特定のモニター・グループ内の各モニターは、JDBCを使用して同じモニター・グループ・データベースに書き込みができる必要があります。モニター・グループのレプリケートされたインスタンスをネットワーク内に広く分散させることはできますが、すべてこの同じデータベースにアクセスできる必要があります。

モニター・グループ・データベース用に、メッセージ・ログ・データベース・スキーマ(messageLogDB)を使用することも、別のスキーマを作成することもできます。別のスキーマを作成する場合、monitorGroupDBをデータベース・ユーザー名に使用することを推奨します。別のスキーマを使用すると、パフォーマンスのボトルネックが発生した場合に、代替ドライブまたは物理ロケーションに再配置できるようになります。

必要に応じて、datastoreUtilユーティリティを使用してモニター・グループ・データベース・スキーマを手動で作成できます(第15章「datastoreUtilユーティリティ」を参照)。スキーマを手動で作成しない場合は、モニター・グループの設定後にシステムによって自動的にスキーマが作成されます。

設定方法を含むモニターの詳細は、第7章「モニターのインストール」を参照してください。

5.4.2 データベース・リソース要件の見積り

Business Transaction Managementデータベースのサイジングの参考として、My Oracle Support (support.oracle.com)でDoc ID 1487044.1 (BTMリリース12cのデータベース・スペース要件の見積り)を参照してください。このドキュメントには、管理者がBusiness Transaction Managementデータベースに必要なリソースの見積りを行う際に役立つスプレッドシートが含まれています。このドキュメントは正確さを増すために更新されるので、常にMy Oracle Supportから最新バージョンを取得するようにしてください。

6 セントラル・サーバーのインストールおよび構成

この章では、Oracle WebLogic 10.3.2から10.3.5へのBusiness Transaction Managementセントラル・サーバーのインストールおよび初期構成の方法について説明します。

6.1 セントラル・サーバーのインストールおよび構成の概要

1. 省略可能 – セントラル・サーバーのセキュリティを構成します。必要な場合は、この段階でモニターおよびオブザーバのセキュリティ構成も実行できます(第4章「セキュリティの構成」を参照)。

2. 以下を含む第5章で説明されているすべての前提条件および設定が満たされていることを確認します。

- 第5.3項「WebLogic環境の設定」

- 第5.4項「Business Transaction Managementデータベースの設定」

3. 省略可能 – 永続記憶域ディレクトリを構成します(第6.2項を参照)。

4. セントラル・サーバーをデプロイします(第6.3項を参照)。

5. ユーザーのBusiness Transaction Managementアプリケーション・ロールへのデフォルト・マッピングを確認し、必要に応じて調整します(第6.4項を参照)。

6. Business Transaction Managementの初期構成を実行します(第6.5項を参照)。

7. Enterprise Managerサーバーの場所を構成します(第6.6項を参照)。

6.2 永続記憶域ディレクトリの構成

初期起動の際、Business Transaction Managementは、システム出力ログ・エントリの収集およびシステム・デプロイメント用のユーザー・プリファレンスの格納用に、一連の永続記憶域ディレクトリを作成します。デフォルトでは、アプリケーション・サーバーのインストール・ディレクトリ内のWL_install_dir/user_projects/domains/domain_name/servers/server_name/btmstorage/*に永続記憶域ディレクトリが作成されます。

永続記憶域についての社内規程の関係で、永続記憶域ディレクトリを別の場所に配置する必要があるかもしれません。その場合は、永続記憶域ディレクトリの場所を再構成できます。

インストールされたBusiness Transaction Managementシステムは、一連のデプロイメント(EARファイル)から構成され、EARファイルは複数のサブデプロイメント(WARファイル)から構成されています。各サブデプロイメントには、その名前から「.war」を除いた名前の関連永続記憶域ディレクトリがあります。次の表には、デプロイメント、サブデプロイメントおよび永続記憶域ディレクトリの名前が示されています。

表6-1 Business Transaction Managementのデプロイメント、サブデプロイメントおよび永続記憶域ディレクトリ

デプロイメント(EAR)

サブデプロイメント(WAR)

永続記憶域ディレクトリ

btmMain

btmui

btmcentral

btmcontainer

btmui

btmcentral

btmcontainer

btmPerformanceServer

btmcontainer

btmperformance

btmcontainer

btmperformance

btmTransactionServer

btmcontainer

btmtransaction

btmcontainer

btmtransaction

btmMonitor

btmmonitor

btmmonitor

6.2.1 永続記憶域ディレクトリの場所の再構成

1. ファイル・システム内の永続記憶域ディレクトリを作成したい場所にディレクトリを作成します。
ディレクトリには、表6-1に示されているデフォルトの名前を付ける必要があります。ディレクトリは空のままにします。

2. Business Transaction Managementセントラル・サーバー用の配布アーカイブを見つけ、任意のディレクトリに解凍します。
配布アーカイブはBTM_Servers*.zipという名前です。「*」はバージョン番号です。アーカイブには、Business Transaction Managementモニターも含まれています。

3. 次の手順に従い、各サブデプロイメントのweb.xmlファイルで指定されているとおりに永続記憶域ディレクトリの場所を変更します。

1. デプロイ用に、記憶域ディレクトリの場所を変更したいWARファイルを探して展開します。

2. テキスト・エディタまたはXMLエディタで、展開したWARファイル内のWEB-INF/web.xmlファイルを開きます。

3. storageDirectoryパラメータの値を編集し、記憶域ディレクトリの新しい場所を設定します。
次の例のように、このパラメータのデフォルトの値はAmberPointDefaultです。

<!-- PERSISTENT STORAGE DIRECTORY
To set the persistent storage area to some value, change the value of param-value to some EXISTING directory where you want things stored.
-->

<context-param>
<param-name>com.amberpoint.storageDirectory</param-name>
<param-value>AmberPointDefault</param-value>
</context-param>

次の例のように、AmberPointDefaultの値を削除し、作成した記憶域ディレクトリへのパスで置き換えます。

Windowsシステムの場合 – btmcentral用の永続記憶域ディレクトリをC:\btm_data\btmcentralとしたい場合、btmcentralのweb.xmlファイル内のデフォルト・エントリを次のように変更します。

<context-param>
<param-name>com.amberpoint.storageDirectory</param-name>
<param-value>C:\btm_data\btmcentral</param-value>
</context-param>

UNIX系システムの場合 – btmcentral用の永続記憶域ディレクトリをopt/webserviceapplogs/btm_data/btmcentralとしたい場合、btmcentralのweb.xmlファイル内のデフォルト・エントリを次のように変更します。

<context-param>
<param-name>com.amberpoint.storageDirectory</param-name>
<param-value>/opt/webserviceapplogs/btm_data/btmcentral</param-value>
</context-param>

4. 場所を再構成する各永続記憶域ディレクトリについて、この手順を繰り返します。

注意:
(セントラル・サーバーに加えて)モニターの永続記憶域ディレクトリ場所を再構成する場合、このタイミングで行っておくと便利です。

4. WARおよびEARファイルを再パッケージ化します。

セントラル・サーバーをアップグレードまたは再インストールする場合、デプロイメント用に永続記憶域ディレクトリの場所を再度定義する必要があるため、永続記憶域ディレクトリの場所を記録しておきます。

6.3 セントラル・サーバーのデプロイ

注意:
この手順では、WebLogic Serverの管理対象インスタンスへのインストールを想定しています。

1. Business Transaction Managementセントラル・サーバーの配布アーカイブを見つけ、任意のディレクトリ(以降、Install_Dirと表記します)に解凍します。
配布アーカイブはBTM_Servers*.zipという名前です。「*」はバージョン番号です。アーカイブには、Business Transaction Managementモニターも含まれています。

注意:
第6.2項で説明している永続記憶域ディレクトリの構成を行っている場合、この手順はすでに完了しています。

2. UNIX系オペレーティング・システム向けの省略可能なセキュリティ・ステップ – 配布アーカイブの構成ファイルに、機能を維持できる最も制限の厳しいレベルのファイル権限を設定したい場合、次のステップを実行します。

1. Install_Dirのトップ・レベルにあるsetPermissions.shを探します。
このスクリプトには、すべての標準ファイルのファイル権限を「所有者 – read/delete」、すべてのディレクトリを「所有者 - read/execute/delete」、すべてのスクリプトを「所有者 – read/execute/delete」に設定するコマンドが含まれています。

注意:
これらは非常に制限の厳しい権限レベルです。たとえば、ファイルを読み取ることができるのは所有者のみです。

2. コマンドラインで、Install_Dirのトップ・レベルから次のコマンドを実行します。

source setPermissions.sh

このコマンドによって、スクリプト・ファイル内のコマンドが実行され、解凍したアーカイブ内のすべてのファイルおよびディレクトリの権限が設定されます。

3. Install_Dir\archivesの中で、次のセントラル・サーバーのアプリケーションEARファイルを探します。

- btmMain.ear

- btmPerformanceServer.ear

- btmTransactionServer.ear

4. WebLogic Serverの管理コンソールを使用し、各EARファイルを一度にデプロイします。
パフォーマンスを考慮し、それぞれ別々のWebLogic Serverインスタンスにデプロイすることが推奨されます。モニター用のサービスまたはコンポーネントをホストしているWebLogic Serverインスタンスには、セントラル・サーバーをデプロイしないでください。セントラル・サーバー・アプリケーションの詳細は、第1章にある「アーキテクチャ」を参照してください。

5. Business Transaction Managementコンポーネントをデプロイしたすべての管理対象サーバーを起動します。

6. デプロイメントを起動します。

7. 永続記憶域ディレクトリの場所を(第6.2項で説明されているように)再構成した場合は、システム出力ログ・エントリが新しい場所に書き込まれていることを確認します。

8. セントラル・サーバーを再インストールしている場合は、すべてのBusiness Transaction ManagementユーザーにWebブラウザのキャッシュをフラッシュするよう通知します。
管理コンソールには、多くのAdobe Flashウィジェットが含まれています。Webブラウザは通常このようなウィジェットをキャッシュし、キャッシュをフラッシュするかWebブラウザを再起動するまでキャッシュされた古いウィジェットを使用し続けます。

6.4 ユーザーのロールへのマッピング

この項では、Business Transaction Managementアプリケーション・ロールおよびロールへのBusiness Transaction Managementユーザーのデフォルトのマッピングについて説明します。このマッピングは、必要に応じてシステム管理機能で再構成できます。

Business Transaction Managementアプリケーション(セントラル・サーバーおよびモニター)は、デプロイ先のアプリケーション・サーバーにユーザーの認証およびユーザーとアプリケーション・ロールの関連付けをゆだねています。

管理コンソールの認証は、デフォルトで有効になっています。認証を無効にしたい場合は、アプリケーション・サーバー上で適切なツールや手順を使用します。認証を無効にした場合でも、管理コンソールのユーザーはログインする必要があります。ただし、どのようなユーザー名でもログインでき、パスワードは必要ありません。ナビゲータ、フィルタおよび列セットの編集などのすべてのUIのパーソナライズは、ユーザー名と関連付けられてプリファレンスとして格納されることに注意してください。

6.4.1 Business Transaction Managementアプリケーション・ロール

Business Transaction Managementコンソールは、ユーザー・インタフェースの様々な機能へのアクセスを認証するロールを使用します。管理コンソールにログインするためには、btmAdmin、btmUserまたはbtmObserverのうちの1つ以上のBTMアプリケーション・ユーザー・ロールにマッピングされている資格証明を使用する必要があります。第6.5項で説明するBusiness Transaction Managementの初期構成を実行するためには、btmAdminロールを持つユーザーとしてログインする必要があります。

6.4.1.1 プライマリ・ロール

各Business Transaction Managementユーザーには、1つ以上のプライマリ・ロールを割り当てる必要があります。プライマリ・ロールには、次のものがあります。

btmAdmin – このロールを持つユーザーには、すべての権限が付与されています。このユーザーは、機密プロパティの表示および作成、すべてのメッセージの内容の表示など、管理コンソールが提供するすべてのツールおよび機能を使用できます。

btmUser – このロールを持つユーザーには、基本的な監視の構成に必要なほとんどの権限が付与されています。たとえば、モニターの構成、ポリシーの作成、編集および削除(システム・ポリシーは除く)、サービスの登録、サービスおよびエンドポイントの登録属性の設定、トランザクションおよび条件の作成および編集を行うことができます。また、btmObserver権限も付与されます。このロールには、Business Transaction Management環境の変更、メッセージの内容へのアクセス、機密プロパティの表示や編集の権限はありません。

btmObserver – このロールを持つユーザーには、基本的な監視機能の使用に必要なほとんどの権限が付与されています。サマリー、依存性および監視しているシステムの管理情報を表示できますが、それに関するポリシーや設定を構成することはできません。また、トランザクションや条件を表示することもできますが、作成や編集はできません。このロールでは、Business Transaction Management環境の変更、メッセージの内容へのアクセス、機密プロパティの表示や編集はできません。

注意:
管理コンソール内のナビゲーションおよびビューは、すべてのプライマリ・ロールで使用可能です。ただし、一部のメニューやメニュー項目、それに関連付けられたツールにアクセスできないロールもあります。

6.4.1.2 補助ロール

Business Transaction Managementでは、プライマリ・ロールに加えて補助ロールも定義されています。補助ロールとは、特定のユーザーに割り当てることができる追加権限です。たとえば、完全な管理権限は与えたくないが、メッセージの内容へのアクセスは許可したい場合があるかもしれません。ユーザーにbtmUserプライマリ・ロールとbtmInspector補助ロールを割り当てることによって、これが可能になります。補助ロールには、次のものがあります。

btmInspector – このロールを持つユーザーは、メッセージの内容の表示、機密プロパティを含むプロパティの表示および作成が可能です。

注意:
btmAdminロールには、すべてのbtmInspector権限が含まれています。

6.4.2 WebLogicユーザーのBusiness Transaction Managementロールへのマッピング

WebLogicサーバーでは、Business Transaction Management管理者のロール(btmAdmin)がWebLogicサーバーで定義されたAdministratorsグループに自動的にマッピングされます。Business Transaction Managementユーザーのロール(btmUser)は、OperatorsおよびMonitorsグループにマッピングされます。Business Transaction Managementオブザーバのロール(btmObserver)は、Everyoneグループにマッピングされるので、すべての認証済ユーザーにオブザーバ権限が付与されます。次の表は、Business Transaction Managementアプリケーション・ロールおよびアプリケーション・サーバー・グループへのデフォルト・マッピングを示しています。

表6-2 WebLogicでのロールのマッピング

Business Transaction Managementアプリケーション・ロール

アプリケーション・サーバー・グループ

btmAdmin

Administrators

btmUser

Operators, Monitors

btmObserver

Everyone

btmInspector (末尾にsは付きません)

btmInspectors (末尾にsが付きます)

注意:
デフォルトでは、btmInspectorロールはbtmInspectorsという名前のグループにマッピングされています。このグループはデフォルトでは存在しないため、アプリケーション・サーバー管理者がグループを作成し、適切なユーザーを割り当てる必要があります。

このデフォルトのマッピングは、WebLogicデプロイメント・ディスクリプタ・ファイル(weblogic.xml)で変更することができます。マッピングを変更する場合は、すべてのBusiness Transaction Managementアプリケーションで変更する必要があります。アプリケーション(EARファイル)の名前は、文字列「btm」で始まります。デフォルト・マッピングの編集の詳細は、WebLogicのドキュメントを参照してください。

6.5 Business Transaction Managementの初期構成

Business Transaction Managementの機能にアクセスする前に、セントラル・サーバーの初期構成を行う必要があります。Business Transaction Managementを初めてインストールする場合は、次で説明するブラウザ・ベースの構成ウィザードを使用する必要があります。ただし、その後のインストールでは、Business Transaction Managementをスクリプトで構成するコマンドライン・インタフェース(CLI)の使用も可能です。詳細は、「Oracle Business Transaction Managementのスクリプトによる構成」を参照してください。

1. セントラル・サーバーが稼働中であることを確認します。

2. WebブラウザでbtmMainのデプロイメントをホストしているサーバーに接続し、管理コンソールを開きます。
次の形式のURLを使用します。

http://host_name:port_number/btmui

管理コンソールのログイン・ページが開きます。

3. btmAdminロールを持つユーザーとしてログインします(このロールの詳細は、第6.4項「ユーザーのロールへのマッピング」を参照)。

4. 構成ウィザードの概要ページが開きます。
「次」をクリックします。「データベース・タイプ」ページが開きます。

5. 「外部データベース」を選択します(「組込みデータベース」は、本番システムではサポートされていません)。
「次」をクリックします。「外部データベースの構成」ページが開きます。

6. Oracleインスタンスへの接続文字列、第5.4項「Business Transaction Managementデータベースの設定」で作成したデータベース・ユーザーのユーザー名およびパスワードを指定します。
別々のOracleインスタンス上にユーザーを作成した場合、複数の接続文字列を入力できるように最初に「カスタム」を選択します。すべてのデータベースに対して単一の接続文字列を使用している場合は、データベースごとに異なるユーザー名が必要になります。

「次」をクリックします。「スフィアURL」ページが開きます。

7. スフィア用のURLが正しいことを確認します。ほとんどの場合(HTTPS環境で使用している場合を除く)、デフォルトで正しい値になっています。

注意:
正しいスフィアURLで「スフィアURLのテスト」リンクをクリックすると、スフィアが初期化されていないことを示す「スフィア・ステータス」ページが表示されます。これは正しい動作で、スフィア・サービスは構成完了時に初期化されます。URLが正しくない場合、ブラウザは「ページが見つかりません」エラーを表示します。

「次」をクリックします。「ローカル・コンテナ設定」ページが開きます。

8. (省略可能)このページで、btmMainをインストールしたネットワーク・ノード用にDNS別名を指定します。
別名を使用すると、ユーザーが手動でサービスを登録するとき、またはシステムが別名アドレスでメッセージ・トラフィックを監視するときに、重複したエンドポイントの作成を回避できます。複数のアドレスはカンマで区切ります。

「次」をクリックします。「パフォーマンス監視コンポーネント」ページが開きます。

9. btmPerformanceServerをデプロイしたURLを、http://HostName:Port/btmcontainer/container/の形式で入力します。
このURLは、「/btmcontainer/container/」で終わる必要があります。この画面を終了する前に、必ずapPerformanceServerをデプロイしてください。

「次」をクリックします。再度「ローカル・コンテナ設定」ページが開きます(btmMainと同じマシンにbtmPerformanceServerをデプロイしている場合を除く)。

10. (省略可能)このページで、btmPerformanceServerをインストールしたネットワーク・ノード用にDNS別名を指定します。
「次」をクリックします。「トランザクション監視コンポーネント」ページが開きます。

11. btmTransactionServerをデプロイしたURLを、http://HostName:Port/btmcontainer/container/の形式で入力します。
このURLは、「/btmcontainer/container/」で終わる必要があります。この画面を終了する前に、必ずbtmTransactionServerをデプロイしてください。

「次」をクリックします。再度「ローカル・コンテナ設定」ページが開きます(btmPerformanceServerまたはbtmMainと同じマシンにbtmTransactionServerをデプロイしている場合を除く)。

12. このページで、btmTransactionServerをインストールしたネットワーク・ノード用にDNS別名を指定します。
「次」をクリックします。「構成のサマリー」ページが開きます。

13. 構成情報が正しいことを確認し、「終了」をクリックします。
Business Transaction Managementは構成の際に入力された情報を検証し、すべての情報が有効だった場合、構成が正常に完了し、Business Transaction Managementコンソールが表示されます。

検証できない構成情報があった場合、Business Transaction Managementはエラー・メッセージを表示します。また、「これらのエラーを無視し、構成が不完全な可能性のあるシステムを続行」というテキストとともにチェック・ボックスが表示されます。通常、構成エラーはすべて修正します。ただし、チェック・ボックスを有効にして「終了」をクリックすることによって、部分的に構成されたBusiness Transaction Managementで先に進むこともできます。部分的に構成されたシステムにアクセスする場合、正常に製品を使用するには構成エラーを訂正する必要があります。たとえば、データベース接続情報が正確でない場合、管理コンソールを使用して再構成する必要があります。初期構成後のデータベースの構成については、Business Transaction Managementオンライン・ヘルプを参照してください。

6.6 Enterprise Managerへの接続の構成

Oracle Enterprise Managerをインストールしている場合は、Business Transaction ManagementがEnterprise Managerに接続できるように、この項で説明する構成手順を実行します。この手順では、以下を行う必要があります。

- Enterprise Managerサーバーの場所を指定します。
この情報によってBusiness Transaction ManagementはJava仮想マシン診断サーバーを見つけることができ、それによって、Business Transaction ManagementUI内の様々な場所からJava仮想マシン診断UIへドリルダウンできるようになります。

この情報を指定しない場合や誤った情報を指定した場合、Java仮想マシン診断UIでドリルダウンする際にエラー・メッセージが表示されます。

この時点でJava仮想マシン診断をインストールしていない場合でも、後でインストールする場合に備えてこの手順を実行しておく必要があります。

- Enterprise Managerリポジトリにアクセスする接続文字列およびユーザー資格証明を指定します。
この情報によって、Business Transaction Managementがトランザクション関連のSLAイベントをEnterprise Managerに送信できるようになり、その情報はEnterprise Managerでイベントやインシデントとして表示されるようになります。なお、イベントを表示するには、Enterprise Managerでトランザクションをビジネス・アプリケーション・ターゲットに関連付ける必要もあります。トランザクションのビジネス・アプリケーション・ターゲットへの関連付けについては、製品をインストールしてからBusiness Transaction Managementオンライン・ヘルプを参照してください。

1. Business Transaction Managementコンソールを開きます。

2. ナビゲータで、「管理」→「システム・サービス」を選択します。

3. メイン・エリアでAP_Sphere_Serviceを選択します。

4. メニュー・バーから、「管理」→「設定データの編集: AP_Sphere_Service」を選択します。

5. 「XMLの編集」ボタンをクリックします。
スフィア・サービス設定XMLファイルが表示されます。

6. ファイルの最後までスクロールし、<pfx6:emgcURL/>要素を探します。

7. 次の例のように、この要素の値にEnterprise ManagerサーバーのベースURLを追加します。

<pfx6:emgcURL>https://myEMhost:5416/</pfx6:emgcURL>

注意:
名前空間の接頭辞は、pfx6以外である可能性があります。XMLテキストに表示されている値を使用してください。

8. <pfx6:emgcURL/>要素のすぐ下にある<pfx6:SphereSetupDataVersion/>要素を探します。

9. <pfx6:SphereSetupDataVersion/>要素を次のコードで置換します。

<pfx6:SphereSetupDataVersion>
<pfx6:emgcRepos>
<pfx1:User>myUserName</pfx1:User>
<pfx1:Password>myPassword</pfx1:Password>
<pfx1:Driver>oracle.jdbc.OracleDriver</pfx1:Driver>
<pfx1:Connection>myDatabaseConnectionString</pfx1:Connection>
<pfx1:DatabaseConnectionVersion/>
</pfx6:emgcRepos>
<pfx6:SphereSetupDataVersion/>
</pfx6:SphereSetupDataVersion>

このコードに対して、以下を行います。

- myUserNameおよびmyPasswordは、Enterprise Managerリポジトリへのアクセス権限があるアカウントのユーザー名とパスワードで置換します。

- myDatabaseConnectionStringは、次のようなEnterprise Managerリポジトリの接続文字列で置換します。

jdbc:oracle:thin:@myhost.mydomain.com:15044:mySID

10. 「適用」ボタンをクリックします。

7 モニターのインストール

この章では、Business Transaction Managementモニターのインストール方法について説明します。シングルトンのモニターおよびモニター・グループの両方のインストール手順を説明します。

シングルトンのモニターとは、オブザーバから直接監視結果を受け取るモニターの単一インスタンスです。モニター・グループとは、ロード・バランサの背後に配置されるレプリケートされたモニター・インスタンスのグループです。モニター・グループの場合、オブザーバは監視結果をロード・バランサに送り、ロード・バランサが監視結果をグループ内のモニターに配布します。

モニターが監視結果を受信できるオブザーバ数には、制限がありません。理論上は、単一のモニターをデプロイしてシステム内のすべてのオブザーバからの監視結果を処理することも可能です。ただし、システムによって生成される監視結果の速度やサイズが大きい場合、単一のモニターでは対応しきれない場合があります。そのような状況では、監視システムのパフォーマンスの低下や、監視データのロストにつながる可能性があります。

複数のモニターをデプロイすることによって、このような潜在的なボトルネックを排除することができます。監視のニーズに必要な数のモニターをデプロイできます。また、モニターは、シングルトン・モニター、モニター・グループまたはこの2つの組み合わせとしてデプロイできます。たとえば、各オブザーバに専用のモニターをデプロイすることも可能です。なお、オブザーバは監視結果を1つのシングルトン・モニターまたはモニター・グループのみに送信できます。シングルトン・モニターの処理より早く監視結果を生成するオブザーバがある場合は、そのオブザーバ向けにモニター・グループをデプロイする必要があります。

モニター・グループを使用することによって、監視システムが拡張できるのみでなく、耐障害性も高まります。モニター・グループには、オブザーバからモニターへメッセージをルーティングするためのTCPをサポートするサードパーティ製ロード・バランサが必要です。モニター・グループには、レプリケートされたモニターのインスタンス間でデータを共有するためのOracle 10gまたは11gデータベースへのアクセスも必要です。これは、他のBusiness Transaction Managementコンポーネントで使用しているデータベースと同じデータベースでも構いません。モニター・グループのレプリケートされたインスタンスをネットワークに広く分散させることはできますが、すべてこの同じデータベースにアクセスできる必要があります(モニター・グループ・データベースの詳細は、第5.4.1項「モニター・グループ・データベースの設定」を参照)。一般的なモニター・グループのデプロイメントを、次の図に示します。

図7-1 一般的なモニター・グループのデプロイメント

7.1 モニターのインストールの概要

この項では、モニターのインストールの際に実行する必要があるタスクの概要について説明します。以降の項で、このタスクの実行方法について詳しく説明します。システムが適切に構成されるように、手順は示されている順番で実行する必要があります。

1. 必要に応じて、セキュリティを構成します(第4章「セキュリティの構成」を参照)。

注意:
セントラル・サーバーでアサーション秘密および暗号化鍵を構成した場合、モニターも同じアサーション秘密および暗号化鍵を使用するよう構成する必要があります。一方、セントラル・サーバーでデフォルトのセキュリティ構成を使用している場合、モニターでもデフォルトのセキュリティ構成を使用する必要があります(第4.3項「アサーション秘密および暗号化鍵の構成」を参照)。

2. 以下を含む第5章で説明されているすべての前提条件および設定が満たされていることを確認します。

- 第5.3項「WebLogic環境の設定」

- 第5.4項「Business Transaction Managementデータベースの設定」

3. 省略可能 – モニター用の永続記憶域ディレクトリを構成します。第6.2項で説明されているセントラル・サーバー用の手順と同じ手順を使用します。

4. モニターのデプロイおよび登録を行います(第7.2項を参照)。

1. セントラル・サーバーがインストール済で稼働中であることを確認します。

2. アプリケーション・サーバーのデプロイメント・ツールを使用して、モニターを対象のアプリケーション・サーバーにデプロイします。

3. registerMonitor CLIコマンドで、モニターを登録します。

5. レプリケートされたモニターの場合のみ – モニター・グループを設定します(第7.3項を参照)。

1. モニター・グループを作成します。

2. モニターをモニター・グループに割り当てます。

6. レプリケートされたモニターの場合のみ – ロード・バランサを構成します(第7.4項を参照)。

7. オブザーバ通信ポリシーを適用します(第7.5項を参照)。

7.2 モニターのデプロイおよび登録

この項は、シングルトンおよびレプリケートされたモニターの両方に関係しています。このタスクは、すべてのインストール・シナリオで実行する必要があります。

1. Business Transaction Managementのセントラル・サービスがインストール済で稼働中であることを確認します。

2. アプリケーション・サーバーのデプロイメント・ツールを使用して、モニターをホストする各アプリケーション・サーバーにbtmMonitor.earデプロイメント・パッケージをインストールします。

注意:
1つのアプリケーション・サーバーに複数のモニターをデプロイしないでください。また、他のBusiness Transaction Managementセントラル・サービスをホストしているアプリケーション・サーバーにモニターをデプロイしないでください。
(Business Transaction Managementコンソールやその他のドキュメントでは、アプリケーション・サーバーをコンテナと呼ぶこともあります。)

3. モニターのデプロイを開始します。

4. registerMonitor CLIコマンドを使用して、デプロイしたそれぞれのモニターを登録します。次に例を示します。

btmcli registerMonitor -e http://my_monitor_host:8080/btmmonitor/agent/agent
-fn My_BTM_Monitor
-s http://localhost:8080/btmcentral/sphere
-l my_admin_username:my_admin_password

表7-1 registerMonitor CLIコマンドのフラグ

フラグ

説明

-e | -endpointUrl

必須です。

登録するモニターのURLを指定します。次に例を示します。

http://my_monitor_host:8080/btmmonitor/agent/agent

ホスト名およびポート番号は、適切な値で置換します。URLは常にbtmmonitor/agent/agentで終わる必要があります。

-fn | -friendlyName

省略可。

モニターのエンドポイントとして、わかりやすい名前を指定します。

-s | -sphereUrl

AP_SPHERE_URL環境変数が設定されている場合を除き、必須です。

スフィアのURLを指定します。次に例を示します。

http://mySphereHost:8080/btmcentral/sphere/

ホスト名およびポート番号は、適切な値で置換します。URLは常にbtmcentral/sphere/で終わる必要があります。

-l | -userLogin

AP_USER_LOGIN環境変数が設定されている場合を除き、必須です。

btmadminロールを持つユーザーの資格証明を、username:password形式で指定します

encryptPassword CLIコマンドを使用してパスワードを暗号化することができます。次に例を示します。

btmcli encryptPassword -password "myPassword"

CLIコマンドの呼出し方法の詳細は、第14章にある「CLIの起動」を参照してください。CLIについてのその他の情報は、Business Transaction Managementオンライン・ヘルプを参照してください。

5. すべてのモニターおよびシステム・サービスが正常に稼働していることを確認します。

7.3 モニター・グループの設定

この項は、レプリケートされたモニターのみに関係します。レプリケートされたモニターを使用する場合、このタスクを実行する必要があります。

1. 次の手順に従い、モニター・グループを作成します。

1. Business Transaction Managementコンソールで、「管理」→「システム・ポリシーの作成」→「モニター・エージェント・グループ」を選択します。

2. モニター・グループの名前を入力します(「バージョン」および「ノート」フィールドに説明を入力することもできます)。

3. データベースへの接続文字列を指定します。
デフォルトの文字列を使用する場合は、中カッコ内のテキスト(および中カッコ自身)をデータベース向けの適切な値で置換します。このデータベースには、モニター・グループのすべてのメンバーがアクセスできる必要があります。モニター・グループ・データベースの詳細は、第5.4.1項「モニター・グループ・データベースの設定」を参照してください。

4. データベースにアクセスするユーザー名およびパスワードを指定します。

5. 「適用」をクリックします。

2. モニターを、直前で作成したモニター・グループに割り当てます。

注意:
モニターがデフォルトのオブザーバ通信ポリシーを使用しない場合は、この項を継続する前に第7.5項「オブザーバ通信ポリシーの適用」を完了させる必要があります。これが必要になるシナリオは、同じマシン内で複数のモニターが実行されている場合です。この場合、異なるソケット・ポートでリスニングする必要があるため、別々のオブザーバ通信ポリシーが必要になります。

1. Business Transaction Managementコンソールのナビゲータで、「管理」→「モニター」を選択します。

2. メイン・エリアで、グループを割り当てるモニターを選択します。

3. 「変更」→「プロファイルの編集: モニター・エージェント」を選択します。

4. 「モニター・グループ」フィールドにモニター・グループの名前を入力します。
この名前は、モニター・グループの登録に使用したモニター・グループ・ポリシーの「名前」フィールドの値と一致している必要があります。

5. 「適用」をクリックします。

7.4 ロード・バランサの構成

この項は、レプリケートされたモニターのみに関係します。レプリケートされたモニターを使用する場合、このタスクを実行する必要があります。

1. HTTP仮想サーバーおよびソケット仮想サーバーの両方を定義し、ロード・バランサをオブザーバと通信できるように構成します。
ロード・バランサには、2つのオブザーバ通信チャネルが必要です。片方はHTTP仮想サーバーと呼ばれ、もう片方はソケット仮想サーバーと呼ばれます。

- HTTP仮想サーバーは、管理目的で使用されます。たとえばオブザーバは、HTTP仮想サーバーを使用してレプリケートされたモニターのいずれかから構成を取得します。

- オブザーバは監視結果データをソケット仮想サーバーに送信し、ロード・バランサはこのデータをレプリケートされたすべてのモニターに配布します。このようなデータを含むメッセージは、監視メッセージと呼ばれます。

注意:
レプリケートされたモニターは、Business Transaction Managementセントラル・サーバーおよびデータベースと、ロード・バランサ経由ではなく、直接通信します。

2. ソケット仮想サーバーのIPアドレスおよびポートを書きとめます。
オブザーバ通信ポリシーを構成する際に、この情報が必要になります(第7.5項を参照)。

3. 監視メッセージをすべてのレプリケートされたモニターに配布するために、次の手順に従ってロード・バランサを構成します。

1. ソケット仮想サーバー用のプールを作成します。

2. モニターが監視結果を受信するポートを割り当てることによって、各モニターにプールを割り当てます。

4. ソケット仮想サーバーのプールに割り当てるモニターのポート番号を書きとめます。
オブザーバ通信ポリシーを構成する際に、この情報が必要になります(第7.5項を参照)。

注意:
すべてのモニターが同じポート番号でリスニングすることによって、オブザーバ通信ポリシーの構成は簡単になります。

5. すべてのレプリケートされたモニターに管理メッセージを配布するために、次の手順に従ってロード・バランサを構成します。

1. HTTP仮想サーバー用のプールを作成します。

2. モニターのアプリケーション・サーバーがリスニングするポートを割り当てることによって、各モニターにプールを割り当てます。

6. オブザーバをホストしているアプリケーション・サーバーで、AP_NANO_CONFIG_URL Javaシステム・プロパティまたはAmberPoint:NanoConfigUrl Windowsキー(プラットフォームによる)がロード・バランサのHTTP仮想サーバー経由でモニターのURLに設定されていることを確認します。
たとえば、HTTP仮想サーバーのIPアドレスが10.147.46.152でポート番号が5072の場合、HTTP仮想サーバーを経由するモニターのURLは、次のようになります。

http://10.147.46.152:5072/btmmonitor/agent/agent/

このトピックの詳細は、第8章「オブザーバのインストールの概要」を参照してください。

7.5 オブザーバ通信ポリシーの適用

この項は、シングルトンおよびレプリケートされたモニターの両方に関係しています。すべてのモニターに、正しく構成されたオブザーバ通信ポリシーを確実に適用する必要があります。次の項で、このポリシーの構成および適用方法を説明します。

- 第7.5.1項「オブザーバ通信ポリシーについて」

- 第7.5.2項「オブザーバ通信ポリシーの適用手順」

- 第7.5.3項「適用する必要があるオブザーバ通信ポリシーの数」

- 第7.5.4項「事前構成済オブザーバ通信ポリシー」

- 第7.5.5項「オブザーバのターゲット指定についての参考情報」

7.5.1 オブザーバ通信ポリシーについて

オブザーバ通信ポリシーは、オブザーバとモニターまたはモニター・グループ間の通信を設定します。デフォルトでは、このポリシーはモニターおよびオブザーバの両方を次のように構成します。

- オブザーバからモニターへの通信チャネルの設定(セキュリティ設定を含む)

- オブザーバ用ランタイム設定の構成(検出および監視されるコンポーネントの種類の選択を含む)

リリース12.1.0.4より前では、1つのモニターに1つのオブザーバ通信ポリシーのみを適用できました。つまり、同じモニターに関連付けられたすべてのオブザーバは、同じ構成を受信していました。オブザーバ構成の柔軟性向上のため、リリース12.1.0.4では1つのモニターに複数のオブザーバ通信ポリシーを適用でき、それぞれのポリシーを異なるオブザーバまたはオブザーバ・セットのターゲットにできるようになりました。

このようなシナリオでは、モニター構成を生成するソースとして1つのポリシーを指定します(これを、「モニター」ポリシーを呼びます)。その後、その他の各ポリシーをオブザーバ構成を生成するソースに指定します(これらを、「オブザーバ専用」ポリシーと呼びます)。

モニター・ポリシーはモニター構成に加えてオブザーバ構成も生成することに注意してください。この構成は、オブザーバ専用ポリシーと同様にオブザーバ・セットにターゲット指定することも、ターゲット指定しないままにすることもできます。ターゲット指定しない場合は、構成によってターゲット指定されていないオブザーバのデフォルトの構成となります。

希望する場合(個別にオブザーバのターゲット指定をする必要がない場合)は、以前のリリースと同様に、モニターおよびそれに関連付けられたすべてのオブザーバの構成に単一のポリシーを使用することもできます。このようなシナリオでは、特定のオブザーバを対象としない「モニター・ポリシー」を使用します。このポリシーはデフォルトのオブザーバ・ポリシーを生成します。特定のオブザーバを対象としていないので、モニターと関連付けられたすべてのオブザーバがこのデフォルトの構成を受信します。

7.5.2 オブザーバ通信ポリシーの適用手順

次の手順は、オブザーバ通信ポリシーの適用方法についての概要レベルでの説明です。この手順の後に、モニターおよびオブザーバに関係するポリシー・フィールドの構成方法の詳細を説明するサブ項目が続いています。

1. モニターの構成に使用するオブザーバ通信ポリシーを開きます(これが「モニター」ポリシーです)。
事前構成済のポリシーのいずれかを編集することも、新しいポリシーを作成することも可能です(事前構成済ポリシーの説明は、第7.5.4項「事前構成済のオブザーバ通信ポリシー」を参照)。

- 事前構成済オブザーバ通信ポリシーを編集するには、次の手順に従います。
ナビゲータで「管理」→「システム・ポリシー」を選択します。

メイン・エリアで編集したい事前構成済ポリシーを選択します。

「変更」→「定義の編集: My_Policy」を選択します。My_Policyはポリシーの名前です。

- 新しいオブザーバ通信ポリシーを作成するには、次の手順に従います。
「管理」→「システム・ポリシーの作成」→「オブザーバ通信」を選択します。

注意:
デフォルトで、「オブザーバ通信ポリシー - デフォルト」という名前の事前構成済ポリシーは、モニター構成の生成およびシステム内のすべてのモニターへの適用の両方を行います。可能な場合は、モニターの構成にこのデフォルトのポリシーを使用してください。モニターの構成に異なるポリシーを使用する場合は、最初にデフォルト・ポリシーを編集し、モニター構成を生成しないようにするか、構成するモニターに適用されないようにするか、どちらか(または両方)になっていることを確認する必要があります。モニターのターゲット指定は、1つのモニター構成でのみ可能です。

2. 「オブザーバのみ対象の構成の生成」チェック・ボックスを解除して、このポリシーをモニター構成を生成するソースに指定します。

3. モニターに関係するポリシー・フィールドを構成します。
手順の詳細は、第7.5.2.1項「オブザーバ通信ポリシーのモニター関連フィールドの構成」を参照してください。

4. モニター・ポリシーによって生成されたオブザーバ構成をデフォルトのオブザーバ構成に使用するか、特定のオブザーバをターゲットにするかを決定します。

注意:
デフォルトでは、「オブザーバ通信ポリシー - デフォルト」という名前のポリシーがターゲット未指定のオブザーバ構成を生成し、これがシステム内のすべてのモニターに適用されます。つまり、デフォルトでは、このオブザーバ構成がシステム内のすべてのオブザーバのデフォルトの構成となります。オブザーバにデフォルトの構成が必要な場合は、このポリシーのオブザーバのターゲットを指定しないままにしてください。一方、デフォルトのオブザーバ構成が不要な場合は、このポリシーを編集してなんらかのオブザーバのターゲットとする必要があります。

5. オブザーバに関するポリシー・フィールドを構成します。
手順の詳細は、第7.5.2.2項「オブザーバ通信ポリシーのオブザーバ関連フィールドの構成」を参照してください。

6. 省略可能 - 追加のオブザーバのターゲットを指定します。

1. 「オブザーバ専用」ポリシーとして使用するために、いずれかの事前構成済ポリシーを開くか新しいポリシーを作成します。

2. 「オブザーバのみ対象の構成の生成」チェック・ボックスを選択して、このポリシーをオブザーバ構成のみを生成するソースに指定します。

3. モニター関連フィールドと、モニター・ポリシーの対応するフィールドの値が一致していることを確認します。

4. オブザーバに関するポリシー・フィールドを構成します。

手順の詳細は、第7.5.2.2項「オブザーバ通信ポリシーのオブザーバ関連フィールドの構成」を参照してください。

7.5.2.1 オブザーバ通信ポリシーのモニター関連フィールドの構成

次の手順で、オブザーバ通信ポリシーのモニター関連のフィールドの構成方法について説明します。この手順では、第7.5.2項「オブザーバ通信ポリシーの適用手順」で説明されているように、編集するポリシーをすでに開いていることを仮定しています。

1. この手順の実行方法は、モニターがシングルトンかレプリケートかによって異なります。

シングルトン・モニターの場合は、次の手順に従います。

1. 「通信パス」フィールドを「直接モニターへ」に設定します(これはデフォルトの設定です)。

2. 「モニターのポート番号」フィールドに、モニターがリスニングするポート番号を指定します。
これは、オブザーバが監視結果を送信し、モニターが監視結果を受信するポートです。この設定は、モニターおよびオブザーバの両方を構成します。

注意:
モニターのホスト名を指定する必要はありません。ホスト名は、AP_NANO_CONFIG_URL Javaシステム・プロパティまたはAmberPoint:NanoConfigUrl Windowsキーから取得されます。オブザーバをインストールするアプリケーション・サーバー上に、このシステム・プロパティまたはキーを設定します(第8.2項を参照)。

レプリケートされたモニターの場合は、次の手順に従います。

1. 「通信パス」フィールドを「ルーターからモニター・グループへ」に設定します。

2. 「ルーターのIPアドレス」および「ルーターのポート番号」フィールドに、ロード・バランサのソケット仮想サーバーのIPアドレスおよびポート番号を指定します。
この設定によって、オブザーバは監視結果をロード・バランサの受信アドレス(第7.4項で構成したロード・バランサのソケット仮想サーバー)に送信するよう構成されます。

3. 「モニターのポート番号」フィールドに、モニターが監視結果を受け取るポート番号を指定します。
この設定によって、モニターは指定されたポートでリスニングするよう構成されます。このポート番号は、第7.4項でロード・バランサのソケット仮想サーバーのプールで割り当てたモニター・ポート番号と一致する必要があります。

注意:
この後にモニター・グループのモニターを追加または削除する場合は、ロード・バランサを適切に再構成する必要があります。

2. オブザーバからモニターへの監視メッセージの転送にセキュリティで保護された接続を使用する場合は、「SSLの有効化」チェック・ボックスを選択したままにし、次の手順に進みます(SSLはデフォルトで有効になっています)。
一方、セキュリティで保護された接続を使用しない場合は、チェック・ボックスの選択を解除し、手順6に進みます。

「SSLの有効化」チェック・ボックスが選択されている場合は、追加のフィールドが表示されます。

3. SSLを有効化した場合は、「プロトコル」フィールドで接続プロトコルを指定します。
TLS 1.0を使用する場合は、「TLSv1」を選択します。

SSL 3.0を使用する場合は、「SSLv3」を選択します(「SSLv3」は.NETベースのオブザーバではサポートされていません。)。

「いずれか」を選択すると、コンポーネントが実行時に最適なプロトコルを決定します。これがデフォルトの設定です。

4. デフォルトでは、SSLが有効化されるとビルトインの事前構成済セキュリティ・ストアが使用されます。これらのビルトイン・セキュリティ・ストアを使用する場合は、サブ手順dに進みます。

独自のセキュリティ・ストアを使用する場合は、「デフォルト・ストアの使用」チェック・ボックスの選択を解除し、以下のすべての手順を実行します(この場合、追加のフィールドが表示されます)。

1. 次のように、モニターのキー・ストア情報を指定します。
キー・ストアの場所 – キー・ストアの場所です。キー・ストア・ファイルがモニターのローカルにある場合は絶対パスで、HTTP GETでアクセスできる場所にある場合はHTTP(S) URLで指定します。

キー・ストア・パスワード – キー・ストアにアクセスするためのパスワードです。

キー・ストア・タイプ – JKS、JCEKS、PKCS12などのキー・ストアのタイプです。

キー名 – 証明書および秘密鍵です。キーの別名または「CN=値, UID=値」などの形式の証明書の属性を指定できます。

キー・パスワード – 証明書および秘密鍵にアクセスするパスワードです。指定されない場合、キー・ストアのパスワードが使用されます。

2. モニターがJavaベースのオブザーバにトラスト・ストアを自動でディスパッチするようにしたい場合は、「トラスト・ストアをJavaオブザーバへ自動ディスパッチ」チェック・ボックスを選択します。

3. 次のように、トラスト・ストア情報を指定します。
トラスト・ストアの場所 – トラスト・ストアの場所です。キー・ストア・ファイルがオブザーバのローカル(自動ディスパッチを使用する場合はモニターのローカル)にある場合は絶対パスで、HTTP GETでアクセスできる場所にある場合はHTTP(S) URLで指定します。

トラスト・ストア・パスワード – トラスト・ストアにアクセスするためのパスワードです。

トラスト・ストア・タイプ – JKS、JCEKS、PKCS12などのトラスト・ストアのタイプです。

4. .NETベースのオブザーバを使用している場合は、第4.4項「監視メッセージ用のセキュア・ソケット(SSL)の設定」の説明に従ってオブザーバをホストしているマシンに適切な証明書をデプロイしていることを確認します。

5. SSLを有効にすると、モニターはオブザーバに対して自身を認証する必要があります。ただし、オブザーバがモニターに対して自身を認証するかどうかは、「オブザーバ認証」フィールドの設定によります。次のいずれかの値でこのフィールドの設定を調整します。
接続認証の使用 – これはデフォルト値で、接続を確立するたびにオブザーバはモニターに対して自身を認証する必要があります。

なし – オブザーバ認証をオフにします。

メッセージ認証の使用 – モニターにメッセージを送信するたびにオブザーバは自身を認証する必要があります。なお、メッセージ認証を使用すると、大幅にパフォーマンスが低下する可能性があります。この設定は、必要な場合のみ使用してください。オブザーバが、(接続ごとではなく)メッセージごとのバランシングを行うロード・バランサで構成されているモニター・グループに対してメッセージを送信する場合、接続認証は使用できません。この場合は、このフィールドを「なし」または「メッセージ認証の使用」のどちらかに設定する必要があります。

6. 「基準」セクションで、ポリシーが正しいモニターに適用されていることを確認します。

「モニター・グループ」句を追加すると、ポリシーを特定のモニター・グループ内のすべてのモニターに適用できます。次に例を示します。

注意:
モニターに適用できるモニター構成を生成するオブザーバ通信ポリシーは、1つのみです。モニター構成を生成するすべての他のオブザーバ通信ポリシーの「基準」セクションでは、このポリシーを適用するモニターを含めないようにするか、このポリシーを適用するモニターを明示的に除外する必要があります。

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

詳細設定については、Business Transaction Managementオンライン・ヘルプを参照してください。

7.5.2.2 オブザーバ通信ポリシーのオブザーバ関連フィールドの構成

次の手順で、オブザーバ通信ポリシーのオブザーバ関連のフィールドの構成方法について説明します。この手順では、第7.5.2項「オブザーバ通信ポリシーの適用手順」で説明されているように、編集するポリシーをすでに開いていることを仮定しています。

1. 「アクティブ・プローブ」セクションで、適切なプローブをアクティブ化または非アクティブ化して検出および監視するビジネス・コンポーネントのタイプを選択します。

注意:
プローブとは、特定のタイプのビジネス・コンポーネントの検出および監視を担当するオブザーバ内のコンポーネントです。ほとんどのタイプのオブザーバには、複数のプローブが含まれています。プローブの詳細は、第1.1項「アーキテクチャ」を参照してください。
JAVAプローブは、ローカルのJava呼出しを監視します。これはほとんどの場合不要です。通常、大量のローカルJava呼出しが発生するので、邪魔になる可能性があるためです。JAVAプローブを使用するには、最初にデプロイおよび構成を行う必要があります。JAVAプローブのデプロイおよび構成の詳細は、My Oracle Support (support.oracle.com)でサービス・リクエストを入力してください。

すでにRMIプローブが非アクティブ化されていない場合、ほとんどの状況でこのプローブを非アクティブ化する必要があります。ほとんどのアプリケーションは、JAX-RPC、JAX-WS、EJBおよびJMSのような高レベルAPIを通してRMIを使用しています。このような場合は、これらの高レベルコンポーネント用のプローブのみをアクティブ化することを推奨します。ただし、アプリケーションが直接RMI呼出しを行う場合は、RMIプローブをアクティブ化する必要があるかもしれません。

パフォーマンスの点からも、その他の理由からも、インストールされていない明示的にプローブを非アクティブ化する必要はありません。アンインストールされたプローブは、元々アクティブ化されていません(プローブがインストールされるのは、プローブを含むオブザーバがインストールされる場合のみです)。プローブを非アクティブ化するのは、(1)プローブがインストールされ、かつ(2)プローブが監視するビジネス・コンポーネントのタイプを監視したくない場合のみです。さらに、いずれかのSOAプローブを非アクティブ化(またはアクティブ化)した場合、すべてのSOAプローブをまとめて非アクティブ化(またはアクティブ化)する必要があります。

コンポーネント・タイプに関連付けられた検出メカニズムをアクティブ化/非アクティブ化するには、「検出の有効化」チェック・ボックスを選択/解除します。あるコンポーネント・タイプの検出がアクティブ化されると、次にメッセージまたは呼出しを受信したタイミングで、そのコンポーネントが検出され、管理コンソールに表示されます。

あるコンポーネント・タイプを検出した際に即時に監視を開始する場合は、「検出時に監視」チェック・ボックスを選択にします。そのタイプのコンポーネントを監視しない場合は、チェック・ボックスの選択を解除します。

注意:
検出を有効にして監視は有効にせず、その後にポリシーを編集して監視を有効化した場合、検出済のコンポーネントの監視は開始されません。システムが監視するのは、監視を有効化した後に検出されたコンポーネントのみです。検出済のコンポーネントの監視の有効化の詳細は、オンライン・ヘルプのトピック「エンドポイントの監視の開始および終了」を参照してください。

2. このポリシーでオブザーバのみを構成している場合、次の手順を実行します。

1. 「通信チャネル」セクション(「オブザーバのみ対象の構成の生成」チェック・ボックスは除くが、「SSL構成」セクションのフィールドは含む)のすべてのフィールドを、モニターの構成に使用するポリシーと一致するように設定します。

2. 「オブザーバのみ対象の構成の生成」チェック・ボックスを選択します。

3. 特定のオブザーバのみにこのポリシーから生成された構成を受信させたい場合、次の手順を実行してターゲットをそのオブザーバに指定します。

1. 「構成ラベル」や「オブザーバのベース・アドレス」フィールドで、ターゲットにするオブザーバを指定します(前述のフィールドや関連するフィールドの詳細は、第7.5.5.1項「オブザーバ構成ラベル」および第7.5.5.4項「オブザーバのターゲット指定フィールドについての参考情報」を参照)。

2. ある「オブザーバ・ポリシー」で指定されたラベルおよびアドレスは、同じモニターに適用される他のポリシーで指定されていないことを確認します(詳細は、第7.5.5.2項「オブザーバ通信ポリシーの拒否」を参照)。

3. 省略可能 – ターゲット指定するすべてのオブザーバがBusiness Transaction Managementに認識されていることを保証するには、「アドレスの検証」チェック・ボックスを選択します。
認識されていないオブザーバをターゲットにしてこのフィールドを選択した場合、ポリシーは拒否されます。現在は認識されていないが、今後認識されるオブザーバをターゲットとする場合は、このフィールドの選択を解除する必要があります。

4. 省略可能 – (複数のモニターにポリシーを適用する場合は、このチェック・ボックスを選択しないでください。)ターゲットとするすべてのオブザーバがポリシーを適用するモニターと関連付けられているかどうかを検証するには、「モニターに施行」フィールドを選択します。

4. 「基準」セクションで、ポリシーが適切なモニターに適用されていることを確認します。
このポリシーでオブザーバのみを構成している場合、これらの設定はモニターの構成に使用するポリシーの設定と一致している必要があります。

5. 「適用」をクリックします。

詳細設定については、Business Transaction Managementオンライン・ヘルプを参照してください。

7.5.3 適用する必要があるオブザーバ通信ポリシーの数

「オブザーバ通信ポリシー - デフォルト」という名前の事前構成済オブザーバ通信ポリシーは、モニターおよびオブザーバの両方の構成を生成し、デフォルトでBusiness Transaction Managementスフィアのすべてのモニターに適用されます。これは、デフォルトでは、すべてのモニターおよびオブザーバがこの単一のポリシーによって構成されることを意味します。単純なデプロイメント・トポグラフィや監視ニーズを満たすには、必要に応じてこのデフォルトのポリシーを単に編集します。複雑なデプロイメント・トポグラフィや監視ニーズに対応するためには、追加のポリシーを適用してモニターおよびオブザーバを他と異なる構成にしなければならない可能性もあります。

ご使用の環境で次のすべての点が該当する場合、オブザーバ通信ポリシーは1つのみ必要であるため、単純にデフォルトのポリシーを編集することができます。

- すべてのモニターがシングルトンまたは単一のロード・バランサの後にあるレプリケートされたモニターである。シングルトンとレプリケートされたモニターが混在する場合や、複数のロード・バランサを使用する場合は、単一のポリシーは使用できません。

- すべてのモニターが同じポート番号で監視結果を受信する。

- モニターが監視結果をSSLで受信する場合、すべてのモニターが同じ秘密鍵や証明書を使用し、セキュリティ・ストアがすべてのモニターおよびオブザーバにとって同じ相対位置にある。

- すべてのオブザーバが同じコンポーネント監視能力を持つように構成される(同じプローブが有効になっている)。

- 一部のモニターおよびオブザーバに対して詳細設定を編集する必要がない。ほとんどの場合、詳細設定はデフォルトのままで構いません。

次の各シナリオでは、追加のオブザーバ通信ポリシーの適用が必要となります。

- モニターが監視結果を異なるポート番号で受信する。この場合、各ポート番号に対して別々のポリシーを適用する必要があります。

- モニターが複数のロード・バランサの後にレプリケートされている。この場合、各ロード・バランサに対して別々のポリシーを適用する必要があります。また、異なるポート番号で(ロード・バランサからの)監視結果を受信するように個々のモニターを構成する場合、ロード・バランサごとに各ポート番号に対する別々のポリシーを適用する必要があります。

- シングルトンおよびレプリケートされたモニターが混在している。この場合、シングルトン・モニターに対してはポート番号ごとに1つのポリシーを適用し、レプリケートされたモニターに対してはポート番号とロード・バランサごとに1つのポリシーを適用する必要があります。

- モニターはSSLで監視結果を受信するが、すべてのモニターが同じ秘密鍵と証明書のペアを使用しない。この場合、各秘密鍵と証明書のペアに対して別々のポリシーを適用する必要があります。

- モニターはSSLで監視結果を受信するが、キー・ストアの場所がモニターによって異なるか、トラスト・ストアの場所がオブザーバによって異なる。この場合、各場所に対して別々のポリシーを適用する必要があります。

- オブザーバによって必要なコンポーネント監視能力が異なる。たとえば、あるオブザーバはOSBプローブをアクティブ化し、SOAプローブを非アクティブ化する必要がある。一方、他のオブザーバはSOAプローブをアクティブ化し、OSBプローブを非アクティブ化する必要がある。この場合、オブザーバが必要とするアクティブ化するプローブの各組合せに対して別々のポリシーを適用する必要があります。

- 一部のモニターまたはオブザーバに対して詳細設定を編集する必要がある。この場合、詳細設定の組合せごとに別々のポリシーが必要です。

7.5.4 事前構成済オブザーバ通信ポリシー

Business Transaction Managementでは、特定の種類のアプリケーションの監視用に事前構成された多くのオブザーバ通信ポリシーが提供されています。これらのポリシーは、監視ニーズに合うよう編集することができます。各ポリシーの名前は太字で表示され、後に説明も表示されます。

- オブザーバ通信ポリシー - デフォルト
このポリシーは、モニター構成および未ターゲット(デフォルト)のオブザーバ構成の両方を生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、異なるポリシーによって個別にターゲット指定されていないすべての関連するオブザーバに配布されます。

- オブザーバ通信ポリシー - Fusionアプリケーション
このポリシーは、オブザーバ構成のみを生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、CONFIG_LABEL_FAPPSラベルでタグ付けされているオブザーバが対象です。Oracle Fusion Applicationコンポーネントを監視するために、この構成によってプローブがアクティブ化され、オブザーバ・ランタイム設定が調整されます。

- オブザーバ通信ポリシー - JavaEE
このポリシーは、オブザーバ構成のみを生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、CONFIG_LABEL_JAVAEEラベルでタグ付けされているオブザーバが対象です。JavaEEコンポーネントを監視するために、この構成によってプローブがアクティブ化され、オブザーバ・ランタイム設定が調整されます。

- オブザーバ通信ポリシー - OSB
このポリシーは、オブザーバ構成のみを生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、CONFIG_LABEL_OSBラベルでタグ付けされているオブザーバが対象です。Oracle Service Busコンポーネントを監視するために、この構成によってプローブがアクティブ化され、オブザーバ・ランタイム設定が調整されます。

- オブザーバ通信ポリシー - SOA
このポリシーは、オブザーバ構成のみを生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、CONFIG_LABEL_SOAラベルでタグ付けされているオブザーバが対象です。Oracle SOAコンポーネントを監視するために、この構成によってプローブがアクティブ化され、オブザーバ・ランタイム設定が調整されます。

7.5.5 オブザーバのターゲット指定についての参考情報

以下のサブ項目は、オブザーバのターゲット指定に関する背景および参考情報です。

- 第7.5.5.1項「オブザーバ構成ラベル」

- 第7.5.5.2項「オブザーバ通信ポリシーの拒否」

- 第7.5.5.3項「優先順位」

- 第7.5.5.4項「オブザーバのターゲット指定フィールドについての参考情報」

7.5.5.1 オブザーバ構成ラベル

オブザーバ構成ラベルとは、オブザーバを概念的に区別するための単純なテキスト文字列(たとえば、CONFIG_LABEL_MY_OBSERVERS)です。ラベルまたはオブザーバがデプロイされているアプリケーション・サーバーのアドレス(たとえば、http://my_host.com:7011)を指定することによって、オブザーバのターゲットを指定できます。指定できるラベルやアドレスの数に制限はありません。また、1つのポリシーでターゲット指定できるオブザーバの数にも制限はありません。

注意:
ラベルがサポートされるのは、Javaプラットフォームのみです。.NETにデプロイされているオブザーバのターゲットを指定する場合は、アドレスを使用する必要があります。

ラベルを使用すると、オブザーバを構成目的で物理的にではなく論理的にグループ分けすることができます。ラベルの適用には、任意の順番で実行できる次の2段階の手順が必要です。

- オブザーバをホストしているアプリケーション・サーバーで、ap.nano.config.labelという名前のシステム・プロパティを作成し、その値にラベル文字列を設定します(このタスクの説明は、アプリケーション・サーバーへのオブザーバ・ライブラリのインストール手順にあります)。

- オブザーバの構成に使用するオブザーバ通信ポリシーの「構成ラベル」フィールドに、ap.nano.config.labelと同じ値を設定します(このタスクの説明は、第7.5.2.2項「オブザーバ通信ポリシーのオブザーバ関連フィールドの構成」にあります)。

7.5.5.2 オブザーバ通信ポリシーの拒否

オブザーバのターゲット指定では、様々な状況でオブザーバ通信ポリシーが意図せず拒否される場合があります。次のシナリオでは、ポリシーが拒否されます。

- 同じモニターに複数のターゲット未指定のポリシー(デフォルトのオブザーバ構成)を適用しようとした

- 同じモニターに適用される2つの異なるポリシーに同じオブザーバ構成ラベルを指定しようとした

- 同じモニターに適用される2つの異なるポリシーに同じオブザーバ・ベース・アドレスを指定しようとした

ラベルは、ポリシーが適用されるモニターにスコープ指定されています。つまり、ポリシーが異なるモニターに適用される場合は特定のラベル名を複数のポリシーで再利用できますが、同じモニターに適用される複数のポリシーではラベル名の再利用はできません。このスコープの原理は、ターゲット未指定のポリシーにも関係します。

ポリシーが拒否された場合は、コンソールの作業領域でポリシーを選択し、「ターゲット」タブを表示します。このタブに、ポリシーの拒否理由が示されています。

7.5.5.3 優先順位

オブザーバがどの構成を受信するかを決定する優先順位は、次のとおりです。

1. オブザーバ・ベース・アドレス
あるポリシーにオブザーバのベース・アドレスが指定されている場合、そのオブザーバはそのポリシーから生成された構成を受信します。

2. オブザーバ構成ラベル
あるポリシーにオブザーバの構成ラベルが指定され、そのオブザーバのベース・アドレスが指定されているポリシーがない場合、そのオブザーバは構成ラベルを指定したポリシーから生成された構成を受信します。

3. ターゲット未指定のポリシー
ターゲット未指定のポリシーがあり、オブザーバのベース・アドレスや構成ラベルを指定しているポリシーがない場合、そのオブザーバはターゲット未指定のポリシーから生成された構成を受信します。

7.5.5.4 オブザーバのターゲット指定フィールドについての参考情報

フィールド名(太字はセクション名)

説明

オブザーバのみ対象の構成の生成

このポリシーでモニターおよびオブザーバの両方の構成を生成したい場合は、このチェック・ボックスを選択しないでください。そのようなポリシーは、モニターに1つのみ適用できます。モニターに追加のポリシーを適用する場合は、このチェック・ボックスを選択する必要があります。チェック・ボックスを選択すると、ポリシーはオブザーバ構成のみを生成します。チェック・ボックスが選択されている場合でも、ポリシーの「通信チャネル」セクション内の他のすべてのフィールドの値を指定する必要があり、それらの値は同じモニターに適用される他のすべてのポリシーと一致している必要があります。

対象のオブザーバ

---------- これはセクションのラベルです ----------
このセクションでは、このポリシーから生成されるオブザーバ構成を受信するオブザーバを指定します。

対象の指定オブザーバ

このポリシーから生成されるオブザーバ構成で特定のオブザーバのみを構成する場合、このチェック・ボックスを選択します。このチェック・ボックスを選択すると、どのオブザーバが構成を受信するべきかを指定する追加のフィールドが表示されます。この追加フィールドで、アドレスやラベルを使用してオブザーバのターゲットを指定します。
このチェック・ボックスを選択しない場合、ポリシーはターゲット未指定となり、ポリシーが適用されるモニターに関連付けられたすべてのオブザーバ向けのデフォルトの構成を生成します。関連付けられたオブザーバがいずれかのポリシーによってターゲット指定されていない場合、デフォルトの構成を受信します。モニターに適用できるターゲット未指定のポリシーは1つのみです。モニターに2つ目のターゲット未指定のポリシーを適用しようとすると、ポリシーは拒否されます。

注意: オブザーバのターゲットは、アドレスとラベルという2つの異なるメカニズムで指定できます。ただし、ある特定のオブザーバに対して同じメカニズムでターゲットを指定できるのは、1つのポリシーのみです。たとえば、ポリシーAがラベルでオブザーバのターゲットを指定する場合、ポリシーBはラベルで同じオブザーバのターゲットを指定することはできません。この場合、ポリシーBは拒否されます。ただし、ポリシーBはアドレスでそのオブザーバのターゲットを指定できます。この場合、アドレスはラベルより優先されるので、オブザーバはポリシーBからの構成を受信します。

構成ラベル

省略可能 – カンマ区切りでオブザーバ構成ラベルのリストを指定します。指定されたラベルのいずれかでタグ付けされたオブザーバが、このポリシーから生成される構成を受信します(別のポリシーがアドレスでオブザーバのターゲットを指定している場合を除く)。このフィールドにはテキストで入力します。大文字と小文字は区別されません。
注意: オブザーバをホストしているアプリケーション・サーバーのap.nano.config.labelという名前のシステム・プロパティによってオブザーバをタグ付けします。ラベルがサポートされるのは、Javaプラットフォームのみです。.NETにデプロイされているオブザーバのターゲットを指定する場合は、アドレスを使用する必要があります。

既知のアドレス

---------- これはセクションのラベルです ----------
省略可能 – このセクションでは、Business Management Transactionの既知のアドレスのドロップダウン・リストからオブザーバのアドレスを.選択できます。指定されたオブザーバが、このポリシーから生成される構成を受信します。

オブザーバのベース・アドレス

このドロップダウン・リストから、オブザーバがデプロイされているコンテナのアドレスを選択します。

[オブザーバ・アドレスの追加]

「オブザーバのベース・アドレス」ドロップダウン・リストに追加するには、このリンクをクリックします。

任意のアドレス

---------- これはセクションのラベルです ----------
省略可能 – このセクションでは、テキスト・フィールドにオブザーバのアドレスを手動で入力できます。指定されたオブザーバが、このポリシーから生成される構成を受信します。

オブザーバのベース・アドレス

このフィールドに、オブザーバがデプロイされているアプリケーション・サーバーのアドレスを手動で入力します。たとえば、http://my_host.com:7011のように入力します。

[オブザーバ・アドレスの追加]

「オブザーバのベース・アドレス」テキスト・フィールドに追加するには、このリンクをクリックします。

アドレスの検証

このポリシーによってターゲットを指定するすべてのオブザーバがBusiness Transaction Managementに認識されていることを保証するには、このチェック・ボックスを選択します。認識されていないオブザーバをターゲットにしてこのフィールドを選択した場合、ポリシーは拒否されます。
現在は認識されていないが、今後認識されるオブザーバをターゲットとする場合は、このフィールドの選択を解除する必要があります。

モニターに施行

ターゲット指定するすべてのオブザーバがポリシーを適用するモニターと関連付けられているかどうかを検証するには、このチェック・ボックスを選択します。
複数のモニターにポリシーを適用する場合は、このチェック・ボックスを選択しないでください。

7.6 モニター・グループ・メンバーの追加および削除

モニター・グループ内のレプリケートされたモニターは、メンバーと呼ばれます。モニター・グループの設定後に、メンバーを追加または削除しなければならないことがあるかもしれません。このような操作は自由に行うことができますが、この項で説明されている手順のとおりに実行する必要があります。

7.6.1 モニター・グループへのメンバーの追加

1. 第7.2項「モニターのデプロイおよび登録」で説明されているように、追加したいモニターのデプロイおよび登録を行います。

2. 第7.3項「モニター・グループの設定」で説明されているように、モニターをモニター・グループのメンバーに割り当てます。

3. 第7.4項「ロード・バランサの構成」で説明されているように、モニターにロード・バランサのソケット仮想サーバー・プールを割り当てます。

7.6.2 モニター・グループからのメンバーの削除

1. ロード・バランサのソケット仮想サーバー・プールからメンバーを削除します。

2. 次の手順に従って、モニター・グループからメンバーを削除します。

1. Business Transaction Managementコンソールのナビゲータで、「管理」→「モニター」を選択します。

2. メイン・エリアで、モニター・グループから削除するメンバーを選択します。

3. 「変更」→「プロファイルの編集: Your_Monitor」を選択します。Your_Monitorは削除するメンバーの名前です。
プロファイルの編集ツールが開きます。

4. 「モニター・グループ」フィールドからモニター・グループの名前を削除します。

5. 「適用」をクリックします。

6. モニターをモニター・グループのメンバーからは削除するが、Business Transaction Managementシステムの一部のままにしておく場合は、ここで終了します。モニターをシステムから完全に削除するには、以降の手順を実行します。

3. アプリケーション・サーバーの管理ツールを使用して、モニターをアンデプロイします。

4. 次の手順に従って、モニターを登録解除します。

1. Business Transaction Managementコンソールのナビゲータで、「管理」→「モニター」を選択します。

2. メイン・エリアでモニターを選択します。

3. 「変更」→「Your_Monitor登録の削除」を選択します。Your_Monitorはモニターの名前です。
モニター登録の削除ツールが開きます。

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

8 オブザーバのインストールの概要

この章では、Business Transaction Managementオブザーバのインストール手順について説明します。オブザーバ・ライブラリのインストールの詳細は別の章で説明されており、この章から相互に参照できます。

8.1 前提条件および予備設定チェックリスト

- Business Transaction Managementセントラル・サーバーがインストール済で稼働中であることを確認します(第6章「セントラル・サーバーのインストールおよび構成」を参照)。

- 1つ以上のモニターがインストールおよび登録済で稼働中であることを確認します(第7章「モニターのインストール」を参照)。

- すべてのシステム・サービスが正常に稼働していることを確認します。
システム・サービスが正常に稼働しているかを確認するには、ナビゲータで「管理」→「システム・サービス」を選択します。すべてのシステム・サービスがサマリー・エリアに表示されます。各システム・サービスが正常に稼働している場合、「システム・サービス・ステータス」列に丸い緑色のアイコンが表示されます。

- オブザーバと関連付けられたモニター(オブザーバが構成を取得し、監視結果を送信するモニター)の間にファイアウォールが存在する場合、オブザーバがモニターにアクセスできるようファイアウォールが構成されていることを確認します。

- 第8.2項の手順4で、特定のURLから構成を取得するようにオブザーバを構成し、オブザーバとモニターを関連付けます。オブザーバがこのURLにアクセスできるようにファイアウォールを構成する必要があります。

- オブザーバ通信ポリシーを構成した際に、オブザーバが監視結果を送信するホストおよびポートを指定しました。オブザーバがこのホストやポートにアクセスできるようにファイアウォールを構成する必要があります。このホストやポートの詳細は、第7.5項「オブザーバ通信ポリシーの適用」の手順1を参照してください。

8.2 一般的なオブザーバのインストール手順

1. オブザーバ用のアサーション秘密および暗号化鍵が、Business Transaction Managementシステムの他のコンポーネントで使用されているものと同じ値に設定されていることを確認します。
Business Transaction Managementシステムのコンポーネントは、内部でセキュリティで保護された通信を行うためにアサーション秘密および暗号化鍵を使用します。Business Transaction Managementサーバー・コンポーネントで、その設定にデフォルト以外の値を使用するよう構成している場合は、オブザーバをホストしている各JVMまたは.NET実行環境が同じ設定値を使用するよう構成する必要があります。このセキュリティ設定の詳しい説明および構成方法は、第4.3項「アサーション秘密および暗号化鍵の構成」を参照してください。

2. 省略可能 – 監視結果メッセージをオブザーバからモニターへ転送するために、オブザーバをホストする実行プラットフォームのSSLセキュリティを構成します。モニターのSSLセキュリティを構成している場合は、関連付けられたオブザーバのSSLセキュリティも構成する必要があります。
第4.4項「監視メッセージ用のセキュア・ソケット(SSL)の設定」を参照してください。

3. オブザーバ通信ポリシーが設定されていることを確認します。
第7.5項「オブザーバ通信ポリシーの適用」を参照してください。

4. アプリケーション・サーバーで、オブザーバ・ライブラリをインストールして構成します。
このタスクの実行手順は、アプリケーション・サーバーおよびオブザーバのタイプによって異なります。手順の詳細は、次の章を参照してください。

- 第9章「WebLogicへのオブザーバ・ライブラリのインストール」

- 第11章「Oracle Enterprise Gatewayへのオブザーバ・ライブラリのインストール」

- 第10章「WCF用のオブザーバ・ライブラリのインストール」

注意:
本インストレーション・ガイドでは、リリース12.1.0.5に含まれているオブザーバをインストールする手順を説明しています。以前のリリースのオブザーバをインストールする場合は、以前のリリースのインストレーション・ガイドを参照してください。特に、WebLogic 9.2、WebSphere、JBossまたはASP.NET向けのオブザーバをインストールする場合は、リリース12.1.0.2.2向けのインストレーション・ガイドを参照してください。
特定のオブザーバの互換性および機能の詳細は、オブザーバZIPファイルを展開した後、オブザーバのnanoagentディレクトリにあるREADME.txtファイルを参照してください。

5. アプリケーション・サーバーでAP_NANO_CONFIG_URL Javaシステム・プロパティまたはAmberPoint:NanoConfigUrl Windowsキーを設定します。
このプロパティやキーにURLを指定することによって、オブザーバはそのURLのモニターと関連付けられます。オブザーバは起動時に指定されたモニターから構成を取得し、監視結果をそのモニターに送信します。URLの例を次に示します。ホスト名およびポート番号のみを編集してください。

http://my_host:8080/btmmonitor/agent/agent/

このプロパティやキーの設定は、アプリケーション・サーバー固有のオブザーバ・ライブラリのインストール手順でも説明されています。

注意:
レプリケートされたモニターを使用している場合は、URLのホストおよびポートの部分にロード・バランサのHTTP仮想サーバーのホストおよびポートを設定する必要があります。たとえば、HTTP仮想サーバーのIPアドレスが10.147.46.152でポート番号が5072の場合、URLを次のように設定します。

http://10.147.46.152:5072/btmmonitor/agent/agent/

ロード・バランサのHTTP仮想サーバーの詳細は、第7.4項を参照してください。

6. 省略可能 – オブザーバ構成ラベルでオブザーバのターゲットを指定する場合は、次の手順を実行します。

- Javaアプリケーション・サーバーの場合 – ap.nano.config.labelという名前のJavaシステム・プロパティを作成し、値にラベル文字列を設定します。

- WCFの場合 – AP_NANO_CONFIG_LABELという名前の環境変数を作成し、値をラベル文字列に設定します。

オブザーバのターゲット指定の詳細は、第7.5項「オブザーバ通信ポリシーの適用」を参照してください。

7. アプリケーション・サーバーを再起動します。

8.3 オブザーバ・ライブラリのデフォルトの場所のオーバーライド

この項は、Enterprise GatewayおよびJavaアプリケーション・サーバーのみに適用されます(WCFおよびASP .NETオブザーバ・ライブラリは、GACにインストールされます)。

デフォルトでは、オブザーバ・ライブラリはAP_NANO_HOME/libにあります。オブザーバ・ライブラリを別の場所に配置する場合は、サーバーでAP_NANO_CLASSLOADER_BASEDIRという名前のJavaシステム・プロパティを作成し、値にライブラリの場所を設定します。

オブザーバは、以下の優先順位に基づいてライブラリを探します(優先順位の高い順)。

1. AP_NANO_CLASSLOADER_BASEDIRシステム・プロパティの値

2. apclassloader.basedir非推奨システム・プロパティの値

3. AP_NANO_HOME/lib

9 WebLogicへのオブザーバ・ライブラリのインストール

この章では、WebLogic 10.3および12サーバーへのオブザーバ・ライブラリのインストールおよびアンインストールの手順を説明します。

Business Transaction Managementオブザーバは、ZIPファイルで配布されます。各ZIPファイルには、特定のアプリケーション・サーバーへのインストールに適した1種類のオブザーバが含まれています。WebLogicアプリケーション・サーバーへのオブザーバのインストールに適したZIPファイルは、次のとおりです。

- BTMObserver_Wls_10.3_Universal_*.zip – このZIPファイルは、JavaEE、Oracle SOA Suite、Oracle Service Bus 11gR1およびOracle Fusion Applications (ADF-UI、ADF-BCおよびSOAデプロイメント)用のオブザーバをWebLogic 10.3サーバーへインストールする際に使用します。

- BTMObserver_Wls_12_JavaEE_*.zip – このZIPファイルは、JavaEE用のオブザーバをWebLogic 12サーバーへインストール際に使用します。

- BTMObserver_Wls_10.3_Osb11gR1_*.zip – このZIPファイルは、Oracle Service Bus 10gR3用のオブザーバをWebLogic 10.3サーバーへインストールする際に使用します。ZIPファイル名には文字列「Osb11gR1」が含まれていますが、このオブザーバはOracle Service Bus 10gR3をサポートしていることに注意してください。このオブザーバは、Oracle Service Bus 11gR1では推奨されません(11gR1では、BTMObserver_Wls_10.3_Universal_*.zipを使用する必要があります)。

注意:
完全なZIPファイル名では、アスタリスク(*)はオブザーバのバージョン番号で置換されています。
これらのオブザーバがサポートしているプラットフォームおよびアプリケーション・サーバーのバージョンの正確なリストは、Business Transaction Management (BTM)動作保証マトリックスを参照してください。このドキュメントは、http://support.oracle.comからオンラインで参照できます。

特定のオブザーバの互換性および機能の詳細は、オブザーバZIPファイルを展開した後、オブザーバのnanoagentディレクトリにあるREADME.txtファイルを参照してください。

個別のインストール手順も提供されています。

- ノード・マネージャ構成のサーバーへのインストール

- スクリプト構成のサーバーへのインストール

9.1 ノード・マネージャ構成のサーバーへのインストール

1. ご使用の環境および監視ニーズに適切なオブザーバ配布ZIPファイルを探します。

2. WebLogic管理対象サーバーのホーム・ディレクトリ(WL_HOME)にオブザーバZIPファイルを解凍します。
ホーム・ディレクトリとは、WebLogicのインストール・ディレクトリにあるwlserver_10.3またはwlserver_12.1のディレクトリで、たとえばC:\WL_10-3-2-0\wlserver_10.3です。この手順を忘れないようにするため、文字列WL_HOMEをWebLogicホーム・ディレクトリの実際のパスで置き換えます。

ZIPファイルを解凍すると、nanoagentおよびsecurity_add_onsという名前のディレクトリが作成されます。nanoagentディレクトリには、bin、configおよびlibという名前の3つのサブディレクトリが含まれています。

注意:
ライブラリを探すために、オブザーバはデフォルトでlibディレクトリを検索します。このデフォルトの場所を上書きする方法の詳細は、第8.3項「オブザーバ・ライブラリのデフォルトの場所のオーバーライド」を参照してください。

3. WebLogicを実行しているユーザー・アカウントが、最低でも以下の権限を持っていることを確認します。

- nanoagent/configおよびnanoagent/libディレクトリの読取り権限(UNIX系システムでは、トラバース権限も必要)

- libディレクトリ内のすべてのJARファイルの読取り権限

4. WebLogic管理コンソール(デフォルトのURLは、http://machine_name:7001/console)を開きます。

5. WebLogic起動引数の編集の準備をします。

1. 「ドメイン構造」ペイン(左側)で、「環境」→「サーバー」に移動します。

2. 「サーバー」表で、管理対象サーバーをクリックします。

3. 「構成 / サーバーの起動」タブを表示します。

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

注意:
この手順は、本番環境での操作を想定しているため、WebLogicサーバーの「ロックを自動取得して変更をアクティブ化」の設定は無効になっていることを前提としています。ただし、開発環境ではこの設定が有効である場合も考えられます。その場合は、変更を行うために「ロックして編集」をクリックする必要はなく、保存後に変更をアクティブ化する必要もありません。

6. 「構成 / サーバーの起動」タブが表示された状態で、WebLogic起動引数を次のように編集します。

1. AP_NANO_HOMEシステム・プロパティを作成し、「引数」フィールドに次の文字列を追加してプロパティにオブザーバのnanoagentディレクトリの場所を設定します。
Windowsシステムでは、次の文字列を追加します。エントリの区切り文字はスペースです。

-DAP_NANO_HOME=WL_HOME\nanoagent

UNIX系システムでは、次の文字列を追加します。エントリの区切り文字はスペースです。

-DAP_NANO_HOME=WL_HOME/nanoagent

注意:
引数のエントリの区切り文字に改行は使用しないでください。

2. AP_NANO_CONFIG_URLシステム・プロパティを作成し、「引数」フィールドに次の文字列を追加します。

-DAP_NANO_CONFIG_URL=http://Host:Port/btmmonitor/agent/agent/

Host:Portは、オブザーバがメッセージを転送するモニターのホスト名およびポート番号で置換します。

このプロパティにURLを指定することによって、オブザーバはそのURLのモニターと関連付けられます。オブザーバは起動時に指定されたモニターから構成を取得し、監視結果をそのモニターに送信します。

注意:
レプリケートされたモニターを使用している場合は、URLのホストおよびポートの部分にロード・バランサのHTTP仮想サーバーのホストおよびポートを設定する必要があります。たとえば、HTTP仮想サーバーのIPアドレスが10.147.46.152でポート番号が5072の場合、URLを次のように設定します。

http://10.147.46.152:5072/btmmonitor/agent/agent/

このトピックの詳細は、第7.4項を参照してください。

3. 省略可能 – オブザーバ構成ラベルでこのオブザーバのターゲットを指定する場合は、ap.nano.config.labelという名前のシステム・プロパティを作成し、その値にラベル文字列を設定するために、次の文字列を「引数」フィールドに追加します。

-Dap.nano.config.label=My_Label_String

My_Label_Stringは、このオブザーバで使用するラベルの文字列で置換します。オブザーバのターゲット指定の詳細は、第7.5項「オブザーバ通信ポリシーの適用」を参照してください。

4. 次のどちらかのJVM引数を「引数」フィールドに追加するして、オブザーバ・ブートストラップ・モジュールをサーバーに構成します。
Windowsシステムの場合は、次の引数を追加します。

-javaagent:WL_HOME\nanoagent\lib\bootstrap\ap-nano-bootstrap.jar

UNIX系システムの場合は、次の引数を追加します。

-javaagent:WL_HOME/nanoagent/lib/bootstrap/ap-nano-bootstrap.jar

7. WebLogicサーバーを実行しているユーザーがオブザーバのエラー・ログ・ディレクトリへの書込み権限を持っていることを確認します。
デフォルトでは、オブザーバのエラー・ログ・ディレクトリはWebLogicドメイン・ディレクトリです。エラー・ロギングの構成の詳細は、第13章「オブザーバ・エラーおよびデバッグ情報のロギング」を参照してください。

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

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

10. オブザーバがメッセージを転送するモニターに、オブザーバ通信ポリシーが適用されていることを確認します。
オブザーバ通信ポリシーの適用の詳細は、第7.5項「オブザーバ通信ポリシーの適用」を参照してください。

9.2 スクリプト構成のサーバーへのインストール

注意:
この手順の実行方法によって、オブザーバをインストール済のWebLogicで定義されているすべてのサーバーへのインストールも、特定のドメインのサーバーへのインストールもできます。この手順では、グローバル・インストールという用語は、オブザーバをすべてのサーバーにインストールすることを示し、ドメイン・インストールという用語はオブザーバを特定のドメインにインストールすることを示します。

1. お使いの環境および監視ニーズに適切なオブザーバ配布ZIPファイルを探します。

2. WebLogicサーバーのホーム・ディレクトリ(グローバル・インストールの場合)またはドメイン・ディレクトリ(ドメイン・インストールの場合)にオブザーバZIPファイルを解凍します。
ホーム・ディレクトリとは、WebLogicのインストール・ディレクトリにあるwlserver_10.3またはwlserver_12.1のディレクトリで、たとえばC:\WL_10-3-2-0\wlserver_10.3です。この手順を忘れないようにするため、WL_HOMEをWebLogicホーム・ディレクトリの実際のパスで置き換えます。

ZIPファイルを解凍すると、nanoagentおよびsecurity_add_onsという名前のディレクトリが作成されます。nanoagentディレクトリには、bin、configおよびlibという名前の3つのサブディレクトリが含まれています。

注意:
ライブラリを探すために、オブザーバはデフォルトでlibディレクトリを検索します。このデフォルトの場所を上書きする方法の詳細は、第8.3項「オブザーバ・ライブラリのデフォルトの場所のオーバーライド」を参照してください。

3. WebLogicを実行しているユーザー・アカウントが、最低でも以下の権限を持っていることを確認します。

- nanoagent/configおよびnanoagent/libディレクトリの読取り権限(UNIX系システムでは、トラバース権限も必要)

- libディレクトリ内のすべてのJARファイルの読取り権限

4. 次の手順に従い、オブザーバ・スクリプト・ファイルを呼び出すように、WebLogicのドメイン起動スクリプトを構成します。

注意:
この手順では、startWebLogicスクリプトを変更していないことを仮定しています。スクリプトを変更している場合は、それに応じたインストール手順の変更が必要な場合があります。

1. サービスを監視するWebLogicドメインの1つでbinディレクトリに移動し、テキスト・エディタで起動スクリプトを開きます(Windowsシステムではbin\startWebLogic.cmdを、UNIX系システムではbin/startWebLogic.shを開きます。ドメイン・ディレクトリの直下にある起動スクリプトは編集しないでください)。

2. 次の行を探します(最初の行はWindowsの場合、次の行はUNIX系システムの場合)。

call "%DOMAIN_HOME%\bin\setDomainEnv.cmd"

. ${DOMAIN_HOME}/bin/setDomainEnv.sh

3. この行の直後に、オブザーバ・スクリプト・ファイルを呼び出す行を追加します。
Windowsシステムでグローバル・インストールを行っている場合は、次の行を追加します。

call "%WL_HOME%\nanoagent\bin\nanoEnvWeblogic.cmd"

UNIX系システムでグローバル・インストールを行っている場合は、次の行を追加します(最初のピリオドと空白に注意してください)。

. ${WL_HOME}/nanoagent/bin/nanoEnvWeblogic.sh

Windowsシステムでドメイン・インストールを行っている場合は、次の行を追加します。

call "%DOMAIN_HOME%\nanoagent\bin\nanoEnvWeblogic.cmd"

UNIX系システムでドメイン・インストールを行っている場合は、次の行を追加します(最初のピリオドと空白に注意してください)。

. ${DOMAIN_HOME}/nanoagent/bin/nanoEnvWeblogic.sh

注意:
第4.3.1項「Oracle Walletによるセキュリティ構成」で説明されているセキュリティ関連の構成を行った場合は、すでにこの場所にsetBtmOverriderEnv_via_CredStoreスクリプトの呼出しが追加されています。これらのスクリプトを呼び出す相対的な順序は重要ではありません。

4. サービスを監視する各ドメインで、この手順を実行します。

5. オブザーバ・スクリプト・ファイルをテキスト・エディタで開きます。
オブザーバ・スクリプト・ファイルとは、startWebLogicスクリプト・ファイルが呼び出すnanoEnvWeblogic.cmdまたはnanoEnvWeblogic.shファイルです。

6. ドメイン・インストールの場合は、次の変更を行います(ドメイン・インストール以外の場合は、次の手順にスキップします)。

Windowsシステムの場合は、次の行を探します。

set NANOAGENT_HOME=%WL_HOME%\nanoagent

この行を次のように変更します。

set NANOAGENT_HOME=%DOMAIN_HOME%\nanoagent

UNIX系システムの場合は、次の行を探します。

NANOAGENT_HOME=$WL_HOME/nanoagent

この行を次のように変更します。

NANOAGENT_HOME=$DOMAIN_HOME/nanoagent

このファイルは開いたままにします。

7. オブザーバをモニターに関連付けます。

注意:
オブザーバ・スクリプト・ファイルは、NANOAGENT_CONFIGURATION_URL変数を使用してAP_NANO_CONFIG_URLシステム・プロパティの値を設定します。このシステム・プロパティにURLを指定することによって、オブザーバはそのURLのモニターと関連付けられます。オブザーバは起動時に指定されたモニターから構成を取得し、監視結果をそのモニターに送信します。

1. オブザーバ・スクリプト・ファイルで、次の変数定義を探します(最初の行はWindowsの場合、次の行はUNIX系システムの場合)。

set NANOAGENT_CONFIGURATION_URL=http://HOST:PORT/btmmonitor/agent/agent/

NANOAGENT_CONFIGURATION_URL=http://HOST:PORT/btmmonitor/agent/agent/

2. HOST:PORTは、オブザーバが監視結果を送信するモニターのホスト名およびポート番号で置換します。次に例を示します。

set NANOAGENT_CONFIGURATION_URL=http://myhost:7002/btmmonitor/agent/agent

NANOAGENT_CONFIGURATION_URL=http://myhost:7002/btmmonitor/agent/agent

注意:
レプリケートされたモニターを使用している場合は、URLのホストおよびポートの部分にロード・バランサのHTTP仮想サーバーのホストおよびポートを設定する必要があります。たとえば、HTTP仮想サーバーのIPアドレスが10.147.46.152でポート番号が5072の場合、URLを次のように設定します。

http://10.147.46.152:5072/btmmonitor/agent/agent/

ロード・バランサのHTTP仮想サーバーの詳細は、第7.4項を参照してください。

3. ドメイン・インストールの場合は、各ドメインで手順6および7を実行します。

8. 省略可能 – オブザーバ構成ラベルでオブザーバのターゲットを指定する場合は、次の手順を実行します。

注意:
オブザーバ・スクリプト・ファイルは、NANOAGENT_CONFIGURATION_LABEL変数を使用してap.nano.config.labelシステム・プロパティの値を設定します。オブザーバのターゲット指定の詳細は、第7.5項「オブザーバ通信ポリシーの適用」を参照してください。

1. オブザーバ・スクリプト・ファイルで、次の変数定義を探します(最初の行はWindowsの場合、次の行はUNIX系システムの場合)。

set NANOAGENT_CONFIGURATION_LABEL=

NANOAGENT_CONFIGURATION_LABEL=

2. 次のように、変数定義のラベル文字列を追加します。

set NANOAGENT_CONFIGURATION_LABEL=My_Label

NANOAGENT_CONFIGURATION_LABEL=My_Label

9. WebLogicサーバーを実行しているユーザーがオブザーバのエラー・ログ・ディレクトリへの書込み権限を持っていることを確認します。
デフォルトでは、オブザーバのエラー・ログ・ディレクトリはWebLogicドメイン・ディレクトリです。エラー・ロギングの構成の詳細は、第13章「オブザーバ・エラーおよびデバッグ情報のロギング」を参照してください。

10. サーバーを再起動します。

11. オブザーバがメッセージを転送するモニターに、オブザーバ通信ポリシーが適用されていることを確認します。
オブザーバ通信ポリシーの適用の詳細は、第7.5項「オブザーバ通信ポリシーの適用」を参照してください。

9.3 WebLogicからのオブザーバ・ライブラリのアンインストール

この項では、WebLogic 10.3サーバーからオブザーバ・ライブラリをアンインストールする方法について説明します。手順は、ノード・マネージャまたはローカル・スクリプトのどちらでサーバーを構成するかによって異なります。

- ノード・マネージャでサーバーを構成する場合は、第9.3.1項「ノード・マネージャで構成された管理対象サーバーからのアンインストール」を参照してください。

- ローカル・スクリプトでサーバーを構成する場合は、第9.3.2項「ローカル・スクリプトで構成されたサーバーからのアンインストール」を参照してください。

9.3.1 ノード・マネージャで構成された管理対象サーバーからのアンインストール

1. WebLogic管理対象サーバーを停止します。

2. WebLogicホーム・ディレクトリ(WL_HOME)にあるnanoagentフォルダを削除します。
ホーム・ディレクトリとは、WebLogicのインストール・ディレクトリにあるwlserver_10.3またはwlserver_12.1のディレクトリで、たとえばC:\WL_10-3-2-0\wlserver_10.3です。この手順を忘れないようにするため、WL_HOMEをWebLogicホーム・ディレクトリの実際のパスで置き換えます。

3. WebLogic管理コンソール(デフォルトのURLは、http://Machine_Name:7001/console)を開きます。

4. 次の手順に従い、オブザーバに関連するすべての起動引数を削除します。

1. ナビゲーション・ペイン(左側)で、「環境」→「サーバー」に移動します。

2. 「サーバー」表で、管理対象サーバーをクリックします。

3. 「構成 / サーバーの起動」タブを表示します。

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

5. 「引数」フィールドから、次の文字列をすべて削除します。

-DAP_NANO_HOME=WL_HOME/nanoagent
-DAP_NANO_HOME=WL_HOME\nanoagent
-DAP_NANO_CONFIG_URL=http://HOST:PORT/btmmonitor/agent/agent/
-Dap.nano.config.label=My_Label
-javaagent:WL_HOME\nanoagent\lib\bootstrap\ap-nano-bootstrap.jar
-javaagent:WL_HOME/nanoagent/lib/bootstrap/ap-nano-bootstrap.jar

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

6. WebLogicサーバーを再起動します。

9.3.2 ローカル・スクリプトで構成されたサーバーからのアンインストール

1. WebLogicサーバーを停止します。

2. WebLogicホーム・ディレクトリ(WL_HOME)にあるnanoagentフォルダを削除します。
ホーム・ディレクトリとは、WebLogicのインストール・ディレクトリにあるwlserver_10.3またはwlserver_12.1のディレクトリで、たとえばC:\WL_10-3-2-0\wlserver_10.3です。この手順を忘れないようにするため、WL_HOMEをWebLogicホーム・ディレクトリの実際のパスで置き換えます。

3. サービスを監視する必要がなくなったWebLogicドメインのbinディレクトリに移動し、startWebLogicスクリプト(Windowsの場合はstartWebLogic.cmd、UNIX系システムの場合はstartWebLogic.sh)を編集します。スクリプトから次の行を削除します(最初の行はWindowsの場合、次の行はUNIX系システムの場合)。

call "%WL_HOME%\nanoagent\bin\nanoEnvWeblogic.cmd"

. ${WL_HOME}/nanoagent/bin/nanoEnvWeblogic.sh

4. WebLogicサーバーを再起動します。

10 WCF用のオブザーバ・ライブラリのインストール

このトピックでは、WCF 3.5および4.0のサービスを監視するオブザーバ・ライブラリのインストールおよびアンインストールの手順を説明します。WCF 3.5サービスを監視するオブザーバには.NET 3.5 Frameworkを、WCF 3.5および4.0の両方のサービスを監視するオブザーバには.NET 4.0 Frameworkをインストールする必要があります。このオブザーバが監視できるのは、IIS 7.5によってホストされるWCFサービスのみです。

注意:
このオブザーバがサポートしているアプリケーション・サーバーのバージョンの正確なリストは、Business Transaction Management (BTM)動作保証マトリックスを参照してください。このドキュメントは、http://support.oracle.comからオンラインで参照できます。
特定のオブザーバの互換性および機能の詳細は、オブザーバZIPファイルを展開した後、オブザーバのnanoagentディレクトリにあるREADME.txtファイルを参照してください。

10.1 オブザーバ配布ファイル

Business Transaction Managementオブザーバは、ZIPファイルで配布されます。各ZIPファイルには、特定のアプリケーション・サーバーへのインストールに適した1種類のオブザーバが含まれています。WCF 3.5サービスを監視するオブザーバを含むZIPファイルは、BTMObserver_Iis_7.5_DotNet4_*.zipです。

注意:
完全なZIPファイル名では、アスタリスク(*)はオブザーバのバージョン番号で置換されています。

10.2 WCF 3.5および4.0用のオブザーバ・ライブラリのインストール

1. WCF用のオブザーバ配布ZIPファイル(BTMObserver_Iis_7.5_DotNet4_*.zip)を探します。

2. ZIPファイルを一時ディレクトリ(以降、observer_tempと表記します)に解凍します。
ZIPファイルを解凍すると、configおよびlibの2つのサブディレクトリを含むnanoagentディレクトリが作成されます。

3. gacutil.exeを使用して、observer_temp\nanoagent\libからグローバル・アプリケーション・キャッシュ(GAC、通常はC:\WINDOWS\assembly)にすべてのDLLファイルをコピーします。

4. 次のようにアプリケーション構成ファイルを編集して、オブザーバをアプリケーションに構成します。

注意:
アプリケーション構成ファイルを編集する前に、バックアップ・コピーを作成します。

マシンで実行されているすべてのWCFアプリケーションを監視する場合、machine.configファイルを編集します(第10.3項を参照)。

1つ以上の特定のWebアプリケーションを監視する場合は、各Webアプリケーションについて適切なweb.configファイルを編集します(第10.4項を参照)。

5. GAC内のAmberPointアセンブリのバージョン番号が、アプリケーション構成ファイルのバージョン番号と一致することを確認します。次に例を示します。

<soapExtensionTypes>
<add type="AmberPoint.NanoAgent.DotNet.AspNet.Handlers.SoapExtensionHandler,
AmberPoint.NanoAgentToolkit, Version=64000.64000.23409.20080,
Culture=neutral,
PublicKeyToken=d8685c0afbb35893" priority="1" group="0" />
</soapExtensionTypes>

バージョン番号がアセンブリと一致していないと、検索されません。

6. アプリケーション構成ファイルを次のように編集します。

1. AmberPoint:NanoConfigUrlキーの値に、オブザーバがメッセージを転送するモニターのURLを設定します。
次の形式を使用します。Host:Portはモニターのホスト名およびポート番号で置換します。

<add key="AmberPoint:NanoConfigUrl" value="http://Host:Port/btmmonitor/agent/agent"/>

このキーにURLを指定することによって、オブザーバはそのURLのモニターと関連付けられます。オブザーバは起動時に指定されたモニターから構成を取得し、監視結果をそのモニターに送信します。

AmberPoint:NanoConfigUrlキーにモニターのURLを設定するかわりに、AP_NANO_CONFIG_URLという名前の環境変数を作成し、そこにモニターのURLを設定することもできます。

注意:
レプリケートされたモニターを使用している場合は、URLのホストおよびポートの部分にロード・バランサのHTTP仮想サーバーのホストおよびポートを設定する必要があります。たとえば、HTTP仮想サーバーのIPアドレスが10.147.46.152でポート番号が5072の場合、URLを次のように設定します。

http://10.147.46.152:5072/btmmonitor/agent/agent/

ロード・バランサのHTTP仮想サーバーの詳細は、第7.4項を参照してください。

2. AmberPoint:NanoHomeキーの値に、オブザーバが構成ファイルをキャッシュする場所を設定します。次に例を示します。

<add key="AmberPoint:NanoHome" value="C:/nanohome"/>

3. AmberPoint:NanoLogBaseDirキーの値に、エラー・ログを作成する場所を設定します。場所は絶対パスで指定します。ディレクトリが存在しない場合に作成するには、AmberPoint:NanoCreateLogBaseDirキーの値をtrueに設定します。次に例を示します。

<add key="AmberPoint:NanoLogBaseDir" value="C:/nanohome/log"/>
<add key="AmberPoint:NanoCreateLogBaseDir" value="true"/>

AmberPoint:NanoLogBaseDirキーには、デフォルト値はありません。nullを設定すると、ログ・ファイルは生成されません。

オブザーバがログ・ファイルを生成できるように、オブザーバを実行しているユーザーがログ・ディレクトリへの書込み権限を持っていることを確認します。オブザーバは、NETWORK SERVICEという名前のユーザーで実行されます。

エラー・ロギングの構成の詳細は、第13章「オブザーバ・エラーおよびデバッグ情報のロギング」を参照してください。

7. 省略可能 – オブザーバ構成ラベルでこのオブザーバのターゲットを指定する場合は、AP_NANO_CONFIG_LABELという名前の環境変数を作成し、その値にラベル文字列を設定します。
オブザーバのターゲット指定の詳細は、第7.5項「オブザーバ通信ポリシーの適用」を参照してください。

8. オブザーバがメッセージを転送するモニターに、オブザーバ通信ポリシーが適用されていることを確認します。
オブザーバ通信ポリシーの適用の詳細は、第7.5項「オブザーバ通信ポリシーの適用」を参照してください。

10.3 machine.configファイルの編集

注意:
machine.configファイルを編集する前に、バックアップ・コピーを作成します。

マシンで実行されているすべてのWCFアプリケーションを監視する場合、machine.configファイルを編集します。通常、このファイルはC:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIGにあります。

注釈付きのmachine.configファイルの例が、observer_temp\nanoagent\config\Machine.config.partにあります。ファイルの編集の際に、このファイルをガイドとして使用します。

10.4 web.configファイルの編集

注意:
web.configファイルを編集する前に、バックアップ・コピーを作成します。

どのweb.configファイルを編集するかによって、すべてのWebアプリケーションを監視することも、特定のWebアプリケーションのみを監視することもできます。たとえば、Webサイトにインストールされているすべてのアプリケーションを監視する場合、Webサイトのホーム・ディレクトリにあるweb.configファイルを編集します。特定のWebアプリケーションのみを監視する場合、そのアプリケーションのディレクトリにあるweb.configファイルを編集します。

注釈付きのweb.configファイルの例が、observer_temp\nanoagent\config\Web.config.partおよびWeb.config.wcf4.partにあります。WCF 3.5環境にオブザーバをインストールする場合は、ファイルの編集の際にWeb.config.partをガイドとして使用します。WCF 4.0環境にオブザーバをインストールする場合は、両方のファイルをガイドとして使用できますが、Web.config.wcf4.partに記述されている手順の方が効率的です。

10.5 WCF 3.5および4.0用のオブザーバ・ライブラリのアンインストール

1. アプリケーション構成ファイルのAmberPoint:NanoConfigキーの値で指定した場所から、apobserver.configurationファイルを削除します。
アプリケーション構成ファイルは、machine.configまたはweb.configです。

2. アプリケーション構成ファイルをオブザーバのインストール前の状態に戻します。
オブザーバ配布ファイル(BTMObserver_Iis_7.5_DotNet4_*.zip)には、オブザーバを追加するためにアプリケーション構成ファイルを編集する方法を説明している注釈付きのアプリケーション構成ファイルの例が含まれています。アプリケーション構成ファイルを戻す際に、このファイルをガイドとして使用します。

machine.configファイルを戻す必要がある場合は、config\Machine.config.partファイルをガイドとして使用します。web.configファイルを戻す必要がある場合は、web.configファイルを構成する際にどちらを使用したかによって、config\Web.config.partまたはWeb.config.wcf4.partをガイドとして使用します。

3. オブザーバのDLLをGACから削除します(マシン上の他のオブザーバに使用されている場合を除く)。
各オブザーバDLLの名前は、文字列「AmberPoint」で始まります。DLLを削除するには、右クリックしてアンインストールを選択します。

注意:
ASP.NET用のオブザーバは、WCF用のオブザーバと同じDLLの多くを使用します。マシン上にASP.NET用のオブザーバがインストールされている場合は、そこで使用されているDLLは削除しないでください。

11 Oracle Enterprise Gatewayへのオブザーバ・ライブラリのインストール

この章では、Oracle Enterprise Gateway 11.1.1.6へのオブザーバ・ライブラリのインストールおよびアンインストールの手順を説明します。

11.1 オブザーバ配布ファイル

Business Transaction Managementオブザーバは、ZIPファイルで配布されます。各ZIPファイルには、特定のアプリケーション・サーバーへのインストールに適した1種類のオブザーバが含まれています。Enterprise Gatewayサーバーにインストールするオブザーバ用のZIPファイルは、BTMObserver_OEG_11.1.1.6_OEG_*.zipです。

注意:
実際のZIPファイルでは、アスタリスク(*)はオブザーバのバージョン番号で置換されています。
このオブザーバがサポートしているプラットフォームおよびアプリケーション・サーバーのバージョンの正確なリストは、Business Transaction Management (BTM)動作保証マトリックスを参照してください。このドキュメントは、http://support.oracle.comからオンラインで参照できます。

特定のオブザーバの互換性および機能の詳細は、オブザーバZIPファイルを展開した後、オブザーバのnanoagentディレクトリにあるREADME.txtファイルを参照してください。

11.2 Enterprise Gateway 11.1.1.6へのオブザーバ・ライブラリのインストール

1. Enterprise Gatewayサーバーを停止します。

2. オブザーバZIPファイル(BTMObserver_OEG_11.1.1.6_OEG_*.zip)を一時ディレクトリ(以降、observer_tempと表記します)に解凍します。
ZIPファイルを解凍すると、config、libおよびscriptsという名前の3つのディレクトリが作成されます。

3. libディレクトリ内のすべてのJARファイルをOEG_HOME/ext/libにコピーします。OEG_HOMEはEnterprise Gatewayサーバーのホーム・ディレクトリ(最上位のインストール・ディレクトリ)です。

注意:
ライブラリを探すために、オブザーバはデフォルトでlibディレクトリを検索します。デフォルトの場所のオーバーライドの詳細は、第8.3項「オブザーバ・ライブラリのデフォルトの場所のオーバーライド」を参照してください。

4. Enterprise Gatewayを実行しているユーザー・アカウントが、最低でも以下の権限を持っていることを確認します。

- nanoagent/configおよびnanoagent/libディレクトリの読取り権限(UNIX系システムでは、トラバース権限も必要)

- libディレクトリ内のすべてのJARファイルの読取り権限

5. テキスト・エディタで、OEG_HOME/system/conf/jvm.xmlを開き、<JVMSettings>要素内を次のように変更します。

1. <JVMSettings>要素の最初の子要素に次の行を追加して、オブザーバをモニターと関連付けます。

<SystemProperty name="AP_NANO_CONFIG_URL" value="http://Host_Name:Port_Number/btmmonitor/agent/agent/"/>

Host_Name:Port_Numberは、オブザーバと関連付けるモニターのホスト名およびポート番号で置換します。

2. 続けて、<JVMSettings>要素の2番目、3番目および4番目の子要素として、次の行を追加します。

<SystemProperty name="AP_NANO_HOME" value="$VDISTDIR/NanoAgent"/>
<SystemProperty name="AP_NANO_LOG_BASEDIR" value="$VDISTDIR/NanoAgent"/>
<SystemProperty name="AP_NANO_CLASSLOADER_BASEDIR" value="$VDISTDIR/ext/lib"/>

3. 省略可能 – オブザーバ構成ラベルでオブザーバのターゲットを指定する場合は、<JVMSettings>要素の5番目の子要素として次の行を追加します。

<SystemProperty name="ap.nano.config.label" value="My_Label_String"/>

My_Label_Stringは、このオブザーバで使用するラベルの文字列で置換します。オブザーバのターゲット指定の詳細は、第7.5項「オブザーバ通信ポリシーの適用」を参照してください。

4. 次の行を探します。

<ClassPath name="$VDISTDIR/system/lib/system/iaik_jce.jar"/>

この行の直前に次の行を追加します。

<ClassPath name="$VDISTDIR/ext/lib/orawsdl_1.0.0.jar"/>

6. Enterprise Gatewayサーバーを再起動します。

7. 次の手順に従ってインターセプタ・モジュールを公開し、オブザーバのインストールを終了します。

1. テキスト・エディタで、observer_temp/scripts/publishLoadableModule.pyスクリプト・ファイルを開きます。

2. Enterprise Gateway管理者アカウントの資格証明を使用して、defUsernameおよびdefPassword変数を設定します(デフォルトの管理者アカウントのユーザー名はadminです)。次に例を示します。

defUserName = "admin"
defPassword = "mypassword"

3. defServer変数に、Enterprise GatewayサーバーのベースURLを設定します。次に例を示します。

defServer = "http://myOegHost:8090"

このURLには、末尾のスラッシュ(/)を追加しないでください。

4. スクリプト・ファイルを保存して閉じます。

5. スクリプトを実行します。次に例を示します。
Windowsシステムでは、次を実行します。

%OEG_HOME%/Win32/bin/jython.bat publishLoadableModule.py

UNIX系システムでは、次を実行します。

$OEG_HOME/posix/bin/jython publishLoadableModule.py

8. Enterprise Gatewayサーバーを実行しているユーザーがオブザーバのエラー・ログ・ディレクトリへの書込み権限を持っていることを確認します。
デフォルトでは、オブザーバのエラー・ログ・ディレクトリはOEG_HOMEです。エラー・ロギングの構成の詳細は、第13章「オブザーバ・エラーおよびデバッグ情報のロギング」を参照してください。

9. オブザーバがメッセージを転送するモニターに、オブザーバ通信ポリシーが適用されていることを確認します。
オブザーバ通信ポリシーの適用の詳細は、第7.5項「オブザーバ通信ポリシーの適用」を参照してください。

11.3 Enterprise Gateway 11.1.1.6からのオブザーバ・ライブラリのアンインストール

この項では、Enterprise Gateway 11.1.1.6サーバーからオブザーバ・ライブラリをアンインストールする方法について説明します。

1. 次の手順に従って、Enterprise Gatewayサーバーからオブザーバ・インターセプタ・モジュールを削除します。

1. テキスト・エディタで、observer_temp/scripts/removeLoadableModule.pyスクリプト・ファイルを開きます。

注意:
observer_tempが存在しない場合は、再作成の方法について第11.2項「Enterprise Gateway 11.1.1.6へのオブザーバ・ライブラリのインストール」を参照してください。

2. Enterprise Gateway管理者アカウントの資格証明を使用して、defUsernameおよびdefPassword変数を設定します(デフォルトの管理者アカウントのユーザー名はadminです)。次に例を示します。

defUserName = "admin"
defPassword = "mypassword"

3. defServer変数に、Enterprise GatewayサーバーのベースURLを設定します。次に例を示します。

defServer = "http://myOegHost:8090"

このURLには、末尾のスラッシュ(/)を追加しないでください。

4. スクリプト・ファイルを保存して閉じます。

5. スクリプトを実行します。次に例を示します。
Windowsシステムでは、次を実行します。

%OEG_HOME%/Win32/bin/jython.bat removeLoadableModule.py

UNIX系システムでは、次を実行します。

$OEG_HOME/posix/bin/jython removeLoadableModule.py

2. Enterprise Gatewayサーバーを停止します。

3. OEG_HOME/ext/libにあるすべてのオブザーバ関連のJARファイルを削除します。
オブザーバ関連のJARファイルは、「ap-」から始まるファイルと、次のファイルです。

orahttp_client_1.0.0.jar
orawsdl_1.0.0.jar
xstream-1.2.2.jar

注意:
他のモジュールと共有されているJARファイルを削除しないように注意してください。

4. テキスト・エディタで、OEG_HOME/system/conf/jvm.xmlを開き、<JVMSettings>要素の中から以下を含むすべてのオブザーバ関連要素を削除します。

<SystemProperty name="AP_NANO_CONFIG_URL" value="http://host-name:port-number/btmmonitor/agent/agent/"/>

<ClassPath name="$VDISTDIR/ext/lib/orawsdl_1.0.0.jar"/>

また、name属性が以下の文字列で始まるすべての<VMArg>要素を削除します。

-Dcom.amberpoint

5. jvm.xmlファイルを保存して閉じます。

6. Enterprise Gatewayサーバーを再起動します。

12 Business Transaction Managementの起動および停止

この章では、以下の方法について説明します。

- Business Transaction Managementコンポーネントの起動および停止

- 監視メッセージを失わないモニター・グループ・メンバーの停止および再起動

- 管理コンソールへのログインおよびログアウト

- オンライン・ヘルプへのアクセス

12.1 Business Transaction Managementコンポーネントの起動

コンポーネントがインストールされたアプリケーション・サーバーが起動すると、Business Transaction Managementコンポーネントも自動的に起動します。セントラル・サーバーおよびモニターはデプロイされたアプリケーションであるため、アプリケーション・サーバーの管理機能を使用して手動で起動することも可能です。一方、オブザーバはビジネス・アプリケーションにインストールされ、そのアプリケーションとともに起動します。

すべてのシステムのコンポーネントが停止している場合、中央から外側に向かって、つまり次の順番で起動するのが最適です。

1. セントラル・サーバー

2. モニター

3. オブザーバ

ただし、どのような順番でも起動は可能で、すべてのコンポーネントがお互いを認識して自身を構成した後、システムは完全に機能するようになります。

注意:
オブザーバ、つまりビジネス・アプリケーションが稼働し、モニターが稼働していない場合、オブザーバの送信キューはやがて一杯になります。この時点で、監視メッセージがキューから抜け落ちるか、ビジネス・アプリケーションがストールします。デフォルトの動作では、監視メッセージがキューから抜け落ち、ビジネス・アプリケーションのパフォーマンスは低下しないことが保証されています。この動作は、オブザーバ通信ポリシーで構成可能です。ただし、これは詳細オプションであるため、Oracleサポート・チームから編集するように指示を受けている場合を除き、デフォルトの設定のままにしておくことが推奨されます。監視結果を失わずにモニターを停止する必要がある場合は、第7章「モニターのインストール」で説明されているように、モニターをレプリケートする必要があります。

12.2 Business Transaction Managementコンポーネントの停止

コンポーネントがインストールされたアプリケーション・サーバーを停止すると、Business Transaction Managementコンポーネントも停止します。セントラル・サーバーおよびモニターはデプロイされたアプリケーションであるため、アプリケーション・サーバーの管理機能を使用して手動で停止することも可能です。一方、オブザーバはビジネス・アプリケーションにインストールされ、そのアプリケーションとともに停止します。

すべてのシステムのコンポーネントを停止する場合、外側から中央に向かって、つまり次の順番で停止するのが最適です。

1. オブザーバ

2. モニター

3. セントラル・サーバー

ただし、システムを損なうことなく、個々のコンポーネントを停止して再起動することも可能です。すべてのコンポーネントがお互いを認識して自身を再構成した後、システムは完全な機能に戻ります。

なお、第12.1項の注意で説明されている監視結果のロストは、この場合にも該当します。

12.3 モニター・グループ・メンバーの停止および再起動

モニター・グループ内のレプリケートされたモニターは、メンバーと呼ばれます。この項では、処理中のデータを失わずにモニター・グループの個々のメンバーを停止する方法を説明します。また、モニター・グループ・メンバーの正しい再起動方法も説明します。

12.3.1 モニター・グループ・メンバーの停止

1. ロード・バランサのソケット仮想サーバーで、モニターに関連付けられたプール・メンバーを無効にします。

2. モニターからすべての処理中データがなくなるまで待ちます。
次の手順に従って、処理中データのステータスを確認できます。

1. 次のいずれかの方法で、モニターのステータス・ページを表示します。
Business Transaction Managementコンソールのナビゲータで、「管理」→「モニター」を選択し、メイン・エリアでモニターを選択して「ステータス」タブをクリックします。

または、Webブラウザで次のURLにアクセスします。host:portは、モニターが稼働しているホスト名およびポート番号です。

http://host:port/btmmonitor/agent/agent?status

2. 「Nano監視キュー」セクションまでスクロールします。

3. 次の式が両方trueになる場合、すべての処理中データがモニターからなくなっています。

perf.SimpleMeasurementsProcessed = perf.SimpleMeasurementsQueued

Perf.RequestsQueued = Perf.ResponsesQueued + Perf.QueueSize

3. アプリケーション・サーバーの管理ツールを使用してモニターのデプロイメントを停止します。

12.3.2 モニター・グループ・メンバーの再起動

1. アプリケーション・サーバーの管理ツールを使用して、モニターのデプロイメントを起動します。

2. ロード・バランサのソケット仮想サーバーで、モニターに関連付けられたプール・メンバーを有効にします。

12.4 管理コンソールのロギング

Business Transaction Managementコンソール(このドキュメントでは、単に管理コンソールと呼ぶこともあります)と呼ばれるWebベースのインタフェースを使用して、Business Transaction Managementの機能の管理およびアクセスを行います。

管理コンソールにアクセスするには、メイン・サーバー(btmMain.ear)が稼働している必要があります。管理コンソールにログインするためには、Webブラウザで次の形式のURLを開きます。

http://hostname:port/btmui

注意:
Webブラウザは、第5.1項「Webブラウザの要件」で示されている要件を満たす必要があります。

hostname:portは、メイン・サーバーをインストールしたマシン名およびアクセス可能なポート番号で置換します。

Webブラウザにログイン・ページが表示されます。第6.4項「ユーザーのロールへのマッピング」で説明されているように、適切な資格証明を使用してログインします。

12.5 管理コンソールからのログアウト

管理コンソールからログアウトするには、ページ右上の「ログアウト」リンクをクリックします。

12.6 オンライン・ヘルプ

管理コンソールで「ヘルプ」メニューをクリックして「ヘルプ」を選択するか、ツール・ダイアログ・ボックスで「ヘルプ」ボタンをクリックすることにより、Business Transaction Managementオンライン・ヘルプにアクセスできます。オンライン・ヘルプが開いたら、左側のナビゲーション機能を使用して適切なヘルプ・トピックを見つけます。

13 オブザーバ・エラーおよびデバッグ情報のロギング

オブザーバは次のログ・ファイルにエラーおよびデバッグ情報を書き込みます。

- NanoAgentErrorTrace.log – 他のログ・ファイルに書き込まれるすべてのエラーおよび警告が1回ずつ出力されます。各エラーおよび警告のエントリは、<Ref>要素内の一意の識別子で参照されます。次に例を示します。

<Ref: Dq/QGNWqOmbdXPigC+vsO40eXgs=>

この識別子を使用して、他のファイル内(通常はNanoAgent.log)にあるそのエラーまたは警告の全件を検索することができます。一般的に、問題発生時に最初に検索するのは、このログ・ファイルです。

このログ・ファイルのデフォルトのサイズは10Mで、サーバーが再起動するたびに再作成されます。ただし、デフォルトでローテーションが2に設定されているため、以前のログ・ファイルはサーバーの再起動後も保持されます。

- NanoAgent.log – ランタイム・エラーおよびデバッグ情報が含まれています(オブザーバ通信ポリシーで「トレース・ロギングの有効化」オプションを使用して、このログ出力の設定を調整できます。)

- NanoAgentPreprocessTrace.log – バイトコード計測エラーおよびデバッグ、クラスのロード、プロプロセッサに関する情報が含まれています。このファイルは、サーバーの再起動ごとに再生成されます。このログ・ファイルの最大サイズは10MBです。
このファイルは、リリース12.1.0.2.2で名前が変更されました。以前のリリースのオブザーバでは、ファイル名はAWTrace.logでした。

注意:
監視メッセージを記録するようにオブザーバを構成することもできます。このトピックの詳細は、オンライン・ヘルプでオブザーバ通信ポリシーの「監視対象メッセージをファイルに記録」フィールドの詳細を参照してください。

ログ・ファイルのデフォルトの場所は、次のとおりです。

- WebLogic – domain_root_directory/nanoagent/logs/server_nameディレクトリ(このディレクトリが確認できない場合は、ドメイン・ルート・ディレクトリがデフォルトになります)

- OC4J – SOA Suiteのインストール・ディレクトリ内のj2ee\homeディレクトリ

- Enterprise Gateway – Enterprise Gatewayサーバーのホーム・ディレクトリ(最上位のインストール・ディレクトリ)

- WebSphere – プロファイル・ディレクトリ

- JBoss – JBOSS_HOME/binディレクトリ

- WCFおよびASP.NET – C:/temp/NanoAgentBaseDirディレクトリ

注意:
WCFおよびASP.NETのデフォルトのログの場所は、厳密な意味のデフォルトではありません。前述したのはAmberPoint:NanoLogBaseDirキーのデフォルトの値です。このキーをnullに設定すると、ログ・ファイルは作成されません。

ログ・ファイルを他のディレクトリに生成したい場合は、AP_NANO_LOG_BASEDIR JavaプロパティまたはAmberPoint:NanoLogBaseDir Windowsキーを設定します。Javaアプリケーション・サーバーの場合は、絶対パスまたはデフォルトのログ・ディレクトリからの相対パスでプロパティを設定できます。Enterprise Gateway、WCFおよびASP.NETの場合は、プロパティまたはキーは絶対パスで設定する必要があります。このプロパティまたはキーの設定例を次に示します。

- WebLogicでローカル・スクリプトの編集によってサーバーを構成する場合は、WL_HOME/nanoagent/binディレクトリにあるnanoEnvWeblogicスクリプトを編集します。ファイルのoptionsセクションで、NANOAGENT_JAVA_OPTIONSの最後に-DAP_NANO_LOG_BASEDIR="my_log_dir"を追加します。この相対パスによって、ドメイン・ディレクトリ内のmy_log_dirディレクトリにログ・ファイルが生成されるようになります。
WebLogicサーバーをノード・マネージャで構成する場合は、WebLogic管理コンソールを開いてサーバーを選択し、「構成 / サーバーの起動」タブを表示します。次に、「引数」フィールドに-DAP_NANO_LOG_BASEDIR=my_log_dirを追加します。この相対パスによって、ドメイン・ディレクトリ内のmy_log_dirディレクトリにログ・ファイルが生成されるようになります。

- OC4Jでは、Java起動オプションに-DAP_NANO_LOG_BASEDIR=my_log_dirを追加します。この相対パスによって、SOA Suiteインストール・ディレクトリ内のj2ee\homeディレクトリにあるmy_log_dirディレクトリにログ・ファイルが生成されるようになります。

- Enterprise Gatewayでは、テキスト・エディタでOEG_HOME/system/conf/jvm.xmlを開き、<JVMSettings>要素の子要素に<SystemProperty name="AP_NANO_LOG_BASEDIR" value="C:\OEG\my_log_dir"/>を追加します。この絶対パスによって、C:\OEG\my_log_dirディレクトリにログ・ファイルが生成されるようになります。

- WebSphereでは、WebSphere管理コンソールで「Servers」→「Application servers」→「server1」→「Server Infrastructure」→「Java and Process Management」→「Process Definition」→「Java Virtual Machine」→「Custom Properties」に移動します(server1のかわりに別のサーバー名が表示される可能性があります)。AP_NANO_LOG_BASEDIRという名前のカスタム・プロパティを作成し、その値にmy_log_dirを設定します。この相対パスによって、プロファイル・ディレクトリ内のmy_log_dirディレクトリにログ・ファイルが生成されるようになります。

- JBossでは、サーバー起動スクリプトJBOSS_HOME/bin/runを編集します。ファイルのoptionsセクションに、set JAVA_OPTS=-DAP_NANO_LOG_BASEDIR="my_log_dir"を追加します。この相対パスによって、JBOSS_HOME/bin/my_log_dirディレクトリにログ・ファイルが生成されるようになります。

- WCFまたはASP.NETでは、アプリケーション構成ファイル(たとえば、Web.config)を編集し、AmberPoint:NanoLogBaseDirキーの値にC:/Inetpub/wwwroot/my_log_dirを設定します。この絶対パスによって、デフォルトWebサイト・ディレクトリ内のmy_log_dirディレクトリにログ・ファイルが生成されるようになります。次に例を示します。

<configuration>
<configSections>
...
</configSections>
<AmberPoint>
<NanoAgentDataSection>
<add key="AmberPoint:NanoConfig" value="c:/temp/NanoAgentLogBaseDir/nanoagentDiscovery.CONFIGURATION"/>
<add key="AmberPoint:NanoLogBaseDir" value="c:/Inetpub/wwwroot/my_log_dir"/>
<add key="AmberPoint:NanoCreateLogBaseDir" value="false"/>
</NanoAgentDataSection>
</AmberPoint>
<system.web>
...
</system.web>
</configuration>

オブザーバがログ・ファイルを生成できるように、オブザーバを実行しているユーザーがログ・ディレクトリへの書込み権限を持っていることを確認します。Javaオブザーバの場合は、ユーザーはアプリケーション・サーバーを実行しているユーザーです。IISオブザーバ(WCFおよびASP.NET)の場合は、次のユーザーです。

- IIS 5.x – オブザーバのユーザーはASPNET

- IIS 6.xおよび7.x – オブザーバのユーザーはNETWORK SERVICE

デフォルトでは、AP_NANO_LOG_BASEDIRプロパティで指定されるディレクトリが存在しない場合は、自動的に作成されます。このディレクトリを自動的に作成しない場合は、AP_NANO_CREATE_LOG_BASEDIRプロパティをfalseに設定します。この場合、ディレクトリは手動で作成する必要があります。このプロパティは、AP_NANO_LOG_BASEDIRと同じ方法で設定します。

注意:
Javaアプリケーション・サーバーの場合 – ログ・ディレクトリが存在せず、AP_NANO_CREATE_LOG_BASEDIRがfalseに設定されている場合、ランタイム・エラーが発生してオブザーバが初期化されない可能性があります。
IISの場合 – NanoLogBaseDir Windowsキーがnullに設定されると、ログ・ファイルは作成されません。

14 Oracle Business Transaction Managementのスクリプトによる構成

初めてBusiness Transaction Managementを構成する場合は、ブラウザ・ベースの構成ウィザードの使用を推奨します。コマンドライン・インタフェース(CLI)は、後からコマンドラインで様々な構成タスクを実行するユーザーのために提供されています。

CLIは、様々な構成タスクと同等のコマンドラインを提供しています。このドキュメントに関連するCLIコマンドは、configureコマンドです。このコマンドによって、ウィザードによる構成アプローチの代替手段が提供されています。

configureコマンドについての完全なドキュメントや、CLIの全体像については、Business Transaction Managementオンライン・ヘルプを参照してください。

14.1 configureコマンド

configureコマンドの引数には、XML構成ファイルを指定します。この構成ファイルは、データベース・タイプ、接続情報、デプロイメント資格証明などのBusiness Transaction Managementのすべての設定情報を指定します。

この構成入力ファイルは、ブラウザ・ベースの構成ウィザードを使用してBusiness Transaction Managementの初期構成を実行する際に出力される生成済構成ファイルを使用して作成できます。ウィザードは、すべての構成情報(スフィアURL、データベース接続情報、パフォーマンス・サーバーの場所、認証資格証明など)を含む構成ファイルを生成します。この構成ファイルを編集して、configureコマンドの入力に使用することができます。生成済構成ファイルは、essentialConfiguration.xmlという名前で、WebLogicインストール・ディレクトリ内の次の場所にあります。

user_projects/domains/MyDomain/servers/MyServer/btmstorage/btmMain /globalPreferences

14.2 CLIの起動

CLI実行可能ファイルは、Install_Dir/toolsディレクトリにあるWindowsではbtmcli.bat、Unix系システムではbtmcli.shです。

configureコマンドの構文は、次のとおりです。

btmcli configure -i inputFile -s sphereUrl -l username:password

CLIを実行する前にAP_USER_LOGIN環境変数を設定すると、コマンドラインでのユーザー名およびパスワードの入力を避けることができます。次に例を示します。

set AP_USER_LOGIN=MyUsername:MyPassword

15 datastoreUtilユーティリティ

第5.4項「Business Transaction Managementデータベースの設定」では、次の推奨名のスフィア、パフォーマンスおよびトランザクション・データベース用のデータベース・ユーザーを作成するよう説明しています。

- sphereDB (スフィア・データベース用)

- measurementDB (パフォーマンス・データベース用)

- transactionDB (トランザクション・データベース用)

この章では、推奨名を使用していることを仮定しています。そうでない場合は、適切な名前に置き換えてください。

datastoreUtilユーティリティであらかじめ作成する場合を除き、Business Transaction Managementを構成する際に(第6.5項「Business Transaction Managementの初期構成」を参照)、システムによって自動的にこれらのユーザー用の適切なデータベース表が作成されます。

datastoreUtilユーティリティを使用すると、Business Transaction Managementに必要な表およびビューを作成するために、(sqlplusで)入力として使用できるDDLを生成できます。または、datastoreUtilを使用してデータベース・インスタンスに接続し、直接表およびビューを作成します。

15.1 使用方法

datastoreUtilユーティリティを起動するには、コマンド・ウィンドウまたはシェルでインストール済のBusiness Transaction Managementのtoolsディレクトリに移動し、オペレーティング・システムに応じたdatastoreUtilスクリプト(datastoreUtil.batまたはdatastoreUtil.sh)を実行します。

ユーティリティの起動後、第15.2項「コマンド」に示されているコマンドを実行できます。複数の引数を持つコマンドは、説明されている順番で引数を指定する必要があります。

15.2 コマンド

datastoreUtilユーティリティでは、次のコマンドが提供されています。

- generateSchema (またはgenerate)

- connect

- createSchema (またはcreate)

- close

- exit

- help

15.2.1 generateSchema (またはgenerate)

指定されたスキーマ定義のDDLを生成します。このコマンドは、データベースに接続せずに使用できます。

generateSchema schemaType databaseType [[directory] targetSchema] -partition|-nopartition

- schemaType – 次のスキーマ・タイプのいずれかを指定します。

- sphere – スフィア・データベース(sphereDBユーザー)用のスキーマを作成します。

- exm – トランザクション・データベース(transactionDBユーザー)用のスキーマを作成します。

- performance – パフォーマンス・データベース(measurementDBユーザー)用のスキーマを作成します。

- monitorgroup – モニター・グループ用のスキーマを作成します。

- msglog – システム・メッセージ・ログ用のスキーマを作成します。

- databaseType – oracleを指定します。サポートされているのはこの値のみです。

- directory – DDLファイルを生成する場所(デフォルトはローカル・ディレクトリ)を指定します。

- targetSchema – 省略可能。この引数は、生成されたスキーマを特定のユーザーにスコープします。たとえば、sphereDB、transactionDBまたはmeasurementDBです。

- -partitionまたは-nopartition – schemaTypeをperformanceまたはmonitorgroupに指定した場合に、このフラグが必要になります。schemaTypeを他の値に指定すると、このフラグは不要になり、指定した場合でも無視されます。
Oracle Enterprise Editionを使用している場合、-partitionフラグを指定することによってOracleのパーティション機能を活用するperformanceまたはmonitorgroupスキーマを作成できます。この機能を活用しない場合、またはOracleエディションでパーティション機能が提供されていない場合は、-nopartitionフラグを指定する必要があります(performanceまたはmonitorgroupスキーマを作成している場合)。

15.2.2 connect

ユーザーが指定する接続情報を使用して、データベースに接続します。

connect databaseType|filename

- databaseType – oracleを指定します。サポートされているのはこの値のみです。

- filename – saveConnectionコマンドによって出力されたファイルを指定します。

connectコマンドを使用して、データベース接続情報を入力してデータベースに接続します。接続するデータベースについて、次の情報がわかっている必要があります。

- ドライバ名

- ユーザー名

- パスワード

- URL接続文字列

接続後にsaveConnectionコマンドを発行して、ファイルに接続情報を保存することができます。次に同じデータベースに接続する場合、接続コマンドが保存されたファイル名で指定できます。データベース・タイプを指定すると、ユーティリティは自動的に対応するデフォルトのドライバを選択します。

15.2.3 createSchema (またはcreate)

接続しているデータベース内に、指定されたスキーマを作成します。

createSchema schemaType -partition|-nopartition

- schemaType – 次のスキーマ・タイプのいずれかを指定します。

- sphere – スフィア・データベース(sphereDBユーザー)用のスキーマを作成します。

- exm – トランザクション・データベース(transactionDBユーザー)用のスキーマを作成します。

- performance – パフォーマンス・データベース(measurementDBユーザー)用のスキーマを作成します。

- monitorgroup – モニター・グループ用のスキーマを作成します。

- msglog – システム・メッセージ・ログ用のスキーマを作成します。

- -partitionまたは-nopartition – schemaTypeをperformanceまたはmonitorgroupに指定した場合に、このフラグが必要になります。schemaTypeを他の値に指定すると、このフラグは不要になり、指定した場合でも無視されます。
Oracle Enterprise Editionを使用している場合、-partitionフラグを指定することによってOracleのパーティション機能を活用するperformanceまたはmonitorgroupスキーマを作成できます。この機能を活用しない場合、またはOracleエディションでパーティション機能が提供されていない場合は、-nopartitionフラグを指定する必要があります(performanceまたはmonitorgroupスキーマを作成している場合)。

15.2.4 close

connectコマンドで以前にオープンした接続をクローズします。

close

15.2.5 exit

ユーティリティを終了します。

exit

15.2.6 help

helpコマンドを使用すると、すべてのコマンドのヘルプが表示されます。helpコマンドに続けてコマンド名を入力すると、単一のコマンドのヘルプが表示されます。

help | help command

索引
A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W

A

AmberPoint:NanoConfigUrl Windowsキー, 7.4, 8.2

AmberPoint:NanoLogBaseDir Windowsキー, 13, 13

AP_NANO_CLASSLOADER_BASEDIR Javaシステム・プロパティ, 8.3

AP_NANO_CONFIG_URL Javaシステム・プロパティ, 7.4, 8.2

AP_NANO_CREATE_LOG_BASEDIR Javaシステム・プロパティ, 13

AP_NANO_HOME Javaシステム・プロパティ, 8.3

AP_NANO_LOG_BASEDIR Javaシステム・プロパティ, 13

apclassloader.basedir Javaシステム・プロパティ, 8.3

BTMのアーキテクチャ

説明, 1.1

図, 1.1

アサーション秘密, 4.3 オブザーバ認証, 7.5.2.1 ユーザーの認証, 6.4

B

BTMコンポーネント

停止, 12.2

起動, 12.1

btmAdminロール, 6.4.1.1 btmInspectorロール, 6.4.1.2 btmObserverロール, 6.4.1.1 btmUserロール, 6.4.1.1

C

セントラル・サーバー

定義, 1.1

ファイル権限, 2.2, 6.3

インストール, 6

デプロイ, 6.3

初期構成, 6.5

BTMアプリケーション・ロールへのユーザーのマッピング, 6.4

概要, 6.1

永続記憶域ディレクトリ, 構成, 6.2

パッケージ, 1.2 アップグレード, 2.2 動作保証マトリックス, 9 コマンドライン・インタフェース(CLI), 14.1

起動, 14.2

registerMonitorコマンド, 7.2

コマンドライン, BTMの構成, 14 通信パス・フィールド, 7.5.2.1, 7.5.2.1 ウィザードによるセントラル・サーバーの構成, 6.5 構成ウィザード

データベースの構成, 6.5

パフォーマンス・サーバーURL, 6.5

スフィア(メイン・サーバー) URL, 6.5

トランザクション・サーバーURL, 6.5

configureコマンド, 14.1 スクリプトによるBTMの構成, 14 接続文字列, データベース, 6.5 createSchema, 15.2.3

D

データベース・ドライバ

WebLogic, 5.3

データベース

構成ウィザードでの構成, 6.5

BTM表およびビューの作成, 15

設定, 5.4

サイジング・スプレッドシート, 5.4.2

datastoreUtilユーティリティ, 15 デバッグ、13 検出

有効化/無効化, 7.5.2.2

DNS別名, 6.5

E

暗号化鍵, 4.3

エラー・ロギング, 13

essentialConfiguration.xml, 14.1

拡張プロパティ, セキュリティでの使用, 4.3.2

F

F5仲介

パッケージ, 1.2

フィールド

通信パス, 7.5.2.1, 7.5.2.1

モニター・ポート番号, 7.5.2.1, 7.5.2.1

ルーターIPアドレスおよびルーターポート番号, 7.5.2.1

デフォルト・ストアの使用, 7.5.2.1

ファイアウォール, 4.2.4, 8.1

G

generateSchema, 15.2.1

H

ヘルプ, オンライン・アクセス, 12.6

HTTPS, 4.2.1

I

インストール

セントラル・サーバー, 6

デプロイ, 6.3

ファイル権限, 2.2, 6.3

初期構成, 6.5

BTMアプリケーション・ロールへのユーザーのマッピング, 6.4

概要, 6.1

永続記憶域ディレクトリ, 構成, 6.2

モニター, 7

概要, 7.1

オブザーバ

WCFの場合, 10

WebLogicサーバーの場合, 9

概要, 3

J

Javaシステム・プロパティ

AP_NANO_CLASSLOADER_BASEDIR, 8.3

AP_NANO_CONFIG_URL, 7.4, 8.2

AP_NANO_CREATE_LOG_BASEDIR, 13

AP_NANO_HOME, 8.3

AP_NANO_LOG_BASEDIR, 13

apclassloader.basedir, 8.3

K

モニター用キー・ストア, 7.5.2.1

L

ライブラリの場所, デフォルトの場所のオーバーライド, 8.3

ロード・バランサ, 構成, 7.4

管理コンソールへのログイン, 12.4

管理コンソールからのログアウト, 12.5

M

machine.configファイル, 編集, 10.3

メイン・サーバー

定義, 1.1

パッケージ, 1.2

URL, 6.5

管理コンソール

ログイン, 12.4

ログアウト, 12.5

URL, 12.4

メンバー, モニター・グループ

追加および削除, 7.6

メモリー割当て

WebLogic, 5.3

モニター

定義, 1.1

インストール, 7

概要, 7.1

キー・ストア, 7.5.2.1 パッケージ, 1.2 アップグレード, 2.2 URL, 8.2 モニター・グループ

メンバーの追加および削除, 7.6

ロード・バランサの構成, 7.4

定義, 7

メンバーの再起動, 12.3.2

設定, 7.3

メンバーの停止, 12.3

モニター・ポート番号フィールド, 7.5.2.1, 7.5.2.1 モニタリング

有効化/無効化, 7.5.2.2

N

NanoAgentErrorTrace.log, 13

NanoAgent.log, 13

NanoAgentPreprocessTrace.log, 13

O

オブザーバ

定義, 1.1

エラー・ロギングおよびデバッグ, 13

ファイアウォール, 8.1

インストールの概要, 8

インストールの前提条件, 8.1

ライブラリのインストール

WCFの場合, 10

WebLogicサーバーの場合, 9

ライブラリの場所, デフォルトのオーバーライド, 8.3 バージョン番号の検索, 2.1.1 パッケージ, 1.2 キュー, 12.1 README.txt, 2.3 トラスト・ストア, 7.5.2.1 ライブラリのアンインストール

WCFの場合, 10.5

WebLogicサーバーの場合, 9.3

アップグレード, 2.3

OEGの場合, 2.3.3

WCFの場合, 2.3.2

WebLogicサーバーの場合, 2.3.1

オブザーバ認証, 7.5.2.1 オンライン・ヘルプ, 12.6 Oracle Wallet, 4.3.1

P

BTMパッケージ, 1.2

パフォーマンス・サーバー

定義, 1.1

パッケージ, 1.2

URL, 6.5

永続記憶域ディレクトリ, 構成, 6.2 前提条件, 5

データベース・ドライバ

WebLogic, 5.3

オブザーバのインストール, 8.1 メモリー割当て

WebLogic, 5.3

データベースの設定, 5.4 Webブラウザ, 5.1 WebLogic環境, 5.3 プローブ

アクティブ化, 7.5.2.2

定義, 7.5.2.2

JAVA, 7.5.2.2

Q

キュー, オブザーバ, 12.1

R

registerMonitor CLIコマンド, 7.2

ロール, BTMアプリケーション

説明, 6.4.1

ユーザーのマッピング, 6.4

WebLogicサーバーの場合, 6.4.2

ルーターIPアドレスおよびルーターポート番号フィールド, 7.5.2.1

S

スキーマ, 作成, 15.2.1, 15.2.3

BTMのスクリプトによる構成, 14

セキュリティ, 4

アサーション秘密, 4.3

ユーザーの認証, 6.4

通信プロトコル, 4.1

デプロイメント・シナリオ, 4.1

暗号化鍵, 4.3

セントラル・サーバーのファイル権限, 2.2, 6.3

ファイアウォール, 4.2.4

HTTPS, 4.2.1

メカニズム, 4

監視メッセージ, 4.4

ロール, BTMアプリケーション

説明, 6.4.1

ユーザーのマッピング, 6.4

SSL, オブザーバとモニター間の有効化, 7.5.2.1 拡張プロパティの使用, 4.3.2 Oracle Walletの使用, 4.3.1 セキュリティ, ネットワーク・レベル

設定, 4.2

BTMコンポーネントの停止, 12.2 サイジング・スプレッドシート, データベース, 5.4.2 構成ウィザードのスフィアURL, 6.5 SSL, オブザーバとモニター間の有効化, 7.5.2.1 BTMコンポーネントの起動, 12.1

T

トランザクション・サーバー

定義, 1.1

パッケージ, 1.2

URL, 6.5

オブザーバ用トラスト・ストア, 7.5.2.1

U

アップグレード

セントラル・サーバーおよびモニター, 2.2

一般ルール, 2

オブザーバ, 2.3

OEGの場合, 2.3.3

WCFの場合, 2.3.2

WebLogicサーバーの場合, 2.3.1

URL

モニター, 8.2

モニター(ロード・バランサ経由), 7.4

パフォーマンス・サーバー, 6.5

スフィア(メイン・サーバー), 6.5

管理コンソール, 12.4

トランザクション・サーバー, 6.5

デフォルト・ストアの使用フィールド, 7.5.2.1 ユーティリティ, datastoreUtil, 15

V

バージョン番号, 互換性の比較, 2.1.1

W

WCF

オブザーバのインストール, 10

オブザーバのアンインストール, 10.5

Webブラウザの要件, 5.1 web.configファイル, 編集, 10.4 WebLogic,

オブザーバのインストール, 9

ユーザーのBTMアプリケーション・ロールへのマッピング, 6.4.2

環境の設定, 5.3

オブザーバのアンインストール, 9.3

Windowsキー

AmberPoint:NanoConfigUrl, 7.4, 8.2

AmberPoint:NanoLogBaseDir, 13, 13

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2014, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。