Oracle® Enterprise Manager

Business Transaction Managementオンライン・ヘルプ

12c リリース5 (12.1.0.6)

E59455-01(原本部品番号:E52792-01)

2014年6月

Oracle Enterprise Manager Business Transaction Managementオンライン・ヘルプ, 12c リリース5 (12.1.0.6)

E59455-01

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

第一著者: Joanna Bujes

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

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

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

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)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

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の登録商標です。

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

目次

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

はじめに

- 対象読者

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

- 表記規則

1 Oracle Business Transaction Managementの概要

- 1.1 Business Transaction Managementの使用方法

- 1.2 新機能および変更点

- 1.3 アーキテクチャの概要

- 1.4 機能アップグレードの問題

- 1.4.1 WebLogic 10.3サーバー用の汎用オブザーバの影響

- 1.4.2 検出の制限に対する新規デフォルト設定の影響

- 1.4.3 新規認証設定の影響

- 1.4.4 新規プローブの影響

- 1.4.5 モデル構成設定での新規JMSオプションの影響

- 1.4.6 改善されたJMSプローブの影響

2 Business Transaction Managementの開始

- 2.1 基本ワークフロー

- 2.1.1 トラフィックの実行

- 2.1.2 サービスおよび依存性の検出

- 2.1.3 対象領域の識別

- 2.1.4 トランザクションの定義

- 2.1.5 トランザクション監視の必要性の評価

- 2.1.6 スクリプトの作成

3 管理コンソールの使用方法

- 3.1 管理コンソールについて

- 3.1.1 一般的なコンソールの設計

- 3.1.2 ナビゲータ

- 3.1.3 メイン領域

- 3.1.4 メニュー

- 3.1.5 タブ領域

- 3.1.6 オブジェクト詳細ウィンドウ

- 3.2 データの表示

- 3.2.1 コントロールの表示

- 3.2.1.1 フィルタリング・コントロール

- 3.2.1.2 列チューザおよびサイズ設定コントロール

- 3.2.1.3 時間間隔コントロール

- 3.2.1.4 ポップアップ・リンクおよびインスペクタ

- 3.2.1.5 ティアオフ・コントロール

- 3.2.2 マップの表示

- 3.2.2.1 マップの表データの表示

- 3.2.2.2 マップ・ビューのフィルタおよび調整

- 3.2.2.3 マップ・ビューのスケーリング

- 3.2.2.4 マップの様々なリージョンへのフォーカス

- 3.2.3 チャートの表示

- 3.2.4 表の表示

- 3.2.5 ダッシュボードの表示

- 3.3 新規ビューの作成

- 3.3.1 表の変更

- 3.3.2 カスタム・データ・エクスプローラを使用したビューの作成

- 3.3.3 ビューの保存

- 3.4 管理コンソール参照

- 3.4.1 「分析」タブの使用方法

- 3.4.1.1 「パフォーマンス」ペイン

- 3.4.1.2 トランザクション・パフォーマンス

- 3.4.1.3 サービスのパフォーマンス

- 3.4.1.4 コンシューマ使用状況

- 3.4.1.5 トランザクション使用状況

- 3.4.1.6 サービス/エンドポイント使用状況

- 3.4.1.7 条件アラート

- 3.4.1.8 クライアント・アドレス別内訳

- 3.4.1.9 コールアウト

- 3.4.1.10 カスタム・チャート

- 3.4.1.11 カスタム内訳

- 3.4.2 状態サマリー・ダッシュボード

- 3.4.3 フィルタ・ツールの使用方法

- 3.4.4 フィルタリングのカスタム属性の追加

- 3.4.4.1 属性の追加

- 3.4.4.2 属性値の割当て

- 3.4.4.3 カスタム属性に基づくフィルタ

- 3.4.5 キーボード・ショートカット

4 サービスおよび依存性の検出

- 4.1 検出について

- 4.1.1 検出できる内容

- 4.1.2 検出プロセス

- 4.1.3 検出の制限

- 4.1.4 JDBCコールのモデル化

- 4.1.4.1 JDBCサマリー・データの表示の理解

- 4.1.4.2 サマリー・オプション変更後のトランザクション定義の更新

- 4.1.5 サービスの手動登録

- 4.2 検出されたコンテナの表示

- 4.2.1 コンテナ情報の表示

- 4.2.2 サマリーおよび詳細情報の表示

- 4.2.3 コンテナのプロファイル情報の編集

- 4.2.4 コンテナの登録解除

- 4.3 検出されたサービスの表示

- 4.3.1 サービス・タイプ

- 4.3.2 デプロイメント・トポロジおよびサービス情報

- 4.3.3 ルーターの存在を推察する方法

- 4.3.4 サービスの表示

- 4.4 依存性の表示

- 4.4.1 関連要素の表示

- 4.4.2 サービスの依存性

- 4.4.3 エンドポイントの依存性

- 4.4.4 操作の依存性

- 4.4.5 依存性の削除

- 4.5 手動によるサービスの登録

- 4.6 検出されたオブジェクトの削除および再開始

5 トランザクションの使用

- 5.1 トランザクションについて

- 5.1.1 トランザクションを定義するもの

- 5.1.2 プロパティ

- 5.1.3 自動相関および手動相関

- 5.1.4 デフォルトのトランザクション定義

- 5.1.5 その他の機能

- 5.1.5.1 セグメンテーション

- 5.1.5.2 インスタンスとプロパティのロギング

- 5.1.5.3 メッセージ・コンテンツ・ロギング

- 5.1.6 サービス・レベル合意および条件

- 5.2 プロパティについて

- 5.2.1 プロパティの使用方法

- 5.2.2 標準プロパティ

- 5.2.3 ユーザー定義プロパティ

- 5.3 プロパティの使用

- 5.3.1 プロパティの定義

- 5.3.2 WSDLがないか不完全なサービスのプロパティ

- 5.3.3 プロパティ定義の表示

- 5.3.4 プロパティ値の表示

- 5.3.5 プロパティの変更

- 5.3.6 プロパティ定義の複製

- 5.3.7 プロパティの削除

- 5.4 トランザクションの定義、変更および削除

- 5.4.1 トランザクションの定義

- 5.4.1.1 操作の選択およびトランザクションの有効化

- 5.4.1.2 セグメンテーションの有効化

- 5.4.1.3 インスタンス・ロギングおよびメッセージ・コンテンツ・ロギングの有効化

- 5.4.1.4 手動キーを使用したトランザクション内のメッセージの相関

- 5.4.1.5 記憶域設定の定義

- 5.4.2 トランザクション定義の変更

- 5.4.3 トランザクション定義の削除

- 5.5 トランザクション・パフォーマンスの表示および監視

- 5.5.1 トランザクションのメイン・ビューのフィルタ処理

- 5.5.2 パフォーマンス情報のサマリーおよび分析

- 5.5.2.1 「サマリー」タブ

- 5.5.2.2 「分析」タブ

- 5.5.3 アラートの表示および応答

- 5.6 「上位10件のトランザクション」ダッシュボード

- 5.7 トランザクション・インスタンスの表示

- 5.7.1 取得したトランザクション・インスタンスの表示

- 5.7.2 インスタンスのアセンブルおよびインスタンス・インスペクタの使用方法

- 5.8 ログ・メッセージおよびプロパティの表示

- 5.8.1 ログ・メッセージおよびプロパティに関する情報の表示

- 5.8.2 メッセージ・ログ検索ツールの使用方法

- 5.8.2.1 ECIDベースの検索

- 5.8.2.2 プロパティ・ベースの検索

- 5.8.2.3 フリー・テキスト検索

- 5.8.3 メッセージ・ロギングおよびインスタンス・ロギングの有効化および無効化

- 5.9 その他の診断ツールへのアクセス

- 5.9.1 JVMDビューの使用方法

- 5.9.2 「インスタンス診断リクエスト」ビューの使用方法

- 5.9.2.1 ECIDの基本

- 5.9.2.2 ECIDとトランザクション操作間の対応

- 5.9.2.3 「インスタンス診断リクエスト」ビューへのアクセス

- 5.9.3 JVMDビューおよびRIDビューへのアクセスの有効化

- 5.10 トランザクションに関する情報の取得

- 5.10.1 プロファイル情報の取得

- 5.10.2 ポリシー情報の取得

- 5.10.3 条件定義の取得および変更

- 5.10.4 プロパティ情報の取得

- 5.11 トランザクションのトラブルシューティング

- 5.11.1 ログ・ポリシー設定の表示

6 サービスの監視

- 6.1 サービスの監視方法

- 6.2 「上位10件のサービス」ダッシュボード

- 6.3 インスツルメントについて

- 6.3.1 トランザクション・インスツルメント

- 6.3.2 サービスおよび操作のインスツルメント

7 コンシューマの使用

- 7.1 コンシューマについて

- 7.1.1 コンシューマ・セグメンテーションの設定

- 7.1.2 コンシューマの作成

- 7.1.3 デフォルトのコンシューマ名の変更

- 7.2 コンシューマへのメッセージのマッピング

- 7.2.1 コンシューマ・ビジネス・オブジェクトのカスタマイズ

- 7.2.2 マッピング・オプション

- 7.3 コンシューマの監視

- 7.4 コンシューマの追加および削除

- 7.5 コンシューマ名の編集

- 7.6 コンシューマ・ラベルのカスタマイズ

8 アラートの構成および表示

- 8.1 アラートについて

- 8.2 サービス・レベル合意について

- 8.2.1 パフォーマンス目標

- 8.2.2 評価期間

- 8.3 サービス・レベル合意の定義

- 8.3.1 固定値のSLAの定義

- 8.3.2 ベースラインSLAの定義

- 8.3.3 使用状況SLAの定義

- 8.4 SLAポリシーの使用

- 8.5 SLA準拠の監視

- 8.6 「SLA準拠」タブ

- 8.7 サービスまたはエンドポイントの停止時間のスケジューリング

- 8.8 条件について

- 8.8.1 条件の定義および評価

- 8.8.2 条件アラートの解釈

- 8.9 条件の使用

- 8.9.1 フォルト監視の有効化と無効化

- 8.9.2 条件の定義

- 8.9.3 条件の有効化と無効化

- 8.9.4 条件情報の表示

- 8.9.5 条件定義の変更

- 8.9.6 条件定義の複製

- 8.9.7 条件の削除

- 8.10 条件アラート情報の表示

- 8.10.1 件数情報の表示

- 8.10.2 アラートおよび詳細情報の表示

- 8.10.3 アラートの有効期限の変更

9 レポートの作成

- 9.1 概要

- 9.2 レポートの生成

10 コマンドおよびスクリプト

- 10.1 コマンドライン・インタフェース(CLI)について

- 10.1.1 ヘルプおよびバージョン情報の取得

- 10.1.2 CLIコマンドおよびスクリプトの実行

- 10.1.3 CLIコマンドにアクセスする場合のセキュリティ・オプション

- 10.1.4 コマンド一覧

- 10.1.5 環境変数

- 10.1.6 属性名

- 10.2 addBaseAddressAlias

- 10.3 addNodeAlias

- 10.4 addPathAlias

- 10.5 configure

- 10.5.1 configureコマンドの動作

- 10.5.2 構成ファイル

- 10.6 configureAlivenessCheck

- 10.7 createOrUpdateGenre

- 10.8 createOrUpdatePolicy

- 10.9 createSettingsDocument

- 10.10 credStoreTool

- 10.10.1 user:password資格証明の使用方法

- 10.10.2 信頼できる発行者と秘密資格証明の使用方法

- 10.10.3 バイナリ資格証明の使用方法

- 10.11 deleteAll

- 10.12 encryptPassword

- 10.13 exportBusinessObjects

- 10.14 exportMessages

- 10.15 exportPolicies

- 10.16 exportPolicyTemplates

- 10.17 exportProfile

- 10.18 exportSchedules

- 10.19 exportTransactionDefns

- 10.20 getSetupData

- 10.21 importBusinessObjects

- 10.22 importPolicies

- 10.23 importPolicyTemplates

- 10.24 importProfile

- 10.25 importSchedules

- 10.26 importTransactionDefns

- 10.27 listInstruments

- 10.28 listNodeAliases

- 10.29 mergeServices

- 10.30 moveEndpoints

- 10.31 moveMeasurements

- 10.32 putSetupData

- 10.33 registerDevice

- 10.34 registerExternalContainer

- 10.35 registerMonitor

- 10.36 removeBaseAddressAlias

- 10.37 removeDuplicateEndpoint

- 10.38 removeNode

- 10.39 removeNodeAlias

- 10.40 removePathAlias

- 10.41 removePolicy

- 10.42 removePolicyTemplate

- 10.43 renameEndpoint

- 10.44 resetSphereUrl

- 10.45 retrieveObjectData

- 10.46 sendEventNotification

- 10.47 sendToNotifier

- 10.47.1 電子メール通知の設定

- 10.47.2 電子メール通知の管理

- 10.47.3 通知サービス・コマンド・ドキュメント

- 10.47.3.1 通知サービス・コマンド

- 10.47.3.2 アラート・タイプのメタデータ

- 10.48 setBaselines

- 10.49 setDefaultLoadBalancer

- 10.50 showService

- 10.51 unmonitorEndpoint

- 10.52 unregister

- 10.53 unregisterContainer

- 10.54 unregisterMonitor

- 10.55 updateProfileData

11 ユーティリティ

- 11.1 コマンドライン・ユーティリティについて

- 11.2 datastoreUtilユーティリティ

- 11.2.1 コマンド

- 11.3 logMergerユーティリティ

- 11.3.1 logMerger構成ファイル

- 11.4 showProductInfoユーティリティ

12 Business Transaction Managementの管理

- 12.1 オブザーバ

- 12.1.1 オブザーバについて

- 12.1.2 オブザーバおよびモニターの構成

- 12.1.2.1 一般的なタスク

- 12.1.2.2 プローブのアクティブ化および非アクティブ化

- 12.1.2.3 プローブの追加

- 12.1.2.4 オブザーバとモニター間の通信チャネルの設定

- 12.1.2.5 監視メッセージ・フローでのSSLの構成

- 12.1.2.6 オブザーバ認証の構成

- 12.1.2.7 オブザーバのターゲット

- 12.1.2.8 Real User Experience Insightからのドリルダウンの有効化/無効化

- 12.1.2.9 WEB_APPプローブ用のリクエストの監視および操作のモデル化

- 12.1.2.10 情報設定フィールドのリファレンス

- 12.1.2.11 詳細設定フィールドのリファレンス

- 12.1.2.12 基準

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

- 12.2 永続的データ

- 12.2.1 Business Transaction Managementデータベース資格証明の構成

- 12.2.2 メッセージ・ログ・データベースの設定

- 12.2.3 永続記憶域ディレクトリについて

- 12.2.4 Business Transaction Management永続記憶域ディレクトリの再配置

- 12.2.4.1 永続記憶域ディレクトリを再配置する前のバックアップ

- 12.2.4.2 永続記憶域ディレクトリを再配置するための一般的な手順

- 12.2.4.3 永続記憶域ディレクトリを再配置するための詳細な手順

- 12.3 Business Transaction Managementシステムのセキュリティ

- 12.3.1 認証およびロール・マッピング

- 12.3.1.1 初期アプリケーション・ロール・マッピングのサマリー

- 12.3.2 Business Transaction Managementアプリケーションのユーザー・ロール

- 12.3.2.1 プライマリ・ロール

- 12.3.2.2 補助ロール

- 12.4 Business Transaction Managementのバックアップおよびリストア

- 12.4.1 バックアップ処理とリストア処理について

- 12.4.1.1 バックアップの前に

- 12.4.1.2 バックアップ手順とリカバリ手順のテスト

- 12.4.2 Business Transaction Managementのバックアップ

- 12.4.2.1 Business Transaction Managementデータの編成方法

- 12.4.2.2 Business Transaction Managementデータのバックアップ

- 12.4.2.3 バックアップのタイミング

- 12.4.3 Business Transaction Managementのリストア

- 12.4.4 データ記憶域のリファレンス

- 12.5 データの移行

- 12.6 ロード・バランサの設定

- 12.6.1 ロード・バランサの設定

- 12.6.1.1 基本的な用語

- 12.6.1.2 サポートされているデバイス

- 12.6.1.3 デフォルトのロード・バランサ

- 12.6.1.4 管理コンソールを使用したロード・バランサの登録

- 12.6.1.5 ロード・バランサに関する情報の変更

- 12.6.1.6 ルーティング関係を示すエントリ・ポイントの追加

- 12.6.1.7 ロード・バランサの登録解除

- 12.6.2 レプリケート対象モニターを使用するためのF5デバイスの構成

- 12.7 検出問題の解決

- 12.7.1 サービス・バージョニング・ポリシーの変更

- 12.7.2 レプリケーションの問題の解決

- 12.7.3 重複の問題の解決

- 12.7.4 コンソールを使用したエンドポイントの明確化

- 12.8 その他の管理トピック

- 12.8.1 サービスの登録解除

- 12.8.2 システム・サービスのステータスの確認

- 12.8.2.1 システム・アラート

- 12.8.2.2 「ステータス」タブ

- 12.8.3 システムの再同期および稼働ステータスのチェック

- 12.8.3.1 自動稼働ステータス・チェックの時間間隔の変更

- 12.8.4 エンドポイントの監視の開始および停止

- 12.8.5 コンテナの使用

- 12.8.5.1 コンテナの監視

- 12.8.5.2 コンテナの登録解除

- 12.8.6 システム・ポリシーの使用

- 12.8.6.1 システム・ポリシーへのアクセス

- 12.8.6.2 システム・ポリシー定義の表示

- 12.8.6.3 システム・ポリシーの定義および変更

索引

はじめに

Oracle Enterprise Manager Business Transaction Managementオンライン・ヘルプでは、エラーの検索およびパフォーマンスの向上のために、Business Transaction Management 12c リリース5 (12.1.0.6)を使用して、サービスの検出、トランザクションの定義と追跡、パフォーマンスの監視、サービス・レベル合意の定義、失敗の監視および根本原因分析を実行する方法について説明します。

対象読者

このドキュメントは、分散アプリケーションの開発および管理に関心のある開発者およびシステム管理者を対象にしています。

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

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について説明します。内容は次のとおりです。

- Business Transaction Managementの使用方法

- 新機能および変更点

- Business Transaction Managementのアーキテクチャの概要

以前のバージョンからアップグレードする場合は、1.4項「機能アップグレードの問題」を参照してください。

1.1 Business Transaction Managementの使用方法

Oracle ManagementパックのコンポーネントであるBusiness Transaction Managementを使用すると、次のことを実行できます。

- アプリケーション環境にデプロイされたサービスを検出し、どのように機能するかを把握します。
Business Transaction Managementでの検出と監視が可能なサービスおよびコンポーネントのタイプの完全かつ最新のリストは、Business Transaction Management動作保証マトリックスを参照してください。このドキュメントは、http://support.oracle.comで「BTM動作保証」を検索すると参照できます。

- トランザクションを定義および追跡し、トランザクションのコンシューマやビジネス・ペイロードなど、各トランザクションのビジネス・コンテキストを把握します。

- リアルタイムでサービスおよびトランザクションのパフォーマンスを監視します。

- サービス・レベル合意を定義し、ビジネス基準に基づいてパフォーマンス・ターゲットを設定し、これらのターゲットを基準としてパフォーマンスを監視します。

- 異常な状態を警告するアラートを生成します。

- 障害を監視し、根本原因の分析を実行して、ボトルネック、エラーおよび不完全なトランザクションを見つけます。

Business Transaction Managementの使用に関するワークフローの詳細は、第2章「Business Transaction Managementの開始」を参照してください。

管理コンソールを使用して、Business Transaction Management機能セットにアクセスします。コンソールの使用の詳細は、第3章「管理コンソールの使用方法」を参照してください。

コマンドライン・インタフェース(CLI)を使用してスクリプトや個別のコマンドを実行することもできます。CLIの使用の詳細は、第10章「コマンドおよびスクリプト」を参照してください。

Enterprise Managerコンソールから一部のBusiness Transaction Management機能にアクセスすることもできます。詳細は、「新機能および変更点」を参照してください。

1.2 新機能および変更点

この項では、追加された新機能および最終リリースからの変更点について説明します。

- SOA_B2Bプローブ – SOAアプリケーションのSOA B2B (企業間)アダプタを監視します。

- アウト・オブ・バンド検出 - オブザーバが新規コンポーネントの検出を試みる際の動的検出期間を有効化します。オブザーバの詳細設定で有効化されるこの機能の詳細は、12.1.2.11項「詳細設定フィールドのリファレンス」を参照してください。

- SOA 12.1.3 - Business Transaction Managementは、Oracle SOA Suiteリリース12.1.3と互換性があります。

- SOA_RESTアダプタ - SOAアプリケーション(SOAリリース12.1.3のみ)のSOA RESTアダプタを監視します。

- OSB 12c - Business Transaction Managementは、Oracle Service Busリリース12cと互換性があります。この機能を使用するには、WebLogic 12オブザーバをインストールします。

Business Transaction Managementでの検出と監視が可能なサービスおよびコンポーネントのタイプの完全かつ最新のリストは、Business Transaction Management動作保証マトリックスを参照してください。このドキュメントは、http://support.oracle.comで「BTM動作保証」を検索すると参照できます。

1.3 アーキテクチャの概要

Business Transaction Managementは、最高レベルで次の3つのタイプのコンポーネントで構成されています。

- セントラル・サーバー: セントラル・サーバーは、アプリケーション・サーバーにデプロイするアプリケーションEARファイルです。3つのセントラル・サーバーがあります。これらのサーバーについて、それぞれ1つのインスタンスのみをデプロイします。パフォーマンス上の理由から、各サーバーを個別のアプリケーション・サーバーにデプロイする必要があります。監視対象のサービスまたはコンポーネントをホストするアプリケーション・サーバーには、いずれのセントラル・サーバーもデプロイしないでください。次のセントラル・サーバーがあります。

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

- パフォーマンス・サーバー(btmPerformanceServer.ear): サービス・レベルの管理コンポーネントが含まれています。btmMain.earまたはbtmTransactionServer.earがデプロイされているアプリケーション・サーバー以外のアプリケーション・サーバーにbtmPerformanceServer.earをデプロイします。

- トランザクション・サーバー(btmTransactionServer.ear): トランザクション管理コンポーネントが含まれています。btmMain.earまたはbtmPerformanceServer.earがデプロイされているアプリケーション・サーバー以外のアプリケーション・サーバーにbtmTransactionServer.earをデプロイします。

- オブザーバ: オブザーバは、監視対象のビジネス・アプリケーションをホストするアプリケーション・サーバーにインストールする一覧のライブラリです。オブザーバは、アプリケーションのコンポーネント間のメッセージおよびコールを監視します。オブザーバは、多くのタイプのコンポーネントを監視でき、JavaEE、OSB、WCFなど、オブザーバが監視するタイプに基づいて分類されます。

- モニター(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コンポーネントが複数のマシンおよびアプリケーション・サーバーにデプロイされている分散アプリケーション環境で使用するように設計されています。

技術的に、すべてのセントラル・サーバーを単一のアプリケーション・サーバーにインストールできますが、そのようなデプロイメント・シナリオは本番環境ではお薦めしません。単一のアプリケーション・サーバーへのインストールは、デモンストレーションや製品の使用方法を学習する場合には有用ですが、このシナリオは、たとえば数多くのビジネス・サービスや大量のメッセージ・トラフィックに対しては正常に対応できない可能性があります。

各セントラル・サーバーを個別のアプリケーション・サーバーにデプロイすることをお薦めします。特にパフォーマンス・コンポーネントとトランザクション・コンポーネントは、通常、パフォーマンス分析に関する大量の計算を実行します。アプリケーション・サーバー間でプロセスを分割することにより、メモリーとプロセッサのリソースを制御できます。

また、セントラル・サーバーとは別のアプリケーション・サーバーにモニターをデプロイする必要があります。監視の要件に応じて、複数のモニターをデプロイする必要がある場合があります。モニターは、シングルトンまたはレプリケートとしてロード・バランサの背後にデプロイできます。モニターのレプリケートの詳細は、『Business Transaction Managementインストレーション・ガイド』を参照してください。

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

1.4 機能アップグレードの問題

Business Transaction Managementでは、リリース12.1.0.2、12.1.0.3、12.1.0.4または12.1.0.5からアップグレードするための簡単なプロセスが提供されています。

アップグレード・プロセスで、管理構成、オブジェクト定義および既存の操作データを保持しつつ、停止時間が最小化されます。

システムのバックアップおよびアップグレードに使用されるプロセスの詳細は、『Business Transaction Managementインストレーション・ガイド』を参照してください。

この項では、Business Transaction Managementによるトランザクションの監視や通信の保護機能に影響を与える可能性がある、このアップグレードで導入された変更点について説明します。ここに含まれる項を読み、製品の変更点がトランザクション定義およびトランザクションを監視するBusiness Transaction Managementの機能にどう影響するかを理解する必要があります。アップグレード後、いくつかのトラフィックを実行してトランザクション・インスタンスを監査し、システムで期待どおりにトランザクションが監視されていることを確認することをお薦めします。そのようでない場合は、状況に応じて、オブザーバ通信ポリシーの調整、トランザクション定義の更新またはノード間への手動キーイングの追加が必要となる場合があります。

次の各項を読んだ後も12.1.0.5リリースへのアップグレードについて不明な点がある場合は、Oracleテクニカル・サポートでサービス・リクエストをオープンしてください。

1.4.1 WebLogic 10.3サーバー用の汎用オブザーバの影響

12.1.0.3より前のリリースでは、WebLogic 10.3サーバーにインストールするための様々なオブザーバが提供されていました。各タイプのオブザーバには、特定のコンポーネント・タイプを監視する機能を提供する一連のプローブが含まれていました。たとえば、JavaEEオブザーバにはJavaEEコンポーネントを監視するプローブが、SOAオブザーバにはSOAコンポーネントを監視するプローブが含まれていました。12.1.0.3以降のリリースでは、WebLogic 10.3サーバーにインストールするための単一の汎用オブザーバが提供されています。この汎用オブザーバには以前のオブザーバに含まれていたすべてのプローブのスーパーセットが含まれているため、以前に監視可能であったコンポーネント・タイプのスーパーセットの監視が可能となります。

汎用オブザーバにアップグレードすると、システムで新しいタイプのコンポーネントを検出および監視できるようになります。この拡張機能により新規オブジェクトが検出され、次に説明するようにトランザクションの表示および監視機能に影響を及ぼす可能性があります。

A→B→Cというトランザクションがあり、新たにB1という操作が監視されると(コール・チェーンはA→B→B1→Cになります)、使用される相関方法に応じて次の2つの結果が考えられます。

- 自動相関: 操作Cはグレーで表示されます。BからCに欠落メッセージ条件が定義されている場合は、アラートを受信します。トランザクションを再定義してCを表示可能にし、トランザクションを監視対象にする必要があります。AからB、Cへのメッセージが変化しないというまれな状況では、システムでCが引き続き監視されます。

- 手動相関: 操作Cが表示可能になり、Bと相関します。新しく監視された操作B1は、依存関係グラフで表示可能になりますが、トランザクション定義では表示可能になりません。トランザクションを再定義してB1を表示可能にする必要があります。この場合、トランザクションは監視されますが、B1はその中に含まれません。

アップグレード・プロセスでは、既存のオブザーバ通信ポリシーの値が継承されます。つまり、既存のポリシーでほとんどのプローブ・フィールドがアクティブ化されており、WebLogic汎用オブザーバへのアップグレードを行い、以前は検出されなかったが現在はアクティブ化されたプローブがあるコンポーネント・タイプがアプリケーション・サーバーでホストされる場合、これらは検出および監視されます。

検出および監視するコンポーネントの数を関心のあるものだけに制限する場合は、アップグレードの前に、オブザーバ通信ポリシーでアクティブ・プローブを確認および調整できます。作業内容を確認し、汎用オブザーバの使用により発生する変更内容を判断するには、WebLogic 10.3コンテナで実行される操作に含まれるすべてのトランザクションを監査する必要があります。

オブザーバの詳細は、12.1.1項「オブザーバについて」を参照してください。オブザーバのアップグレードの詳細は、『Business Transaction Managementインストレーション・ガイド』を参照してください。

1.4.2 検出の制限に対する新規デフォルト設定の影響

基礎となるテクノロジによっては、クライアントから直接サービス・エンドポイントに流れるメッセージもありますが、その他のメッセージは実際の宛先に到達する前に中間エンドポイントのホストを通過します。このような中間エンドポイントは、メッセージ・システム、ジョブ・スケジュール・システム、分散システムなどの実装で構成されている場合があります。

中間エンドポイントを使用するテクノロジのプローブをインストールしている場合、Business Transaction Managementを使用すると、このようなシステムのすべてのエンドポイントを監視するか、またはエッジにあるエンドポイントのみを監視するかを指定できます。多くの場合、これらは目的のビジネス・サービスを直接示すエンドポイントです。現在のリリースでは、デフォルトで中間エンドポイントの監視はオフになっています。これによって、監視のパフォーマンスが向上し、分散アプリケーションの監視に不要なデータが排除されます。

中間エンドポイントの監視がオンになっているシステムからアップグレードする場合、Business Transaction Managementでは、新規のデフォルト設定にアップグレードした後、これらのエンドポイントの設定が保持されます。これらのエンドポイントは依存関係グラフで確認できます。これらはトランザクション・グラフではグレー表示されます。トランザクション定義を編集してこれらのエンドポイントを削除できます。

デフォルト設定が示すように、中間エンドポイントの監視をオフにすることをお薦めします。

検出の制限の詳細は、4.1.3項「検出の制限」を参照してください。

1.4.3 新規認証設定の影響

現在のリリースのBusiness Transaction Managementでは、オブザーバ認証が導入されており、オブザーバとモニター間の通信でSSLがデフォルトでオンに設定されています。これらの機能の詳細は、『Business Transaction Managementインストレーション・ガイド』を参照してください。現在のリリースでは、新しいオブザーバ通信ポリシーを作成すると、クライアント認証およびSSLがデフォルトでオンになります。

ほとんどの場合、システムをアップグレードしても予想される動作に影響はありません。次に説明するように、オブザーバとモニター間の通信に影響を及ぼす例として、旧オブザーバと新規通信ポリシーを組み合せる場合があります。

- 既存のオブザーバが、SSLを使用しないモニターと通信を行っています。アップグレードを行っても、何も変わりません。新規オブザーバは旧オブザーバと同じように動作します。動作を変更するには、オブザーバ通信ポリシーを編集してSSLまたはオブザーバ認証を追加します。

- 既存のオブザーバがSSLを介してモニターと通信を行っています。アップグレードを行っても、引き続き同じように動作します。クライアント認証を追加する場合は、オブザーバ通信ポリシーをそのように編集する必要があります。

- フィールドに旧オブザーバが存在しており、セントラル・サーバーとモニターをアップグレードします。旧オブザーバに適用する新規オブザーバ通信ポリシーを作成すると、旧オブザーバはモニターに対して認証できず、モニターは旧オブザーバがそのモニターに送信するデータを認識できないため、旧オブザーバは失敗します。新規オブザーバが使用可能で、クライアント認証を使用する場合は、新規オブザーバをインストールしてください。新規オブザーバを使用できない場合は、オブザーバ通信ポリシーで認証をオフにしてください。

1.4.4 新規プローブの影響

リリース12.1.0.6のWebLogic 10.3用の汎用オブザーバでは、次のプローブが提供されています。

- SOA_B2B – SOAアプリケーションのSOA B2B (企業間)アダプタを監視します。

リリース12.1.0.5のWebLogic 10.3用の汎用オブザーバでは、次のプローブが提供されています。

- SOA_JCA: SOA JCAアダプタを監視します(AQ、データベース、ファイル、FTP、JMS、MQシリーズ、ソケット、Oracle Applicationsなど)。

リリース12.1.0.4のWebLogic 10.3用の汎用オブザーバでは、次のプローブが提供されています。

- SOA_WORKFLOW: Oracle SOAヒューマン・ワークフローのコンポーネントおよび通知を監視します。

- SOA_DIRECT: SOAコンポジット間およびSOAとOracle Service Bus間の直接バインディング・コールを監視します。

新規プローブを含むオブザーバにアップグレードすると、そのプローブは、作成するすべての新規オブザーバ通信ポリシーですぐに使用可能になります。ただし、プローブは既存のポリシーに自動的には追加されません。既存のポリシーで新規プローブのいずれかを使用する場合は、手動でポリシーに追加する必要があります。プローブをポリシーに追加する方法の詳細は、12.1.2.3項「プローブの追加」を参照してください。

アクティブ化後、新規プローブのタイプによって新規タイプのコンポーネントが検出されます。定義したトランザクションのフロー内でこれらの新しく検出されたコンポーネントのいずれかがコールされる場合は、トランザクションを完全に監視することができなくなります。トランザクションの監視は、新しく検出されたコンポーネントの部分で終了します。

トランザクションを完全に監視するには、次のいずれかの方法でトランザクションを編集する必要があります。

- 非結合ノードのキーイングを手動で行うことにより、トランザクションを元の状態に戻します。

- 新しく検出されたコンポーネントを新規ノードとしてトランザクションに追加し、それを非結合ノードに接続することにより、トランザクションを拡大します。

1.4.5 モデル構成設定での新規JMSオプションの影響

セントラル・サーバーとモニターをアップグレードすると、作成するすべての新規オブザーバ通信ポリシー用に(既存のポリシーは影響を受けません)、新規JMSオプションが「詳細設定」の「モデル構成」セクションに追加されます。デフォルトで、この新規JMSオプションは「フローのエッジのモデル化」に設定されます。この設定では、JMSトピック・メッセージ・リスナーのみがモデル化されます。すべてのJMSトピック、JMSキューおよび関連メッセージ・リスナーをモデル化する場合は、JMSオプションを編集して「すべてモデル化」に設定する必要があります。

詳細は、「モデル構成」のエントリを参照してください。

1.4.6 改善されたJMSプローブの影響

リリース12.1.0.4では、以前のリリースに含まれるJMSプローブに置き換わる、大幅に改善されたWebLogic用のJMSプローブが新たに提供されています。新規JMSプローブは次のオブザーバに含まれています。

- WebLogic 10.3用の汎用オブザーバ

- WebLogic 12.1用のJavaEEオブザーバ

セントラル・サーバーとモニターをアップグレードした後、これらは新旧両方のJMSプローブで互換性が維持されます。オブザーバをアップグレードする必要はなく、アップグレードしない場合は、引き続き以前と同様に動作します。アップグレードされたオブザーバとアップグレードされていないオブザーバが混在するシステムを実行することもできます。ただし、すべてのオブザーバをアップグレードすることをお薦めします。

アップグレード後、オブザーバによってシステムのJMSコンポーネントが再検出され、新規タイプのJMSサービスとしてモデル化されます。キューおよびトピックはタイプ「JMSリソース」のサービスとしてモデル化され、メッセージ・リスナーはタイプ「メッセージ・リスナー」のサービスとしてモデル化されます。(旧JMSプローブによって検出される)旧JMSサービスは引き続き表示されますが、システム内を流れるビジネス・トラフィックを登録しません。旧サービスのタイプは「JMSメッセージ・コンシューマ」です。これらの旧JMSサービスの登録を解除する必要があります。

旧JMSサービスを含むトランザクションは正しく機能しなくなります。旧トランザクションを削除し、新しく検出されたJMSサービスを使用して再定義する必要があります。

2 Business Transaction Managementの開始

この章では、Business Transaction Managementを使用するための基本ワークフローについて説明します。また、オンライン・ヘルプの主要セクションの紹介としても役立ちます。この章は、このマニュアルの残りの部分に進む前に参照する必要があります。

BTMを使用する方法のデモンストレーションを表示するには、次のURLにアクセスして「Begin Video」をクリックします。

https://apex.oracle.com/pls/apex/f?p=44785:24:539253248237801::NO:24:P24_CONTENT_ID,P24_PREV_PAGE:6366,1

2.1 基本ワークフロー

Business Transaction Managementを使用するための基本ワークフローには、次の手順が含まれます。

- トラフィックの実行

- サービスおよび依存性の検出

- 対象領域の識別

- トランザクションの定義

- トランザクション監視の必要性の評価

- スクリプトの作成

2.1.1 トラフィックの実行

Business Transaction Managementの検出プロセスは、完全にトラフィックベースです。監視対象のエンドポイントをメッセージが流れていない場合、システムでアプリケーション・コンポーネントを検出することも、これらのコンポーネント間の依存性を検出することもできません。そのため、Business Transaction Managementを使用するための最初の手順は、トラフィックを実行し、メッセージ・トラフィックを監視する機会をシステムに与えるために少しの時間そのままにして、デプロイされたシステムの図を作成することです。

Business Transaction Managementを使用するのが初めての場合、次に実行が必要なことは、管理コンソールを表示して、その基本部分および構成をおおまかに理解することです。トラフィックが実行済の場合、管理コンソールを開くと、サービスおよびその依存性を確認できます。少し時間をかけてコンソールの基本動作について理解します。

- 「管理コンソールについて」では、管理コンソールの各部分と構成について説明しています。

- 「データの表示」では、管理コンソールを使用して様々なデータ・タイプを表示する方法について詳細に説明しています。パフォーマンス・データを示すのに使用する基本要素(マップ、チャート、表形式ビューおよびダッシュボード)についても説明します。この説明は、今参照することも、後でパフォーマンス情報を表示および解析するときに参照することも可能です。

2.1.2 サービスおよび依存性の検出

トラフィックを実行すると、Business Transaction Managementはすぐにデータの収集を開始し、使用している環境の全体図を提供して作業の流れを理解できるようにします。分散アプリケーションを構成するコンポーネントを識別し、これらのコンポーネントの相互関係を理解することで、「どのようなコンポーネントがあるか」および「何が実行されているか」という2つの質問に回答できるようになります。

Business Transaction Managementでは、表形式ビューおよびグラフィカル・ビューを使用して、トポロジおよびパフォーマンス情報が表示されます。次のスクリーン・ショットに、エンドポイントの依存性、ステータスおよびパフォーマンス・データが1つのグラフィカル・ビューにどのように表現されるかを示します。

まず最初に使用している環境を参照したときには、監視対象のコンポーネントを実行しているコンテナの場所とステータスを把握します。次に、サービスを表示して、監視対象のすべてのサービスが検出されていることを確認します。続いて、サービスが相互にやり取りする方法と、サービスがレプリケートされている場合にトラフィックがサービスに分散される方法について確認できます。

ここで、検出できないサービスの登録、レプリケーションまたは重複の問題の解決、バージョニング問題の対応などを実行して、作成された図を調整することが必要になる場合があります。

2.1.3 対象領域の識別

環境内のサービス操作の正確な全体図が作成されると、今度は操作データに注目できるようになります。デフォルトでは、スループット、トラフィック、フォルト、平均レスポンス時間、最大レスポンス時間および稼働時間のデータがシステムによって表示されます。これにより、ボトルネック、障害のあるコンポーネント、速度の遅いコンポーネント、異常に軽いまたは重いトラフィックを特定できます。

フィルタを使用して、表示されるサービスの数を絞ることができます。また、表形式ビューに表示されるコア測定にインスツルメントを追加して、ビューをカスタマイズすることもできます。

この情報を使用して、サービスのレプリケート、その他の処理容量の調整、障害のあるコンポーネントの詳細な調査など、デプロイメントのトポロジの変更を決定できます。

2.1.4 トランザクションの定義

トランザクションは、1つの単位として監視する一連の操作です。Business Transaction Managementでは、トランザクションの監視に重点を置いて、パフォーマンス関連の問題の特定と解決、使用状況のプロファイリング、ビジネス・プロセスで問題のあるコンポーネントの原因特定を支援します。

検出で明らかになる依存性に基づいて、目的の相互作用を備えたサービスを含めるようにトランザクションを定義できます。制御下にないサービスを除外したり、パフォーマンスに適切な効果があると思われる補助サービスを含めるよう決定することができます。トランザクションの定義は簡単です。一連の操作の開始操作と終了操作を特定します。その後、様々な観点からのトランザクション調査を可能にする追加機能を有効にできます。

2.1.5 トランザクション監視の必要性の評価

デフォルトでは、Business Transaction Managementは単にトランザクションの基本パフォーマンスを監視します。パフォーマンスおよび使用状況について、必要な詳細レベルを正確に提供する監視機能が有効になるように、デフォルトのトランザクション定義を変更できます。たとえば、次の処理を可能にする機能を追加できます。

- ホスト・アドレス別または使用状況別のパフォーマンス情報の分割。使用状況は、ユーザー別、サプライヤ別または有用なパフォーマンス情報の取得に役立つ基準別にまとめることができます。

- トランザクション・インスタンスのロギング。

- メッセージ・コンテンツのロギング。これによって特定の情報のログ・メッセージを検索できます。たとえば、「15,000冊の書籍の注文を含むメッセージはどれか」などです。

常に収集され、いつもで表示できるパフォーマンス情報に加えて、ビジネス・トランザクションでは次のような特別な場合に警告を送信できます。

- 固定値または過去の基準に基づいてサービス・レベル合意を定義し、パフォーマンスが定義済のしきい値を超えた場合には必ず通知するよう要求している場合。たとえば、トランザクションのスループットが直近の10分間で100リクエストよりも下がった場合に通知を受けるなどです。

- メッセージ・コンテンツまたは特定のフォルトをテストする条件を定義し、この条件に一致した場合に通知するよう要求している場合。たとえば、注文数量に関連するプロパティの値が1,000よりも大きい場合に通知を受けるなどです。

- 特定期間内のメッセージの到着をテストする条件を定義し、メッセージが到着しなかった場合に通知するよう要求している場合。これを使用して、完了していないトランザクションについての警告を受け取ることができます。

ご覧のように、Business Transaction Managementでは、トランザクションを監視するための様々なオプションが提供されています。これらの監視技術のいずれを使用するかは、ユーザーが回答する質問およびユーザーが解決しようとする問題によって異なります。このような質問は、開発からテスト、本番へと進むにつれて変わる可能性があります。監視機能を選択的に有効および無効にできるシステムを作成することにより、管理システムのパフォーマンス・コストを最小限に抑えながら、必要な情報を正確に取得できるようにすることが可能です。

2.1.6 スクリプトの作成

最後に、Business Transaction Managementの使用について学習し、任意でアーカイブおよび実行する処理(特に管理タスク)を識別するときに、コマンドライン・インタフェースを使用してスクリプトを作成できます。このようなスクリプトを使用すると、次の処理を実行できます。

- システムの構成

- 検出問題の解決

- サービスの登録

- レプリケーション問題の解決

- データの移行

- レポートの生成

3 管理コンソールの使用方法

この章では、Business Transaction Managementコンソールを使用するプロセスについて説明します。内容は、次のとおりです。

- 管理コンソールについて

- データの表示

- 新規ビューの作成

- 管理コンソール参照

3.1 管理コンソールについて

Business Transaction Managementコンソールでは、スフィアに認識されているオブジェクトに関する情報を確認し、これらのオブジェクトを監視および管理するためのツールにアクセスできます。情報は、様々なタイプのビュー(ダッシュボード、チャート、マップ、グラフ、表など)を使用して表示されます。この項では、コンソールの主な領域(ナビゲータ、メイン領域、タブ領域およびメイン・メニュー)について説明します。

Business Transaction Managementを初めてインストールすると、コンソールにはスフィアのオブジェクトに関する一連のデフォルト・ビューが示されます。追加のビューを作成および保存して、関連するオブジェクトやインスツルメントにより簡単にアクセスできるようにすることができます。また、カスタム・データ・エクスプローラを使用すると、システムの任意のオブジェクトをその他の任意のオブジェクトとの関連で表示できます。

この項での説明に続き、この章の残りの項では次の内容について説明します。

- 各タイプのビューで使用されるコントロール

- デフォルト・ビューの解釈

- ビューの変更

- 新規ビューの作成

コンソール以外にBusiness Transaction Managementコマンドライン・インタフェース(CLI)を使用して、コマンドラインやスクリプトを使用して管理コマンドを発行することもできます。CLIコマンドを使用して、システムの構成、DNS別名の管理、レプリケーション問題の解決、サービスの登録、メタデータの管理、監視の制御、ポリシーの適用、データの移行またはレポートに必要なデータの生成を行います。

3.1.1 一般的なコンソールの設計

次の図に、管理コンソールの主な領域を示します。

この後の各項では、それぞれの領域の詳細を説明します。概要は次のとおりです。

- ナビゲータには、デフォルトで使用可能なビューのリストが表示されます。いずれか1つの項目を選択すると、そのタイプのすべてのオブジェクトがメイン領域に表示されます。

- メイン領域には、ナビゲータで選択したビューが表示されます。メイン領域で任意の項目をダブルクリックすると、タブ領域がまだ開いていない場合はタブ領域が開き、その項目の詳細な情報が表示されます。メイン領域の最上部には、表示されたオブジェクトのフィルタに使用できるコントロールがあります。

- メニューによって、メイン領域で選択した項目に対して実行できるアクションが提供されます。また、新規オブジェクトの登録や管理アクションの実行など、選択した項目に関連しないアクションも提供されます。

- タブ領域では、メイン領域で選択した項目に関する追加情報が提供されます。

3.1.2 ナビゲータ

ナビゲータは、必要なオブジェクトおよび関係を迅速に取得できるようにする役割を果たします。デフォルトのナビゲータ・セクションは、次のとおりです(これらのセクションは通常、展開された状態で表示されます)。

ナビゲータには、次の2種類のコントロールがあります。

- 右上隅の最小化コントロール(矢印)。このコントロールをクリックしてナビゲータを縮小すると、メイン領域を広げることができます。

- 各ビュー名の左側にある展開コントロール(三角形)。このコントロールをクリックすると、カテゴリ・コンテンツを展開して表示できます。

「エクスプローラ」ビューの各項目には、小カッコで囲まれた数値が含まれています。これは、スフィアで認識されているオブジェクトの数を表しています。より少ない項目を表示するために対応するメイン・ビューをフィルタした場合、ナビゲータに表示される数は変更されないままとなります。

次の表に、ナビゲータのデフォルト・カテゴリのコンテンツの概要を示します。

カテゴリ

説明

マイ・ビュー

変更または作成し、保存したビューのリスト。

ダッシュボード

ダッシュボードは、複数のより小さいビューで構成された異種ビューであり、通常、対象となる情報の要約に使用されます。システムおよび監視対象のオブジェクトの状態のサマリー・ビューが提供されます。
デフォルトでは、コンソールには3つのダッシュボードがあります。1つはシステムの操作状態を要約し、2つは上位10件のサービスおよびトランザクションのサマリー情報を提供します。

マップ

サービスとその依存性およびコンテナのグラフィカル・ビュー。

エクスプローラ

監視対象および監視非対象のオブジェクトとその関係の表形式ビュー。スフィアの任意のオブジェクトをその他のオブジェクトとの関連で表示できるカスタム・データ・エクスプローラも含まれています。

過去1時間のアラート

すべてのアラート・タイプ(SLA、条件およびシステム)の表形式ビュー。

管理

システム・サービス・コンテナ、システム・サービス、システム・ポリシー、監視および未割当てエンドポイントの表形式ビュー。

3.1.3 メイン領域

メイン領域では、ナビゲータで選択した項目(「ダッシュボード」および「マップ」カテゴリの項目を除く)の表形式ビューが表示され、表のすぐ上に、列および表示する項目数のフィルタに使用できる一連のコントロールが表示されます。次に、ナビゲータで「コンテナ」が選択されている場合のメイン領域の表示内容の例を示します。

メイン領域の右下隅にある上/下コントロールを使用して、タブ領域を開閉します。メイン領域のサイズを制御するには、メイン領域とタブ領域の境界のスライダ・コントロールを移動します。

3.1.4 メニュー

メニュー項目は、メイン領域またはタブ領域で現在選択されている項目に直接関連します。メイン領域またはタブ領域の項目を名詞、メニュー項目の項目を動詞と考えることができます。つまり、メニュー項目を選択すると、メイン・ビューまたはタブ・ビューで選択されている項目に影響を与えるアクションが実行されます。

メニュー項目は非表示になりませんが、現在の選択項目に操作を適用できない場合、現在選択しているオブジェクトが適切な状態ではない場合またはユーザーがターゲットへの操作を認可されていない場合は、メニュー項目を無効にすることができます。ユーザー・ロールの詳細は、ここをご覧ください。

3.1.5 タブ領域

タブ領域はタブ付きパネルで編成されます。表示されるタブは、サマリー領域で選択されている項目によって異なります。

タブ領域を縮小するには、メイン領域の右下隅にある矢印コントロールを使用します。タブ領域を再度展開するには、メイン領域で項目をダブルクリックするか、またはサマリー・ペインの右下隅にある上矢印をクリックします。

3.1.6 オブジェクト詳細ウィンドウ

コンソールでは、インスペクタ・ウィンドウまたは選択したオブジェクトのタブ領域を含む別個のウィンドウにアクセスできます。このビューは、ティアオフ・コントロール(拡大鏡)が表示されたオブジェクトまたは領域で使用できます。コントロールをクリックすると、選択項目に関する追加情報が表示された別個のウィンドウが開きます。表示される情報は、選択したオブジェクトによって異なります。

3.2 データの表示

スフィアで認識されている、アプリケーションを構成するサービス、エンドポイントおよび操作に関するすべてのデータは、様々なタイプのビュー(グラフィカル・ビュー、チャート、表形式ビューおよびダッシュボード)を使用して表示されます。この情報は、データの検索および解釈を容易に行うことができる形式を使用して表示できます。また、様々なコントロールを使用して、データをフィルタおよびソートして、アプリケーション・パフォーマンスの選択した側面を強調できます。

この項では、データの表示に使用されるコントロールおよびビューについて説明します。まず、すべてのタイプのビューで使用可能なコントロールについて説明し、続いて各タイプの特性について説明します。次のトピックを取り扱います:

- コントロールの表示

- マップの表示

- チャートの表示

- 表の表示

- ダッシュボードの表示

3.2.1 コントロールの表示

コンソールでは、データはグラフ、表、チャートおよびダッシュボードを使用して表示されます。この項では、データの表示方法に関係なく使用可能なコントロールについて説明します。1つのタイプのビューに固有のコントロールについては、そのタイプに関する項で説明します。

すべてのタイプのビューでは、コントロールを使用して、表示されている情報のフィルタ、表での列の追加や削除またはデータがレポートされる時間間隔の変更を行うことができます。コントロールを使用すると、追加情報を表示したり、別個のウィンドウに情報を表示することもできます。

3.2.1.1 フィルタリング・コントロール

フィルタリング・コントロールを使用すると、サービス・マップおよび表形式データをフィルタできます。Business Transaction Managementには、ディープとシャローの2種類のフィルタがあります。すべてのビューで両方のタイプが提供されるわけではありません。次の図に、これらのコントロールを示します。

ディープ・フィルタでは、フィルタ・コントロールを使用して指定した制約に基づいてスフィアからデータを再フェッチすることによってビューを変更します。シャロー・フィルタでは、現在コンソールに表示されている内容のみを制限します。したがって、たとえば、名前に「Order」が含まれている項目のみを表示するシャロー(検索対象)フィルタを使用すると、現在のビューがリフレッシュされ、該当する項目のみが表示されます。

ディープ・フィルタは、次の2つの方法で定義できます。

- ドロップダウン・リストから事前定義済フィルタを1つ選択します。ドロップダウン・リストにリストされる選択肢には、ナビゲータで選択されているオブジェクトに最もよく必要とされるフィルタ基準が含まれています。

- ドロップダウン・リストの「フィルタの選択...」項目を選択して、フィルタ・ツールを開き、必要な基準を指定します。
フィルタ・ツールでは、顕著な特性(属性)に基づいてオブジェクトをフィルタできます。そのような特性は、ナビゲータで選択されているオブジェクト(サービス、コンテナ、ポリシー、デバイス、コンシューマなど)によって異なります。フィルタ・ツールに属性がリストされていない場合は、その属性に基づいてビューをフィルタできません。

フィルタ・ツールの詳細は、3.4.3項「フィルタ・ツールの使用方法」を参照してください。

3.2.1.2 列チューザおよびサイズ設定コントロール

表表示を(列の追加または削除によって)変更するコントロールおよび列のサイズを変更するコントロールは、表ビューのすぐ上に表示されます。次の図に、列チューザとそのドロップダウン・リストを示します。また、表にすべての列が表示されるように列のサイズを変更できるサイズ設定コントロールも示します。

列を表示しない場合は、「列なし」を選択します。「列の選択....」を選択すると、列の追加または削除に使用できるツールがBusiness Transaction Managementに表示されます。

3.2.1.3 時間間隔コントロール

時間間隔コントロールを使用すると、インスツルメント・データをフェッチおよび表示する間隔を指定できます。このコントロールは、設定場所に応じて異なる場所に表示され、効果が異なります。これは時計アイコンとして表示されるか、または「時間間隔」というラベルが付いたドロップダウン・リストとして表示されます。

- 列チューザ(「インスツルメント」タブ)では、このコントロールを使用して、インスツルメント・データを取得する間隔を指定できます。この間隔は動的にするか、または10分、1時間、1日または7日間の固定期間を選択できます。「動的」を指定すると、メイン・ペインに表示された時間間隔コントロールによって間隔が設定されます。

- メイン領域では、時間間隔コントロールが表示されている場合は、このコントロールを使用して、インスツルメント・データがレポートされる間隔を指定できます。10分、1時間、1日または7日間から選択できます。

- 最も細かい粒度が提供される「分析」ペインでは、最後の固定期間である10分、1時間、1日または7日間に取得された測定を確認できます。また、指定された日時以降に取得された測定を確認できます。あるいは、指定された2つの日時の間に取得された測定を確認できます。

- 「サマリー」ペインでは、最後の固定期間である10分、1時間、1日または7日間に取得された測定を確認できます。また、時間範囲を設定できます。

間隔が日次または週次の場合は、少なくとも要求しただけのデータが取得されるように間隔が拡張されることに注意してください。たとえば、現在2010年12月22日の午前11時20分であり、「過去1日間」を選択した場合、2010年12月21日午前11時から現在までのデータが返されます。同様に、「先週」を選択した場合は、2010年12月15日午前0時から現在までのデータが返されます。

3.2.1.4 ポップアップ・リンクおよびインスペクタ

表の一部の項目には、その項目がクリックしてインスペクタを開くことができるリンクであることを示す下線が付いています。たとえば、「操作状態サマリー」ダッシュボードでは、「稼働中」コンテナを指定する数値がこのようなリンクです。

リンクをクリックして、現在稼働中のコンテナに関する追加情報が表示されたインスペクタ・ウィンドウを開きます。

3.2.1.5 ティアオフ・コントロール

拡大鏡アイコンは、タブ領域を含む、選択したオブジェクトに関する情報が表示された新規ウィンドウを開くことができることを示しています。

3.2.2 マップの表示

マップは関係を表すよい方法です。マップでは、サービス、エンドポイントまたは操作がどのように関連しているかがビジュアルで表示されます。

- すべてのサービスおよびその依存性を表示するには、ナビゲータで「マップ」→「サービス・マップ」を選択します。

- コンテナを表示するには、ナビゲータで「マップ」→「コンテナ・マップ」を選択します。

- 関連サービス、エンドポイントまたは操作のサブセット間の依存性を表示するには、対象となるオブジェクトを選択し、「依存性」タブをクリックします。

- トランザクションを構成する操作間の依存性を表示するには、トランザクションを選択し、「サマリー」タブをクリックします。

次の図に、エンドポイントの依存性を表すマップを示します。

マップ・ビューでは関係に重点を置いているため、Business Transaction Managementでは、これらの関係が不明瞭にならないように、できるだけ明確な図の提供が試行されます。通常は、オブジェクトをつなぐリンクにカーソルを移動するか、またはオブジェクト自体にカーソルを合わせると、追加情報を入手できます。この場合、エンドポイント・アイコンにカーソルを合わせると、エンドポイントのコンテナ、サービスおよびコア・インスツルメント値に関する情報が表示されます。

また、すべてのマップ・ビューには、追加情報を取得したり、使用可能な情報をフィルタリングする場合に使用できる特化されたコントロールが用意されています。これらについては、この後の項で説明しています。

3.2.2.1 マップの表データの表示

マップ・ビューで表アイコンをクリックすると、Business Transaction Managementでは、マップの左側の表に対応するインベントリが表示されます。

表形式ツリー・ビューでは、グラフィックに表示されているオブジェクトの上または下の1つ以上のレイヤーを確認できます。表示の最上部にシャロー・フィルタがあります。このフィルタを使用して、表のコンテンツをさらにフィルタできます。

表形式ツリー・ビューを閉じるには、表アイコンを再度クリックします。

3.2.2.2 マップ・ビューのフィルタおよび調整

マップ・ビューでレンチ・アイコンをクリックすると、Business Transaction Managementで複数のコントロールを使用できます。

- 「レイアウト」コントロールを使用すると、使用されるレイアウトの方向およびタイプを選択できます。

- 「関連の表示」コントロールを使用すると、依存性が表示されているオブジェクトに間接的にのみ関連している追加オブジェクトを表示できます。これらのオブジェクトは、登録することによってマップに手動で追加できるオブジェクトである場合があります。

- 一部のマップでは、このコントロールを使用して現在のビューをフィルタできる場合もあります。

3.2.2.3 マップ・ビューのスケーリング

スケーリング・アイコンを使用すると、現在表示されているマップを展開および縮小できます。

スケーリング・バーを上下にスライドして、マップを必要なサイズにサイズ変更します。スケーリングによって必要な結果が得られない場合は、次に説明するリージョン・コントロールを使用できます。

3.2.2.4 マップの様々なリージョンへのフォーカス

マップが現在のウィンドウに収まらない場合は、マップ・ウィンドウの右下隅にサム・ビュー・コントロールが表示されます。このコントロールを使用して、すべてのブランチが表示されるようにマップを再配置します。

このコントロールを使用するには、白色の四角形をクリックし、ドラッグして、必要に応じてマップを配置します。サム・ビュー・コントロールを縮小するか、または開くには、右下隅の三角形のアイコンを使用します。

3.2.3 チャートの表示

チャートでは、時間の経過に伴うインスツルメント値の変化のグラフィック表示が提供されます。次のチャートでは、トランザクションのレスポンス時間が表示されています。チャートには、凡例およびチャートのデータの表形式表示として機能する表が付いています。チャートからさらに情報を取得するには、グラフ化されたインスツルメント値にカーソルを合わせます。チャートのノードにカーソルを合わせると、Business Transaction Managementでは、そのノードに関連付けられた時点のインスツルメント値が表示されます。

3.2.4 表の表示

表はコンソールのメイン領域に表示されます。

表の上に位置するコンソールでは、表のコンテンツのフィルタ、表示される列の変更またはデータに合わせた列のサイズの変更を行うことができます。また、列のソート、列幅の変更および列の移動も行うことができます。

- 指定した列のソート・オプションを表示するには、列ヘッダーにカーソルを合わせます。ポップアップによってオプションが通知されます。

- 列幅を変更するには、サイズ変更アイコンが表示されるまで列ヘッダーの境界線にカーソルを合わせ、サイズ変更アイコンをドラッグして列の幅を変更します。

- 異なる位置に列を移動するには、列ヘッダーをクリックし、必要な位置までドラッグします。

表に対する変更は、ブラウザを閉じるか、またはリフレッシュすると失われます。変更したビューを保存するには、メニューの「表示」→「現在のビューを保存」を選択する必要があります。ビューに名前を付けて保存すると、ナビゲータの「マイ・ビュー」にリストされます。

3.2.5 ダッシュボードの表示

ダッシュボードは、グラフィカル要素および表形式要素が含まれているコンテナです。ダッシュボードには、システムの側面(トランザクション・パフォーマンス、上位10件のサービスおよび操作状態)のスナップショットが表示されます。ダッシュボードを表示するには、ナビゲータの「ダッシュボード」から1つ選択します。

3.3 新規ビューの作成

次の方法で、新しい一時ビューまたは永続ビューを作成できます。

- 列の追加または削除、列の再配置および列の再ソートによって既存の表を変更できます。

- デフォルト・ビューがないオブジェクトおよび関係に重点を置いた新しい表を作成できます。

作成するビューは、現在のセッションでのみ使用可能です。ただし、後で使用するためにビューを保存できます。保存したカスタム・ビューは、ナビゲータの「マイ・ビュー」カテゴリに表示されます。

3.3.1 表の変更

表表示を(列の追加または削除によって)変更するコントロールおよび列のサイズを変更するコントロールは、表ビューのすぐ上に表示されます。次の図に、列チューザとそのドロップダウン・リストを示します。また、表にすべての列が表示されるように列のサイズを変更できるサイズ設定コントロールも示します。

列を表示しない場合は、「列なし」を選択します。「列の選択....」を選択すると、列の追加または削除に使用できるツールがBusiness Transaction Managementに表示されます。

「列の選択」ツールには、3つのタブ「プロファイル属性」、「ユーザー属性」および「インスツルメント」のいずれかで現在選択されている属性が表示されます。

一番上のボックスには、「プロファイル属性」、「ユーザー属性」および「インスツルメント」の3つのタブのいずれかで現在選択されている、すべての列が表示されます。

3つのタブ付きカテゴリで追加または削除する列を選択できます。まず、タブをクリックし、必要に応じて「検索対象」フィルタを使用し、表示されるオプションを絞り込みます。

- 列を追加するには、必要な属性またはインスツルメントの「使用」列のボックスをクリックします。

- 列を削除するには、必要な属性またはインスツルメントの「使用」列のチェックマークが付いているボックスをクリックします。

ユーザー属性はグラフィック表示でのみ使用されます。ユーザー属性によって、エンドポイントまたはサービスのクライアントが表示されるかどうかが指定されます。

「インスツルメント」タブに表示される時間コントロールは、選択されているすべてのインスツルメントに適用されます。インスツルメントの間隔は複数選択できます。

変更に満足した場合は、「OK」をクリックします。結果のビューに必要な情報があることを確認します。さらに列を移動またはサイズ変更してから、このビューを永続ビューとして保存することもできます。

- 指定した列のソート・オプションを表示するには、列ヘッダーにカーソルを合わせます。ポップアップによってオプションが通知されます。

- 列幅を変更するには、サイズ変更アイコンが表示されるまで列ヘッダーの境界線にカーソルを合わせ、サイズ変更アイコンをドラッグして列の幅を変更します。

- 異なる位置に列を移動するには、列ヘッダーをクリックし、必要な位置までドラッグします。

表に対する変更は、ブラウザを閉じるか、またはリフレッシュすると失われます。ただし、常に、作成したビューを保存できます。

3.3.2 カスタム・データ・エクスプローラを使用したビューの作成

デフォルトでは、ほとんどのユーザーにとって最も役立つと思われるオブジェクトおよび関係がコンソールに表示されます。デフォルト・ビューに必要なオブジェクトまたは関係が含まれていない場合は、カスタム・データ・エクスプローラを使用して、システムで認識されている任意のオブジェクトおよびその他の関連オブジェクトとの関係を表示します。この情報を使用して、独自のカスタム・ビューを作成できます。

カスタム・データ・エクスプローラを使用するには、ナビゲータで「エクスプローラ」→「カスタム・データ・エクスプローラ」を選択します。

カスタム・データ・エクスプローラでは、すでに説明したメイン領域が使用されます。メイン領域の最上部に、新しいコントロールが含まれています。2つのドロップダウン・リストで、オブジェクトおよびツリー・ビューに含める1つ以上の関連オブジェクトを選択できます。

- 指定可能な1次オブジェクトのリストは非常に長いため、スクロール・バーを使用して対象となるオブジェクトを見つけます。ビューの例では、1次オブジェクトとして「トランザクション」が選択されています。

- オブジェクト・リストの右側の指定可能なオブジェクトのリストには、選択したオブジェクトを関連付けることができるすべてのオブジェクトが含まれます。たとえば、「トランザクション」オブジェクトは、次に関連付けることができます。
「次のみ」を選択すると、関連オブジェクトは表示されません。関連オブジェクトを選択すると、ツリー・ビューの1次オブジェクトの下にそのオブジェクトが表示されます。

両方のリストから項目を選択すると、メイン・ビューに、最上位に1次オブジェクトが表示され、その下に従属オブジェクトが1つ以上表示されたツリー・ビューが表示されます。ビューの例では、1次オブジェクトとして「トランザクション」が選択され、関連オブジェクトとして「論理的な操作を経由して物理的な操作へ」が選択されています。

列チューザ・ツールを使用して、1次オブジェクトと関連オブジェクトの属性およびインスツルメントを表示できます。

終了後、ビューを保存して永続ビューにすることができます。このプロセスは、次の項で説明します。

3.3.3 ビューの保存

既存のビューを変更して作成したビューを保存するには、次の手順を実行します。

1. ビューがフォーカスされている状態で、メイン・メニューの「表示」→「現在のビューに名前を付けて保存」を選択します。

2. このビューを新規ビューにする場合は、名前を指定します。この名前は、ナビゲータの「マイ・ビュー」カテゴリでビューを参照する場合に使用されます。

3. このビューで同じ名前のビューを置き換える場合は、「すでに存在する場合にビューを置き換える」チェック・ボックスをクリックします。

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

保存したビューは、ナビゲータの「マイ・ビュー」カテゴリに表示されます。ビューをデフォルト・ビューとして設定するには、「表示」メニューの「現在のビューをデフォルトに設定」を選択します。

3.4 管理コンソール参照

この項では、多くのビューに共通のコントロールおよびツールの使用に関する参照情報を示します。次のコントロールおよびツールについて説明します。

- 「分析」タブの使用方法

- 管理状態サマリー・ダッシュボード

- フィルタ・ツールの使用方法

- フィルタリングのカスタム属性の追加

- キーボード・ショートカット

3.4.1 「分析」タブの使用方法

「分析」タブには、選択したオブジェクト(トランザクション、サービス、エンドポイント、操作またはコンシューマ)の現在のパフォーマンスと使用情報が詳しく表示されます。一部の情報は特定のタイプのオブジェクトにのみ関連するため、「分析」タブのレイアウトはオブジェクトによって異なります。

「分析」タブは、一度に1つずつ表示する複数のペインで構成されます。各ペインには異なるタイプの情報が表示されます。一連の使用可能なペインは、選択するオブジェクトによって異なります(つまり、すべてのペインがすべてのタイプのオブジェクトで使用可能というわけではありません)。ペインについては、この項で説明します。

3.4.1.1 「パフォーマンス」ペイン

トランザクションを選択すると、このペインに開始済トランザクションと完了済トランザクション、条件アラート、平均レスポンス時間、最大レスポンス時間のインスツルメントが表示されます。これらのインスツルメントは、「カウント」チャート、「カウント」表、「レスポンス時間」チャートおよび「レスポンス時間」表に表示されます。

サービス、エンドポイント、操作またはコンシューマを選択すると、このペインにトラフィック、スループット、フォルト、フォルトの割合、平均レスポンス時間および最大レスポンス時間のインスツルメントが表示されます。これらのインスツルメントは、「メッセージ」チャート、「メッセージ」表、「レスポンス時間」チャートおよび「レスポンス時間」表に表示されます。

「カウント」チャートの青色の線は、開始されたトランザクションの数を示しています。緑色の線は完了したトランザクションの数を、赤色の線は関連時間セグメントの間に発生した条件アラートの数を示しています。次に例を示します。

「カウント」表には、これらの測定が数値で表示されます。

「メッセージ」チャートの棒の高さの合計は、関連時間セグメントの間に監視されたトラフィックを示しています。棒の緑色の部分はスループットを示しており、赤色の部分はフォルト・カウントを示しています。次に例を示します。

「メッセージ」表には、これらの測定と追加のフォルトの割合の測定が数値で表示されます。表のハイパーリンクになっている値をクリックすると、メッセージ・ログ検索ツールが開き、測定値に関連付けられているメッセージを返す事前定義問合せが実行されます。たとえば、トラフィック値に関するメッセージを確認する場合は、値をクリックします。

「レスポンス時間」チャートの緑色の線は関連時間セグメントの平均レスポンス時間を示しており、オレンジ色の線は最大レスポンス時間を示しています。次に例を示します。

「レスポンス時間」表には、これらの測定が数値で表示されます。

3.4.1.2 トランザクション・パフォーマンス

選択されたコンシューマに関連付けられているトランザクション・パフォーマンス測定が表示されます。チャートと表の詳細は、「パフォーマンス」ペインの説明を参照してください。

3.4.1.3 サービスのパフォーマンス

選択されたコンシューマに関連付けられているサービスのパフォーマンス測定が表示されます。チャートと表の詳細は、「パフォーマンス」ペインの説明を参照してください。

3.4.1.4 コンシューマ使用状況

選択したオブジェクトの、コンシューマごとにセグメント化されたスループット、フォルト、フォルトの割合、平均レスポンス時間および最大レスポンス時間の測定が表示されます。表には選択したオブジェクトのすべてのコンシューマと各コンシューマのオブジェクトの使用に関連する集計パフォーマンス測定がリストされます。

3.4.1.5 トランザクション使用状況

選択されたコンシューマに関連付けられている開始済トランザクション、完了済トランザクション、平均レスポンス時間および最大レスポンス時間の測定が表示されます。これらの測定はトランザクションごとにセグメント化されています。

3.4.1.6 サービス/エンドポイント使用状況

選択されているコンシューマに関連付けられているスループット、フォルトおよびフォルトの割合が表示されます。これらの測定はサービスおよびエンドポイントごとにセグメント化されています。

3.4.1.7 条件アラート

指定期間にトリガーされた条件アラートに関する情報(満たされた条件の名前、条件アラートがトリガーされたエンドポイント、トリガーされた条件アラートの数)がリストされます。

3.4.1.8 クライアント・アドレス別内訳

選択したオブジェクトの、クライアント・アドレスごとにセグメント化されたスループット、フォルトおよびフォルトの割合が表示されます。クライアント・アドレスは、リクエストの送信元であるマシン・ホスト名です。表には、選択したオブジェクトにリクエストを送信したすべてのクライアント・アドレスと各クライアント・アドレスのオブジェクトの使用に関連する集計パフォーマンス測定がリストされます。

3.4.1.9 コールアウト

選択したオブジェクトがアウトバウンド・コールを行った各操作(エンドポイントによって修飾)がリストされます。「操作」列で、アウトバウンド・コールを行った操作が特定されます。集計リンク・スループット、リンク・フォルトおよびリンクの平均レスポンス時間が、アウトバウンド・コールのタイプごとに表示されます。

3.4.1.10 カスタム・チャート

選択したインスツルメントで、「パフォーマンス」ペインのようなカスタマイズされたチャートや表を設定できます。

「インスツルメントの選択」をクリックして、チャートや表に表示するインスツルメントを選択します。複数のインスツルメントを選択できます。トランザクションのカスタム・チャートまたは表を設定すると、任意の選択トランザクション、コンシューマおよびサービス、エンドポイントまたは操作に使用できます。

3.4.1.11 カスタム内訳

セグメント化された数値のインスツルメントのカスタム表を様々な方法で設定できます。

「インスツルメントの選択」をクリックして、表に表示するインスツルメントを選択します。複数のインスツルメントを選択できます。「セグメントの選択」をクリックして、測定をセグメント化する方法を選択します。複数のセグメントを選択できます。

たとえば、コンシューマ別の開始済トランザクションと完了済トランザクションの数を表示する表を設定できます。この場合、インスツルメントは開始済トランザクションと完了済トランザクションであり、セグメントはコンシューマ名です。

3.4.2 状態サマリー・ダッシュボード

「管理状態サマリー」ダッシュボードを使用すると、Business Transaction Managementのシステム・コンポーネントの状態を迅速に評価できます。「操作状態サマリー」ダッシュボードでは、同じ情報およびビジネス・コンポーネントの状態に関する情報が提供されます。

状態サマリー・ダッシュボードを表示するには

- 「ダッシュボード」>「管理状態サマリー」を選択します。

- 「ダッシュボード」>「操作状態サマリー」を選択します。

これらのダッシュボードは、複数の表で構成されています。各表では、トランザクション、サービス、SLAアラートなど、特定のタイプのオブジェクトに関するサマリー情報が提供されます。各表の行は、通常、可能性があるオブジェクトのステータスおよびそのステータスであるオブジェクトのインスタンスの数を示す数値を示します。たとえば、次の例では、5つのサービスが失敗の状態であり、5つのサービスが警告の状態です。

左端の時計アイコンは、数値が、ダッシュボード最上部で選択されている「時間間隔」に関連していることを示しています。値の横の拡大鏡をクリックすると、その状態の個別のオブジェクトのリストが表示されます。

3.4.3 フィルタ・ツールの使用方法

フィルタ・ツールを使用すると、顕著な特性に基づいてオブジェクトをフィルタできます。フィルタ・ツールは、ナビゲータで選択された項目によって異なります。ターゲット・オブジェクトが変わってもフィルタ・ツールの基本的な構造は変わりませんが、フィルタを使用してサービス、コンテナ、ポリシー、コンシューマなどのいずれのビューを変更するのかに応じて、選択できる基準が異なります。

「フィルタ」リンクの横のドロップリストに表示される事前定義済のフィルタ以外に、リンクをクリックしてフィルタ・ツールを開き、より豊富なフィルタ基準の選択肢を取得することもできます。

注意: 条件アラート、オブザーバまたはスケジュールはフィルタできません。

フィルタ・ツールを開くには、任意のビューで表示されている「フィルタ」リンクをクリックします。

Business Transaction Managementに次のようなダイアログが表示されます。

最初、ツールは短い形式で表示され、ここで、対象となるオブジェクトに最もよく使用される基準を参照するフィルタを定義でます。フィルタを作成するオブジェクトのドメインがテキスト・ボックスに表示されます。たとえば、上の図では、テキスト・ボックスで、すべてのユーザー・サービスに対するフィルタを作成していることが通知されます。追加の基準を表示するには、「詳細を表示」ボタンをクリックします。

短い形式またはより長い形式(詳細を表示)から問合せの基準を選択すると、Business Transaction Managementでは選択がデータベースの検索に使用されるAQL式に変換されます。ツールの最上部のテキスト・ボックスにAQL問合せ文を表示するには、「AQLの表示」チェック・ボックスをクリックします。

この機能を使用して、-filterQueryフラグを使用するCLIコマンドに渡すことができるAQL式を定義できます。フィルタ・ツールのコントロールを使用して基準を定義し、AQL式をCLIコマンドにコピー・アンド・ペーストするだけです。問合せにスペースが含まれている場合は、問合せを引用符で囲みます。

対象となる基準を選択した後に、「OK」ボタンをクリックし、このフィルタを使用して、現在のビューを変更します。ビューの保存手順は、3.3.3項「ビューの保存」を参照してください。

3.4.4 フィルタリングのカスタム属性の追加

スフィア内のオブジェクト(サービス、エンドポイント、コンテナなど)のカスタム属性を追加できます。これにより、フィルタ・ツールを使用して特定の属性値を持つオブジェクトを検索できます。たとえば、サービスに優先度レベルを割り当て、優先度に基づいてサービスをフィルタできます。

デフォルトの属性ラベルとは異なり、ユーザー定義の属性ラベルは自動的に変換されません。

オブジェクトをフィルタリングするためのカスタム属性の追加および使用の基本的なプロセスは、次のとおりです。

1. 対象となるオブジェクト・タイプのカスタム属性を追加します。

2. 個別のオブジェクトのプロファイルを編集して、カスタム属性に値を割り当てます。

3. フィルタ・ツールを使用して、カスタム属性の値が必要な値であるオブジェクトのみを選択します。

3.4.4.1 属性の追加

カスタム属性を追加するには、次の手順を実行します。

1. 「管理」→「データ・モデル属性の編集」にナビゲートします。「データ・モデル属性の編集」ツールが表示されます。

2. 「設定」領域で、カスタム属性を追加するオブジェクトを見つけます。

3. 「属性の追加」リンクをクリックします。

4. 次の情報を入力します。名前とタイプのみが必要です。
名前: 属性の名前を指定します。

タイプ: 属性のタイプを選択します。

フォーム・ラベル: 「プロファイル」タブおよびフィルタ・ツールで属性の識別に使用される名前です。属性の名前と異なるラベルにする場合にのみ値を指定する必要があります。

問合せラベル: フィルタ・ツールの「問合せ」テキスト・ボックスで属性の識別に使用される名前です。属性の名前と異なるラベルにする場合にのみ値を指定する必要があります。

値: 「値の追加」リンクをクリックして、属性の推奨値を指定します。この値は、その後、選択したオブジェクトの「プロファイル」タブに表示されます。(オプション)

説明: 属性の用途や目的を確認するための説明を追加します(オプション)

5. 「適用」をクリックします。

3.4.4.2 属性値の割当て

カスタム属性に値を割り当てるには、次の手順を実行します。

1. カスタム属性を追加したオブジェクトの「プロファイル」タブを開きます。追加した属性が「プロファイル」タブの「属性」領域に表示されています。

2. 「変更」メニューの「プロファイルの編集: <Object>」を選択します。

3. 隣接するテキスト・ボックスでカスタム属性の値を指定します。

4. 「適用」をクリックします。入力した値が「プロファイル」タブに表示されます。

3.4.4.3 カスタム属性に基づくフィルタ

カスタム属性に基づいてオブジェクトをフィルタリングするには、次の手順を実行します。

1. 「フィルタ」ドロップリストから「フィルタの選択...」を選択します。

2. 対象となるオブジェクトの属性リンクを展開します。たとえば、「サービス属性」や「コンテナ属性」を展開します。

3. 作成したオブジェクトのカスタム属性は、そのオブジェクトに定義されているデフォルト属性とともにリストされます。リストされていない場合は、ブラウザをリフレッシュします。

4. カスタム属性のドロップダウン・リストを使用して、検索基準を指定します。

5. 「OK」をクリックします。指定した基準に一致するすべてのオブジェクトがメイン領域にリストされます。

3.4.5 キーボード・ショートカット

キーボード・ショートカットを使用して、Business Transaction Managementコンソールをナビゲートできます。ショートカットは、Microsoft Internet Explorer 8でサポートされています。

Internet Explorerでのショートカットの使用に関する一般情報は、次のサイトのWebページの表示と検索に関する情報を参照してください。

http://windows.microsoft.com/en-US/windows-vista
/Internet-Explorer-8-keyboard-shortcuts

この項では、管理コンソールの様々な領域でのキーボード・ショートカットの使用方法について詳しく説明します。

3.1.1項「一般的なコンソールの設計」に記載されているように、管理コンソールは、メニュー・バー、ナビゲータ、メイン領域およびタブ領域の4つのセクションに分割されています。また、コンソールの使用中に別のツールにアクセスし、使用することもできます。これらの領域は異なる基本テクノロジを使用して作成されているため、キーボード・ショートカットは必ずしも一貫していません。次の各項で説明されている各領域の相違点と制限を確認してください。

一般的な[Tab]の順序

[Tab]キーはコンソールをナビゲートする基本的な手段です。([Tab]を押して進み、[Shift]を押しながら[Tab]を押して戻ります。)一般的な[Tab]の順序は、最上部のエクスプローラ・コントロール、コンソール・メニュー、ログアウトとリフレッシュのコントロール、コンソールのナビゲータ項目、メイン領域のコントロール(フィルタおよび列チューザ)、メイン領域の項目、タブ領域です。

メニュー

次のガイドラインに従って、管理コンソールのメニューを使用します。

- [Tab]を使用して、メニュー間を移動します(戻るには、[Shift]を押しながら[Tab]を押します)。

- [Enter]を押して、メニューを開きます。

- メニューが開いた後に、[↑]または[↓]キーを使用して、メニュー項目を前後に移動します。

- [→]キーを使用して、階層化されたメニューをナビゲートします。

- [Enter]を押して、現在選択しているメニュー項目を実行します。

ナビゲータ

次のガイドラインに従って、ナビゲータの項目を使用します。

- [Tab]キーを使用して、ナビゲータにアクセスします。

- ナビゲータで[Tab]を使用して前に進み、[Shift]を押しながら[Tab]を押して戻ります。項目は強調表示されません。

- [↑]または[↓]を使用して、カテゴリ間を直接ナビゲートします。

- [→]または[←]キーを使用して、カテゴリおよびビューを順にナビゲートします。

- ナビゲータ・カテゴリを展開または縮小するには、[Tab]を押してカテゴリに移動し、[Enter]を押します。

- ナビゲータ項目を選択するには、[Tab]を押して項目に移動し、[Enter]を押します。

メイン領域

メイン領域にアクセスするには、ナビゲータの最後の項目にフォーカスを移動し、[Tab]キーを押します。これにより、フォーカスがメイン領域の「フィルタ」コントロールに移動します。

メイン領域のグリッド・ビューの項目にアクセスするには、[Tab]を押して、メイン領域のコントロールの中で(「フィルタ」、列チューザ...その後、グリッド・ビューの一番上の線が強調表示されるまで)フォーカスを移動させます。グリッド・ビューの一番上の線にフォーカスが移動した後に、[Ctrl]を押しながら[↓]を押して、グリッド・ビューにリストされている最初の項目にフォーカスを移動します。

- メイン領域のグリッド・ビューの項目間を移動するには、[↑]または[↓]キーを使用します。

- 項目を展開するには、項目にフォーカスを移動し、[Shift]、[Ctrl]を押しながら[→]を押します。その後、[↑]または[↓]を使用して、グリッド項目間を順次移動します。

- 項目のタブ領域を開くには、項目にフォーカスを合わせ、[Enter]を押します。

タブ領域

タブ領域を使用するには、領域を表示し、タブ間をナビゲートして、特定のタブのコンテンツにナビゲートできる必要があります。

タブ領域を表示するには、次のいずれか1つを実行します。

- 詳細情報を表示する項目にフォーカスを合わせ、[Enter]を押します。

- [Tab]を押して「表示」メニューに移動し、「詳細ペインの表示/非表示」を選択します。その後、[Tab]を押してメイン領域に表示されている項目間を移動し、各項目の詳細情報を表示します。

タブのコンテンツにアクセスするには

1. メイン領域で、[↓]キーを使用してグリッド・ビューの最後の項目にフォーカスを移動します。最後の項目に到達した後に、[Tab]キーを使用して、タブ領域の必要なタブにナビゲートします。

2. [Enter]を押して、現在フォーカスされているタブを開きます。

3. タブのコンテンツにナビゲートするには、[Tab]キーを使用してすべてのタブから現在のタブの右側にフォーカスを移動します。最後のタブの後に、フォーカスは開いているタブのコンテンツに移動します。

4. フォーカスがタブのコンテンツに移動した後に、[Tab]キーを使用してタブの要素間を移動します。コントロールをアクティブ化するか、項目を選択するには、[Space]バーを押すか、または[Return]を押します。

注意:
[Tab]を使用してタブの最後の項目を超えて移動すると、フォーカスが失われる可能性があります。念のため、タブ項目を移動してメイン領域に戻ります([Shift]を押しながら[Tab]を押します)。

ツールおよびコントロール

ツールには、メニューからアクセスするか、メイン領域またはタブ領域に表示されているコントロールを使用してアクセスします。ツール内で次のことを実行します。

- [Tab]キーを使用して、ツール内の項目間を移動します。

- [Esc]を押して、いつでもツールを取り消すことができます。

- [Enter]を押すと、ツールの「OK」または「適用」ボタンがアクティブ化されます。必要に応じて[Space]バーを押すと、ツール内でアクションが実行されます。たとえば、[Space]バーを押して、チェック・ボックスを切り替えたり、リンクまたはボタンで指定されているアクションを実行します。

- ドロップリストから項目を選択するには、[↑]または[↓]を使用します。

- ツールにタブ領域が含まれている場合は、[→]または[←]を使用して、タブ間を移動します。

注意:
[Tab]を使用してツールの最後の項目を超えて移動すると、フォーカスが失われる可能性があります。念のため、タブ項目を移動してフォーカスを現在のタブに戻します([Shift]を押しながら[Tab]を押します)。

4 サービスおよび依存性の検出

この章では、Business Transaction Managementを使用して、コンテナ、サービスおよび依存性を検出する方法について説明します。この情報を使用すると、分散アプリケーションの動作、パフォーマンスに問題があるコンポーネント、およびより詳細な監視を必要とするコンポーネントを正確に把握できます。内容は、次のとおりです。

- 検出について

- 検出されたコンテナの表示

- 検出されたサービスの表示

- 依存性の表示

- 手動によるサービスの登録

- 検出されたオブジェクトの削除および再開始

Business Transaction Managementでの検出と監視が可能なサービスおよびコンポーネントのタイプの完全かつ最新のリストは、Business Transaction Management動作保証マトリックスを参照してください。このドキュメントは、http://support.oracle.comで「BTM動作保証」を検索すると参照できます。

4.1 検出について

検出は、コンポジット・アプリケーションを構成するビジネス・コンポーネントを識別し、ビジネス・コンポーネントと他のビジネス・コンポーネントとの関係(依存性)を理解できるようにするプロセスです。この項では、検出プロセスで必要な情報を正確に取得するために理解しておく必要がある概念およびプロセスについて説明します。次の内容について説明します。

- 多様なコンポーネント・タイプをBusiness Transaction Managementでモデル化する方法

- 検出プロセスの手順

- 大量の中間エンドポイントを含むテクノロジに対して検出を制限する方法

- 自動的に検出できないサービスを手動で登録する方法

- JDBCコールをモデル化する方法

検出の問題を解決する方法については、12.7項「検出問題の解決」を参照してください。

4.1.1 検出できる内容

Business Transaction Managementでは、次の要素を検出できます。

- アプリケーション・コンポーネント: これには、デプロイされたコンポーネント・タイプを指定する論理サービス、エンドポイント(そのサービスのインスタンス)およびエンドポイントで呼び出すことができる各操作が含まれます。

- コンテナ。

- コンポーネント間の依存性。

Business Transaction Managementでは、多様なコンポーネント・タイプおよびそれらが存在するコンテナを検出できます。コンポーネント・タイプに関係なく、同じモデルを使用して、相互接続されたコンポーネントが示されます。モデルは、リクエストおよびレスポンスのXMLメッセージを送信することによって相互作用するサービスで構成されます。また、モデルでは、各サービスが、サービスの場所およびそのインタフェースを指定するWSDLで記述されていることを想定しています。コンポーネントがWebサービスではないためにこのようなWSDLが存在しない場合、Business Transaction Managementは、コンポーネントを一貫して処理できるように疑似的なWSDLを作成します。次の図に、モデルを示します。

たとえば、JDBCを介してデータベースにアクセスするEJBを呼び出すWebサービスで構成されるコンポジット・アプリケーションがある場合、それは、XMLメッセージを使用して通信する3つのサービスとしてモデル化されます。Business Transaction Managementコンソールを使用して検出されたコンポーネントを表示すると、これらはサービスとしてリストされ、やり取りされるメッセージはこれらのサービスに属する操作としてリストされます。あるメッセージは、1つの操作のリクエスト・フェーズまたはレスポンス・フェーズのいずれかに相当します。

場合によっては、JAX-WSサービスやJAX-RPCサービスなど、監視されたトラフィック・タイプがこのモデルと完全に適合していることがあります。その他の場合には、Business Transaction Managementで、基本モデルと互換性のある方法を使用してコンポーネント・タイプをマップする必要があります。Webサービス以外のコンポーネントを検出および監視する場合は、このマッピングの詳細が重要になることがあります。

Business Transaction Managementでは、1つのコンポーネントから別のコンポーネントに流れるメッセージ・トラフィックを監視することで、コンポーネントを検出します。また、Business Transaction Managementでは、このトラフィックの監視から派生したデータに基づいて、これらのコンポーネントの相互関係を検出し、その依存性マップを描画できます。依存性情報によって、コンポジット・アプリケーションの実際の動作が正確に示されます。これにより、特定のコンポーネントがまったくコールされていないという事実を警告されることがあり、また、ビジネス・トランザクションを定義するための基礎が提供されます。

4.1.2 検出プロセス

検出について理解するうえで最も重要な事実は、検出が完全にトラフィックベースであるということです。監視されているエンドポイントをメッセージが流れていない場合、Business Transaction Managementではアプリケーション・コンポーネントを検出できず、これらのコンポーネント間の依存性を検出することもできません。不確かな場合は、トラフィックを送信します。この項では、監視対象の環境で分散アプリケーション・コンポーネントを検出する手順について概要を示します。詳細は、次の各手順からリンクされている項を参照してください。

検出を実行する前に、監視対象の環境にオブザーバをインストールし、オブザーバ通信ポリシーを構成して、オブザーバ間の通信と、オブザーバで検出されたデータをさらに処理するためのモニターまたはモニター・グループを定義する必要があります。

検出は2つのステージで実行されます。始動ステージでは、監視されるトラフィックによってオブザーバがモニターとの通信を開始し、監視ステージでは、オブザーバからモニターに流れるデータに測定ポリシーが適用されます。これはつまり、作業システムの全体図を作成するのに少し時間がかかる可能性があるということです。このことを表す1つの兆候として、100個のメッセージを送信したのにBusiness Transaction Managementでは98個しか監視されていないと報告された場合、不明となっているメッセージは、検出プロセスを始動する役割を果たしたメッセージということになります。

検出では次の手順を実行します。

1. システムにトラフィックを送信します。

2. 監視されているコンテナを確認します。ロード・バランサが使用されている場合、これらも表示可能にしておく必要があります。(Business Transaction Managementをインストールした後でコンテナを再起動するのみでは表示可能にならず、表示されるようにするにはトラフィックを送信する必要があります。)

3. サービスを表示し、監視対象のすべてのサービスが検出されていることを確認します。

4. サービスの「サマリー」または「分析」タブを参照して、測定が行われていることを確認します。メッセージ・トラフィックに関係するすべてのサービスについて、スループット、トラフィック、最大レスポンス時間および平均レスポンス時間を参照できます。測定値が不正確であるか、または見つからない場合は、Business Transaction Managementでトラフィック測定値を計算するのに十分な時間が経過していないか、監視が無効になっていた可能性があります。

5. 「サービス・マップ」で依存性を参照し、トラフィックがどのようにシステムを流れているかを確認します。

6. 必要に応じて調整します。一般に、検出された図が予想したものと一致しない場合に最初に行うことは、さらに多くのトラフィックを実行して、Business Transaction Managementがシステムのすべての部分を確認するのに十分な時間を確保することです。それでも問題が解決されない場合は、次の1つ以上を実行する必要があります。

- 検出しようとしているオブジェクトに適したプローブを有効にします。

- 手動でサービスを登録します。4.5項「手動によるサービスの登録」を参照してください。

- バージョニング・ポリシーまたはレプリケーションの問題が原因の検出問題を解決します。

4.1.3 検出の制限

テクノロジによっては、クライアントから直接サービスに流れるメッセージもありますが、その他のメッセージは実際の宛先に到達する前に中間エンドポイントのホストを通過します。このような中間エンドポイントは、メッセージ・システム、ジョブ・スケジュール・システム、分散システムなどの実装で構成されている場合があります。中間エンドポイントを使用するテクノロジのプローブをインストールしている場合、Business Transaction Managementを使用すると、このようなシステムのすべてのエンドポイントを監視するか、またはエッジにあるエンドポイントのみを監視するかを指定できます。多くの場合、これらは目的のビジネス・サービスを直接示すエンドポイントです。デフォルトでは、中間エンドポイントの監視はオフになります。これによって、監視のパフォーマンスが向上し、分散アプリケーションの監視に不要なデータが排除されます。

図4-1に、クライアントからサービス(EP5)にメッセージを伝達するエンドポイントを監視している多数のオブザーバを示します。メッセージ・フローのエッジにあるエンドポイントEP1およびエンドポイントEP4に注目してください。また、コンテキスト情報のリレーを示す点線にも注目してください。すべてのエンドポイントの監視を選択した場合、図に示すすべてのエンドポイントがBusiness Transaction Managementによって検出および監視されます。

図4-1 中間エンドポイントのモデル化

図4-2に、監視されるエンドポイントの数を制限した場合のメッセージ・フローのモデル化を示します。この場合、クライアント、EPおよびEP5のみが検出および監視されます。コンテキスト情報は、そのまま変わらずクライアントから最終受信者であるEP5に伝達されます。

図4-2 エンドポイント検出の制限

オブザーバ通信ポリシーによって、SOA、OSBおよびEJBプローブ用の中間エンドポイントの監視を制御するオプションが提供されます。各種テクノロジを監視するオプションは、それぞれ微妙に異なります。たとえば、EJBの監視では、フローのエッジのモデル化(ローカル・リクエスト・フロー内の最初のローカルEJBのみをモデル化)、すべてのモデル化(すべてのローカルEJBをモデル化)、および何もモデル化しない(ローカルEJBなし)のオプションを使用できます。ローカルEJBをモデル化する方法はEJBのモデル化および監視には影響せず、これらは常に監視されます。オブザーバ通信ポリシーの詳細は、12.1.2項「オブザーバおよびモニターの構成」、特に中間エンドポイントの監視を制御するオプションについて説明している12.1.2.11項「詳細設定フィールドのリファレンス」を参照してください。

4.1.4 JDBCコールのモデル化

JDBCプローブが有効でインスタンス・ロギングがオンになっている場合、大量のトランザクションまたはボリュームの大きいJDBCによってBTMリソースが制約されることがあります。また、1つの操作をコールすることで、データベースに対する大量のコールが発生する可能性もあります。たとえば、1つのFusion Application操作が何百ものSQL文に変換される可能性があります。このオーバーヘッドを削減し、リソースを解放するために、Business Transaction Managementでこれらのコールを個々に書き留めるのではなく、サマリーを記録するように選択できます。

JDBCサマリー・モードを使用するが、個々のコールも調査する場合は、データベース管理ツールを使用してこれを行うことができます。JDBCサマリー・オプションの背景にある主な考え方は、BTMパフォーマンスをより効率的にすると同時に、遅い、または問題のあるSQL文の情報を取得できるようにすることです。

オブザーバの通信ポリシーの設定で、JDBCサマリー・モードを有効にするかどうかが決定されます。この項では、JDBCサマリーを有効にした場合にBTMによって表示される情報について説明します。通信ポリシーの詳細は、12.1.2.11項「詳細設定フィールドのリファレンス」を参照してください。

JDBCサマリーを有効にすると、JDBCコールは次の図のように示されます。

図4-3 サマリー・モードでのJDBCコール

JDBCコールに指定された測定で、コールの平均時間およびコールの数が指定されます。図の場合、22個のコールが作成され、平均時間は20msです。サマリー・モードでは、操作名は常にexecuteになります。(JDBCサマリーが無効の場合、executePrepStmt、executePrepStmtBatch、executeQueryおよびexecuteBatch文はすべて個別に検出されます。)

4.1.4.1 JDBCサマリー・データの表示の理解

JDBCサマリーが有効な場合、トランザクション・インスタンスおよびメッセージ・ログの表示に、サービス・コールごとのサマリー・カウントおよびフォルト・カウントを示す2つの列が追加されます。(オブザーバ通信ポリシーでタイムアウト値を指定できます。SQLコール時間がこの値を上回る場合、BTMは追加のタイムアウト・サマリー・メッセージを送信します。)

次の図に、JDBCサマリーが有効な場合に示される追加情報を示します。execute文に対するレスポンス時間の報告のされ方に注意してください(表示の一部分のみが示されています)。サマリー情報を含む行にはすべてシグマ記号のマークが付けられます。

図4-4 インスタンス・インスペクタ: JDBCサマリーの新しい列

JDBCサマリー・モードをサポートするために、メッセージのリクエスト・フェーズに、aggregateCountおよびaggregateFaultCountの2つの追加の組込みプロパティが定義されています。これらのプロパティは検索で使用できます。たとえば、平均フォルト・カウントが100よりも多いexecuteメッセージを検索できます。

JDBCサマリーが有効な場合、BTMはすべてのJDBC操作を個別に記録しますが、メッセージ・コンテンツをロギングしている場合、コール元ごとに1つの要約されたサマリー監視で情報が送信され、オブザーバ通信ポリシー設定で指定した最も遅いSQL文とフォルトの数のペイロード情報のみがここに含まれます。(サマリー・コンテンツのロギングを制御するオプション設定については、12.1.2.11項「詳細設定フィールドのリファレンス」を参照してください。)

サマリー監視のメッセージ・コンテンツを表示すると、xmlリスト(ExecuteSummaryContent)は次のように表示されます。このテキストでは出力のメイン・セクションが太字で示され、その説明が例の後に続いています。

<ExecuteSummaryContent>
<ExecuteCount>52</ExecuteCount>
<FaultCount>2</FaultCount>
<SumResponseTime>77</SumResponseTime>
<AvgResponseTime>1.54</AvgResponseTime>
<SummaryStartTime>1376876999364</SummaryStartTime>
<SummaryEndTime>1376877000390</SummaryEndTime>
<Caller>
<Service>LogService</Service>
<Operation>haveFaults</Operation>
</Caller>
<CapturedFaults>
<Fault>
<ArriveTime>1376877000364</ArriveTime>
<Content> <![CDATA[select * from noneexisttable]]> </Content>
<FaultContent> <![CDATA[ORA-00942: table or view does not exit]]> </FaultContent>
</Fault>
<Fault>
<ArriveTime>1376877000386</ArriveTime>
<Content> <![CDATA[select * from noneexisttable]]> </Content>
<FaultContent> <![CDATA[ORA-00942: table or view does not exist]]> </FaultContent>
</Fault>
</CapturedFaults>
<TopNSlowestMessages>
<TopNMessage>
<Content> <![CDATA[INSERT INTO calculationlog
(leftoperator,rightoperator,operatortype, result,logdate)
VALUES(?,?,?,?,systimestamp)]]> </Content>
<ResponseTime>4</ResponseTime>
<ArriveTime>1376876999360</ArriveTime>
<ExecuteCount>10</ExecuteCount>
<AverageTime>2.30</AverageTime>
<MinTime>2</MinTime>
</TopNMessage>
<TopNMessage>
<Content> <![CDATA[DELETE FROM calculationlog where id=?]]> </Content>
<ResponseTime>4</ResponseTime>
<ArriveTime>1376877000150</ArriveTime>
<ExecuteCount>10</ExecuteCount>
<AverageTime>1.60</AverageTime>
<MinTime>1</MinTime>
</TopNMessage>
<TopNMessage>
<Content> <![CDATA[UPDATE calculationlog SET leftOperator = ?,
rightOperator = ?, operatorType = ?, result = ?,
logDate = systimestamp where id = ?]]> </Content>
<ResponseTime>3</ResponseTime>
<ArriveTime>1376876999552</ArriveTime>
<ExecuteCount>10</ExecuteCount>
<AverageTime>1.80</AverageTime>
<MinTime>1</MinTime>
</TopNMessage>
</TopNSlowestMessages>
</ExecuteSummaryContent>

ExecuteSummaryContentというタイトルのセクションには、サマリー監視に関する次の情報が示されています。

- ExecuteCount: 実行されたJDBCコールの合計数(例外を含む)。

- FaultCount: このサマリーで発生したすべてのJDBC例外の数。

- SumResponseTime: すべてのSQL文のレスポンス時間の合計。

- AvgResponseTime: 合計されたJDBCコールのレスポンス時間の平均。

- SummaryStartTime: 次の「注意」を参照してください。

- SummaryEndTime: 次の「注意」を参照してください。

- サービス・コールおよび操作。

通信ポリシーでは、取得する例外の数も指定できます。このような例外またはフォルトごとに、次の情報がCapturedFaultsというタイトルのセクションに示されます。

- ArriveTime: 例外が到着した時間。次の「注意」を参照してください。

- Content: 例外が発生したSQL文。

- FaultContent: SQL例外のコンテンツの全テキスト。

また、セクションTopNSlowestMessagesには、最も遅いN個のSQL文のそれぞれについて次の情報が示されます。(Nの値は通信ポリシーを使用して指定します。)

- Content: SQL文の名前(ただし、これらに渡されるパラメータではない)。

- ResponseTime: このSQL文の実行時間(マイクロ秒)。

- ArriveTime: 開始時間。次の「注意」を参照してください。

- ExecuteCount: このSQL文がコールされた回数。

- AverageTime: 記録されたすべてのSQL文の平均時間。

- MinTime: 記録されたすべてのSQL文の最小時間。

注意:
ArriveTime、SummaryStartTimeおよびSummaryEndTimeの時間は、UNIXタイムスタンプを使用して指定されます(1/1/1970からの秒数に基づく)。この値を判別可能な日時に変換するには、インターネットで「UNIX時間変換」を検索して変換ツールを探してください。

4.1.4.2 サマリー・オプション変更後のトランザクション定義の更新

すでにトランザクションを作成した後でJDBCサマリーの設定を変更する場合、さらに多くのトラフィックを実行してからトランザクション定義を更新する必要があります。これは、BTMがJDBCサマリーの設定に応じて、別の名前の下にあるSQL実行のJDBCサービス操作を検出するためです。

- JDBCサマリーが無効の場合、executePrepStmt、executePrepStmtBatch、executeQueryおよびexecuteBatch文はすべて個別に検出されます。

- JDBCサマリーが有効な場合、executePrepStmt、executePrepStmtBatch、executeQueryおよびexecuteBatch文はすべて単一のexecute操作に結合されます。

トランザクション定義の作成後にJDBCサマリーの設定を変更する場合は、次の手順を実行します。

1. 再度JDBCサービスでトラフィックを実行して、新しい操作を検出します。

2. 古い操作を削除し、新しく検出された操作を含めることで、JDBCサービスを使用するトランザクションを編集します。

トランザクション定義を更新しない場合、BTMでは新しく検出されたJDBCサービスの操作をトランザクションの一部として認識できず、そのサービスへのトラフィックの測定値を記録できなくなります。

4.1.5 サービスの手動登録

Business Transaction ManagementでSOAタイプのコンポーネントを直接検出できない場合があります。たとえば、監視できないコンテナの中にサービスが存在する場合や、オブザーバがインストールされていないコンテナの中にサービスが存在する場合などです。このような場合、サービスを手動で登録すると、オブジェクトを検索できることがあります。

このような方法でサービスを検出することは可能ですが、通常は、サービスが直接監視されていない状態でそのパフォーマンスを監視することはできません。詳細は、4.5項「手動によるサービスの登録」を参照してください。

4.2 検出されたコンテナの表示

検出によって、Business Transaction Managementシステム・サービスをホストしているコンテナ、および監視されているコンポーネントをホストしているコンテナに関する情報が表示されます。この項では、コンテナに関する使用可能な情報について説明します。また、コンテナのプロファイル情報を編集する方法とコンテナの登録を解除する方法についても説明します。

4.2.1 コンテナ情報の表示

コンテナ情報は、「エクスプローラ」→「コンテナ」ビューから、または「マップ」→「コンテナ・マップ」ビューから表示できます。

コンテナ・マップを表示するには:

1. ナビゲータで、「マップ」→「コンテナ・マップ」を選択します。

2. フロートオーバー型のヘルプに、各コンテナのホスト名が示されます。カーソルをコンテナに合わせてヘルプを表示します。

3. タブ領域を開いてコンテナ・アイコンをクリックすると、コンテナの「プロファイル」および「サービス」タブが表示されます。タブの内容については、次の項を参照してください。

4.2.2 サマリーおよび詳細情報の表示

検出されたコンテナとその内容に関するサマリー情報を表示するには:

1. ナビゲータで、「エクスプローラ」→「コンテナ」ビューを選択します。検出されたコンテナに関する情報がメイン領域に表示されます。デフォルトでは、Business Transaction Managementは認識されたすべてのコンテナに関する情報を表示します。「フィルタ」コントロールを使用して、表示されるコンテナ情報をフィルタ処理します。

2. コンテナ名のそばにあるプラス・アイコンをクリックして、コンテナの内容を表示します。これで、選択したコンテナでホストされているアプリケーション・コンポーネントを表示できます。

3. コンポーネント名のそばにあるプラス・アイコンをクリックして、そのコンポーネントを構成している操作を表示します。操作は、ツリー・ビューのコンテナの下に表示されます。

検出されたコンテナに関する詳細情報を表示するには:

1. メイン領域でコンテナを選択します。

2. コンテナ名をダブルクリックします。詳細ペインに、「プロファイル」および「サービス」の2つのタブが表示されます。

3. 「プロファイル」タブには、コンテナおよびデプロイされたオブザーバに関する情報が表示されます。次の表に、「プロファイル」タブのフィールドを示します。ユーザー定義フィールドは、プロファイル情報を編集することで入力できます。

4. 「サービス」タブには、このコンテナで実行しているサービスの情報が表示されます。

フィールド

説明

注意

ユーザー定義フィールド。コンテナの使用または内容の理解に役立つ情報を示します。

ベース・アドレス

このコンテナのhttpベースのアドレス(エントリ・ポイント)。

別名

コンテナがスフィアに認識される際のすべてのIPアドレス。ここには、コンテナへのメッセージ・トラフィックを監視することによってBusiness Transaction Managementで検出されたVPNアダプタ・アドレス、ユーザー定義の別名またはその他のアドレスが含まれる場合があります。この情報は、不適切なコンテナ設定を調査する場合に役立ちます。

コンテナ・タイプ

コンテナ・タイプおよびバージョン番号。

OS

オペレーティング・システムおよびバージョン。

ホスト

サーバーが実行しているホスト名。

識別子

Business Transaction Managementでのこのオブジェクトの一意の識別子。

管理UIコンソール

ユーザー定義フィールド: コンテナの管理コンソールのURL。このリンクを使用してコンソールを起動できます。このアドレスの値はBusiness Transaction Managementによって提供されますが、正確でない可能性があり、コンソールを移動する場合には必ず変更する必要があります。この値は、コンテナ・プロファイルを編集することで変更できます。

モニターの詳細

指定されたコンテナにデプロイされたオブザーバの情報と、最終の検出、登録、スフィアとの同期およびバージョンの日付。

連絡先情報

サーバー管理者またはその他のサポート担当者の連絡先情報を提供するユーザー定義フィールド。

ルーティングの詳細

コンテナにメッセージをルーティングしている、監視対象のロード・バランサの情報。

4.2.3 コンテナのプロファイル情報の編集

コンテナのプロファイル情報を編集するには

1. コンテナのマップ領域またはメイン領域でコンテナを選択します。

2. 「変更」→「プロファイルの編集: <container>」項目を選択します。

3. 編集可能な任意のフィールドを変更します(黄色で示されます)。

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

4.2.4 コンテナの登録解除

コンテナの登録を解除すると、コンテナおよびコンテナにデプロイされているすべての検出済サービスがスフィア・レジストリから削除されます。これは、次のいずれかのタスクが完了した後で必要になる場合があります。

- 別のスフィアへのコンテナの移動

- コンテナからのBusiness Transaction Managementオブザーバのアンインストール

- システムからのコンテナのアンインストールまたは物理的削除

次のいずれかのタスクを完了した後でのみコンテナの登録を解除する必要があります。そうしないと、何も変更されていない場合には、登録解除されたコンテナによって起動時にそれ自体が登録されます。

1. 「マップ」→「コンテナ・マップ」ビューまたは「エクスプローラ」→「コンテナ」ビューでコンテナを選択します。

2. 「変更」メニューから「ContainerName登録の削除」を選択します。

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

4.3 検出されたサービスの表示

Business Transaction Managementによって、検出されたサービス、サービス・エンドポイント、エンドポイントにメッセージ・トラフィックを配布するルーター、およびサービス操作に関する情報が表示されます。

- サービスとは、論理サービスを示します。

- エンドポイントとは、サービス・インスタンスおよびルーターを示します。

- 操作は、1つのサービスが別のサービスに送信するリクエストおよびレスポンス・メッセージによって呼び出されます。

Business Transaction Managementを開始した時点では、サービスは表示されません。サービスが検出されるには、次のことが必要です。

- オブザーバがインストールされ、適切なプローブがアクティブになっているアプリケーション・サーバーに、サービスがデプロイされている必要があります。

- 1つのサービスから別のサービスにトラフィックが流れている必要があります(手動でサービスを登録していない場合)。

サービスが検出されると、「サービスからエンドポイントへ」および「サービスから操作へ」ナビゲータ・ビューから、それらの情報にアクセスできます。サービスの依存性は、「マップ」→「サービス・マップ」ビューで表示できます。

4.3.1 サービス・タイプ

Business Transaction Managementは、サービスで最初に検出されたエンドポイントのタイプに基づいて、サービスにタイプを割り当てます。サービス・タイプには、Webアプリケーション、Webサービスおよびデータベースがあります。(Webアプリケーションは、HTMLページ(画面)を介してユーザーとやり取りするコンポーネントです)。サービスにはそれぞれ異なるタイプの複数のエンドポイントがあり、それぞれ異なるオブザーバによって検出される場合があることに注意してください。たとえば、Webサービスでは、それぞれ異なるテクノロジ(JAX-RPC、JAX-WS、WCFなど)を使用して実装された別個のコンテナに、複数のエンドポイントが存在する場合があります。

4.3.2 デプロイメント・トポロジおよびサービス情報

表示されるサービス情報は、デプロイメントのトポロジによって異なります。実行しているサービスのインスタンスが1つしかない場合、そのサービスの1つのエンドポイントが表示されます。実行しているサービスのインスタンスが複数ある場合は、そのサービスの複数のエンドポイントが表示されます。

複数のサービス・インスタンスが検出される可能性があり、これらを監視する必要がありますが、その理由は様々です。

- パフォーマンスまたはフェイルオーバーのためにサービスがレプリケートされている。この場合、レプリケートされたすべてのインスタンスがサービスのエンドポイントとして表示されます。これらのインスタンスにトラフィックを配布しているルーターも表示されます。ルーター名は、エンドポイント名に接尾辞としてRouterを付けた名前になります。

- セキュアな(HTTPS)ポートとセキュアではない(HTTP)ポートの両方でサービスがコンテナにデプロイされている。トラフィックがポートに流れている場合にのみ、そのポートごとに1つのエンドポイントが表示されます。

- 1つのサービスに対する様々なバインディングがWSDLに含まれ、各バインディングによって、様々なエンドポイントで実装可能な様々な操作セットが定義されている。これはまれなケースですが、Business Transaction Managementではこの状態を認識し、エンドポイントを検出します。

4.3.3 ルーターの存在を推察する方法

ルーターがトラフィックのリダイレクトに使用されているかどうかを判断するのに時間がかかる場合があります。Business Transaction ManagementはHTTPトラフィックのホスト・ヘッダーを使用して、監視されているコンテナとは異なるアドレスにメッセージが最初に送信されたときに、そのことを検出し、依存性グラフの受信者にコール元を接続します。

ホスト・ヘッダーに含まれているホスト名は異なるが、ポートは同じである場合、Business Transaction Managementは最初にコンテナとそのエンドポイントの別名を追加します。実際にリスニングしているコンテナとは異なるポートがホスト・ヘッダーに含まれている場合、または2つ以上のコンテナに送信されたトラフィックで同じホスト・ヘッダーが監視されている場合、Business Transaction Managementはコール元とサービスの間にハードウェア・ロード・バランサが存在することを推察し、必要に応じてスフィア・モデルにルーター・エンドポイントを追加して、依存性グラフでコール元とそのターゲット・エンドポイントを接続します。

4.3.4 サービスの表示

ナビゲータから、「サービスからエンドポイントへ」ビューまたは「サービスから操作へ」ビューのいずれかを使用して、サービスを表示できます。

「サービスからエンドポイントへ」を表示するには、ナビゲータからそのビューを選択します。Business Transaction Managementによって、コンソールのメイン領域に情報が表示されます。次の表に、このビューの内容を示します。

「サービスからエンドポイントへ」ビューは、エンドポイントのレプリケートが表示されるという点で役立ちます。レプリケートはアドレスで識別され、メイン領域に表示されます。また、このビューのタブ・セクションに示されるように、個別の定義情報およびパフォーマンス情報も表示されます。

列名

説明

名前

サービスの名前。最上位の論理サービス名を展開して、そこに含まれるエンドポイントを表示します。エンドポイントを展開して、その操作を表示します。

上矢印/下矢印

緑色の矢印は、サービス、エンドポイントまたは操作が実行中であることを示します。赤色の矢印はダウンしていることを示します。黄色は、エンドポイントがサービスに含まれていることを示しますが、実行中のものもあればダウンしているものもあります。

アドレス

サービスのコンテナのアドレス。レプリケートのエンドポイントはそれぞれ異なるアドレスを持ちます。

タイプ

サービスのタイプ。これは、検出された最初のサービス・エンドポイントのタイプに基づきます。

コンテナ・タイプ

サービス・コンテナのタイプおよびバージョン。

各サービス、エンドポイントまたは操作の詳細を表示するには、目的の要素をクリックしてタブ領域に詳細情報を表示します。これには、次のデータが含まれます。

タブ

説明

サマリー

メイン・ペインで選択したオブジェクトのパフォーマンス測定のサマリーを表示します。

分析

特定の期間にわたるパフォーマンス情報を表示します。

アラート

選択したオブジェクトのアラートを表示します。

メッセージ・ログ

指定した操作に対してメッセージ・ロギングが有効になっている場合に、使用可能なメッセージを表示します。

SLA準拠

選択したオブジェクトの準拠と、指定したオブジェクトに定義されているサービス・レベル合意を表示します。

プロファイル

選択したオブジェクトの定義を表示します。「変更」→「プロファイルの編集: object name」を選択することで、この情報の一部を編集できます。

依存性

選択したオブジェクトと関連オブジェクトとの間の依存性を表示します。

ポリシー

現在選択されているオブジェクトに適用されているポリシーを表示します。

停止時間

選択したオブジェクトにスケジュールされている停止時間を示します。

プロパティ

選択したオブジェクトに定義されているプロパティを示します。「編集」ボタンを使用して、これらのプロパティを変更、複製または削除します。

「サービスから操作へ」を表示するには、ナビゲータから選択します。Business Transaction Management。表示される情報のタイプは、「サービスからエンドポイントへ」ビューと同じです。タブの情報も同じです。

4.4 依存性の表示

ビジネス・コンポーネントの検出に加えて、Business Transaction Managementでは、1つのコンポーネントから次のコンポーネントに流れるメッセージ・トラフィックを監視することで、コンポーネントが互いにどのように関係または依存しているかを検出できます。依存性情報によって、コンポジット・アプリケーションの実際の動作が正確に示されます。これにより、特定のコンポーネントがコールされていないという事実を警告されることがあり、また、ビジネス・トランザクションを定義するための基礎が提供されます。

サービス、エンドポイント、(サービス・インスタンス)または操作間の依存性を表示できます。各依存性マップによって、選択した要素に適切な情報が提供されます。

また、依存性グラフに最新でない依存性が表示されている場合には、依存性を削除することもできます。

4.4.1 関連要素の表示

表示されている依存性のタイプに関係なく、依存性ダイアグラムでは選択したオブジェクトをルートとして、その開始点から、およびその開始点につながるすべてのリンクが表示されます。ルート・オブジェクトの直接のアップストリームまたはダウンストリームに存在しない要素は表示されません。これらの追加要素を表示するには、レンチ・アイコンをクリックして「レイアウト」および「関連の表示」コントロールを表示します。

「関連の表示」のデフォルト値は「なし」で、これはルート・オブジェクトに直接リンクされている要素のみが表示されることを意味します。

1. 「1」を選択して、ルート・オブジェクトに間接的にリンクされているその次のレベルのオブジェクトを表示するか、または「すべて」を選択して、ルート・オブジェクトにリンクされているすべてのオブジェクトを表示します。

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

4.4.2 サービスの依存性

サービスの依存性を表示するには

1. ナビゲータで、「サービスからエンドポイントへ」ビューまたは「サービスから操作へ」ビューを選択します。

2. タブ領域がまだ開いていない場合には、目的のサービスをダブルクリックしてタブ領域を開きます。開いている場合は、単に目的のサービスを選択します。

3. 「依存性」タブを選択します。Business Transaction Managementによって、選択したサービスとそのサービスがやり取りしている他のサービスとの間の依存性が表示されます。矢印はトラフィック・フローを示します。その厚みで相対的なスループット・サイズが示されます。

4. 表示されているサービスにカーソルを合わせると、Business Transaction Managementでそのコンポーネント・タイプを表示できます。

また、ナビゲータから「マップ」→「サービス・マップ」ビューを選択しても、サービスの依存性を表示できます。

4.4.3 エンドポイントの依存性

エンドポイントの依存性を表示するには:

1. ナビゲータで、「サービスからエンドポイントへ」ビューを選択します。

2. 目的のサービスを展開して、対応するエンドポイントを表示します。サービスがレプリケートされた場合や、異なるエンドポイントがセキュアな通信またはセキュアではない通信に使用される場合、(論理)サービスに複数の対応するエンドポイントが存在する場合があります。

3. 目的のエンドポイントをダブルクリックしてタブ領域を開きます。すでに開いている場合は、単に目的のエンドポイントを選択します。

4. 「依存性」タブを選択します。Business Transaction Managementによって、選択したエンドポイントとそのエンドポイントがやり取りしている他のエンドポイントとの間の依存性が表示されます。矢印は、トラフィック・フローの方向と相対的なスループットを示します。エンドポイントごとに、そのエンドポイントが存在するコンテナのホスト名とポートも表示されます。エンドポイントの検出に使用された方法がカッコの中に表示されます。次の表に可能なタイプを示します。

検出の方法

意味

オブザーバ

エンドポイントはオブザーバによって検出されました。

ルーター

エンドポイントはルーターによって検出されました。(HTTPホスト・ヘッダーと、監視されたコンテナの物理アドレスの間の矛盾に基づいて、ハードウェア・ルーターの存在が推察されました。)

登録済

エンドポイントは手動で登録されました。

DTA

監視されているエンドポイントから送信されたアウトバウンド・トラフィックに基づいて、エンドポイントの存在が推察されました。

個々のエンドポイントにカーソルを合わせると、ビジネス・トランザクションによってエンドポイント名、コンテナのホストとポート、およびそのエンドポイントがどのサービスおよびコンポーネント・タイプのインスタンスであるかが表示されます。また、コア測定も表示されます。

4.4.4 操作の依存性

操作間の依存性を表示するには:

1. ナビゲータで、「サービスから操作へ」ビューを選択します。論理的または物理的な操作間の依存性を表示できます。論理的な操作はサービスの直下に表示され、物理的な操作は論理的な操作の下に表示されます。物理的な操作の名前は次の形式になります。
endpointName on containerName

例: checkCredit.CreditServiceSOAP on uitest20:7011

2. 目的の操作をダブルクリックしてタブ領域を開きます。すでに開いている場合は、目的の操作を選択します。

3. まだ選択されていない場合は、「依存性」タブをクリックします。

4. 操作を含むコール・チェーンが表示されます。

5. カーソルを操作に合わせて、フロートオーバー型の追加ヘルプを表示します。

4.4.5 依存性の削除

アプリケーションが変更され、依存性グラフがこれらの変更を反映していない場合には、すべての依存性の削除が必要になることがあります。依存性データが古くなって使用できなくなることはないため、グラフに不要なデータが含まれる場合は、すべての依存性を消去し、さらに多くのトラフィックを実行することでグラフを再生成できます。

依存性を削除するには:

1. 「管理」メニューから「依存性の削除」を選択します。

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

3. 依存性を再生成するには、さらに多くのトラフィックを実行します。

4.5 手動によるサービスの登録

通常、サービスが直接監視下にない場合は、検出または監視することができません。ただし、サービスを手動で登録し、表示して、そのサービスに送信されるコールの測定を取得できます。

サービスへの送信コールはあるがサービスのコンテナにオブザーバをインストールできない場合は、サービスを登録する必要があります。サービスを登録すると、メッセージ交換のクライアント側で監視される測定およびログ・メッセージをシステムで記録できるようになります。

サービスを登録した後、registerExternalContainerコマンドを使用すると、そのエンドポイントを外部コンテナにグループ化できます。それ以外の場合、手動で登録したエンドポイントはデフォルトでシステム・コンテナに割り当てられ、「未割当てのエンドポイント」ノードに表示されます。

サービスを登録するには:

1. メイン・メニューから、「管理」→「登録」→「サービスWSDL」を選択します。

2. サービスのWSDLのURLを指定し、「次」をクリックします。

3. サービスをスフィアに登録する際の名前を指定します。デフォルトでは、名前はWSDL定義から抽出されますが、必要に応じて代替名を使用できます。

4. オプションで、サービスのバージョンを指定します。

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

これで、「サービスからエンドポイントへ」または「サービスから操作へ」ビューのサマリー領域に、サービスが表示されるようになります。

4.6 検出されたオブジェクトの削除および再開始

有用な検出構成を作成しようとすると、特にBusiness Transaction Managementを使用する早い段階では何度か繰り返し作業することになる場合があります。プローブを有効にするためのデフォルト設定にあまりにも多くの情報が含まれる場合や、デプロイメントまたはオブザーバ・モニター・トポロジの変更によって情報が冗長になったり誤ったものになる場合があります。システムを再インストールしたり、すべての監視対象エンティティおよび関連するアーティファクトを手動で削除する必要がないようにするために、Business Transaction ManagementにはdeleteAllコマンドが用意されています。このコマンドは、すでに検出されたオブジェクトをトランザクション、プロパティ、登録済サービス、デバイス、コンテナなど関連するアーティファクトとともに削除します。

監視したオブジェクトに関する履歴データなどのデータの不要な損失を防ぐために、このコマンドは慎重に使用してください。このコマンドが最も適しているのは、Business Transaction Managementでの作業を開始し、検出方式を微調整するときです。本番環境では使用しないでください。

詳細は、10.11項「deleteAll」を参照してください。

5 トランザクションの使用

トランザクションは、1つの単位として監視する一連の操作です。この章では、トランザクションを使用する利点、トランザクションを定義および監視する方法、JVM診断およびインスタンス診断リクエストにアクセスする方法、トランザクションのトラブルシューティング方法について説明します。内容は、次のとおりです。

- トランザクションについて

- プロパティについて

- プロパティの使用

- トランザクションの定義、変更および削除

- トランザクション・パフォーマンスの表示および監視

- 「上位10件のトランザクション」ダッシュボード

- トランザクション・インスタンスの表示

- ログ・メッセージおよびプロパティの表示

- その他の診断ツールへのアクセス

- トランザクションに関する情報の取得

- トランザクションのトラブルシューティング

5.1 トランザクションについて

トランザクションに参加する操作を指定することによって、トランザクションを論理レベルで定義します。Business Transaction Managementでは、個別のエンドポイントを調べることによってトランザクションが監視され、必要なレベルの情報が表示されます。提供される詳細レベルの範囲は、最小の集約パフォーマンス情報から、最大のメッセージ・コンテンツ・ロギングまでです。Business Transaction Managementを使用したトランザクションの監視は反復プロセスであり、最初は最大限のエンドポイントを調べて、サービス使用状況およびトラブルの可能性がある箇所の概要を把握します。これらを識別しながら、より狭い範囲の要素をより詳細に調べます。この方法を使用することで、システム・リソースを多く使用しないで、必要な情報を確実に取得できます。

次のことを実行するためにトランザクションを定義および監視できます。

- ビジネス・トランザクションのパフォーマンスを評価します。Business Transaction Managementでは、完了、失敗およびスタックしているトランザクションに関する情報が提供されます。また、トランザクションが完了するまでにかかる全体的な時間と、その時間のどれだけの部分がトランザクションの各処理で使用されるかも示されます。

- メッセージ・コンテンツに基づいてトランザクション・インスタンスを検索します。

- トランザクションの問題をトラブルシューティングします。ボトルネックを分析し、パフォーマンスの低下またはトランザクションの失敗の理由を診断します。

役割が異なるユーザーは、トランザクション・パフォーマンスに関するサマリー情報を次のように使用できます。

- 業務担当者は、サーバーまたはコンポーネントの停止時間の影響を受けるトランザクションを判別する必要があります。これは、作業に優先順位を付け、メンテナンスをスケジュールするのに役立ちます。

- 開発者は、コンポーネントに対する実装の変更の影響を受けるトランザクションを理解する必要があります。

- ビジネス・アプリケーション所有者は、トランザクションのパフォーマンスおよびスループットを示すグラフを監視する必要があります。

操作フローを識別する検出プロセスを使用して、トランザクションを定義します。検出で明らかになる依存性に基づいて、目的の相互作用を備えたサービスを含めるようにトランザクションを定義できます。次に、デフォルトのトランザクション定義を変更して、パフォーマンスおよび使用状況に関して必要な詳細レベルが提供される監視機能を有効にできます。機能には、ユーザーまたはホスト・アドレス別のセグメント情報、インスタンスとプロパティのロギングおよびメッセージ・コンテンツ・ロギングが含まれています。

この項では、トランザクション定義のこの反復プロセスおよび各機能を有効にしたときに使用可能になる詳細レベルについて説明します。内容は、次のとおりです。

- トランザクションを定義するもの

- プロパティ

- 自動相関および手動相関

- デフォルトのトランザクション定義

- その他の機能

- サービス・レベル合意および条件

5.1.1 トランザクションを定義するもの

トランザクションは次のものによって定義されます。

- プライマリ操作フロー。これは、フローをトリガーする開始メッセージを示すことによって指定されます。開始メッセージは、通常はフローの最初の操作のリクエスト・メッセージです。

- 追加操作フロー(必要な場合)。これは、プライマリ・フローと手動で相関させる必要があります。

- トランザクションの終了メッセージ。デフォルトでは、これはプライマリ操作フローの最初の操作からのレスポンス・メッセージです。ただし、より複雑なトランザクションをモデル化するために変更できます。

フローから1つ以上の操作を削除することによって、操作フローのトランザクションのビューを変更できます。

Business Transaction Managementでは、同じ操作を複数のトランザクションに含めることができますが、唯一の制限は同じ操作を複数のトランザクションの開始操作にすることはできないということです。操作を複数のトランザクションに含める場合、Business Transaction Managementでは各トランザクションの全体的なレスポンス時間の正確な測定の集計を保持でき、共有される操作がそれを所有する各トランザクションによってコールされるたびに、操作の呼出しを適切にカウントします。Business Transaction Managementではサービスがレプリケートされる状況も処理でき、フェイルオーバーまたはロード・バランシング・アーキテクチャでなんらかのレプリケートが使用されたときにパフォーマンス情報を正確に収集します。

あるトランザクションが特定の期間内に数多く実行されます。Business Transaction Managementでは、トランザクションに含まれるメッセージのフローを追跡し、これらを特定のトランザクション・インスタンスにマップできます。

- トランザクション・インスタンスは、プライマリ操作フローのインスタンスが開始すると開始します。

- トランザクション・インスタンスは、インスタンスの開始メッセージに相関する終了メッセージのインスタンスがシステムで認識されると終了します。

含まれている操作フロー以外に、トランザクションは次の情報を指定する設定によっても定義されます。

- トランザクションのスコープ: 1つのトランザクションがどれくらいの時間実行されることが予想されるか。Business Transaction Managementでは、この値を使用して特定のトランザクション・インスタンスのメッセージの検索をいつ停止するかを識別します。

- トランザクションの特定のインスタンスを表示できるように、アセンブルする可能性のあるログ・メッセージをどれくらいの時間保持するか。

- トランザクション監視を有効にするかどうか、およびフリー・テキスト検索を有効にするかどうか。

- セグメンテーション、インスタンス・ロギングおよびメッセージ・コンテンツ・ロギングを有効にするかどうか。

5.1.2 プロパティ

ユーザーがすべてのメッセージのコンテンツをログに記録しなくてもメッセージから情報を抽出できるように、Business Transaction Managementではトランザクション操作に関連付けられたプロパティを使用できます。プロパティは、メッセージ・ヘッダーまたはメッセージ・ペイロードの一部と関連付けることができます。次の方法で使用できます。

- トランザクション内の操作を相関させるために使用されるメッセージ・キーの値の指定

- メッセージのコンテンツをログに記録しないメッセージ要素の値の表面化

- 特定のトランザクション・インスタンスの検索

- 条件の定義

5.1.3 自動相関および手動相関

トランザクションの開始操作と終了操作を定義すると、デフォルトでは、Business Transaction Managementにより介在する操作がトラフィック・フローに基づいて決定され、トランザクション・インスタンスの操作を結合する(相関させる)メッセージ・フィンガープリントが作成されます。トランザクション・メッセージの相関にかわる方法として、手動キーを定義することもできます。

次の場合には操作を手動で相関させる必要があります。

- トランザクションへのセカンダリ操作フローの追加。これは、JMSなどの非同期システムの場合に必要になることがあり、基礎となるデータを共有するが因果関係としては接続されない2つの操作フローを接続する場合に望ましいことがあります。たとえば、受注の入力によって定義されるフローと、受注の終了によって定義される別のフローがあります。同じ受注が2つの別々のプロセスに関与します。

- 終了メッセージがフローを開始した操作の終了メッセージとは異なるトランザクションの定義。

- 欠落メッセージ条件の定義。

それぞれの場合に何を相関させる必要があるかの詳細は、「手動キーを使用したトランザクション内のメッセージの相関」を参照してください。

1つのトランザクション定義に、自動的に相関される操作と手動で相関される別の操作を含めることができます。

5.1.4 デフォルトのトランザクション定義

操作を選択し、トランザクションを作成することを選択すると、Business Transaction Managementによって、デフォルト値がすでに入力されたトランザクション定義の作成ツールが表示されます。このデフォルトの定義は、次のとおりです。

- トランザクションの開始メッセージは選択した操作のリクエスト・メッセージであり、終了メッセージはその操作のレスポンス・メッセージです。

- トランザクション監視は有効です。つまり、Business Transaction Managementによって、開始済トランザクションと完了済トランザクションの数、スループット、平均レスポンス時間、最大レスポンス時間およびフォルトの測定の計算および表示を可能にするデータが収集されます。

- トランザクション内のメッセージは、(Business Transaction Managementによって計算される)メッセージ・フィンガープリントを使用して相関されます。

- セグメンテーション、インスタンスとプロパティのロギングおよびメッセージ・コンテンツ・ロギングは無効です。

トランザクションの概要を最初に把握するには、デフォルト構成で十分です。速度の遅いリンク、障害のあるサービスおよび予期しないトラフィック急増を識別するのに役立ちます。また、全体的なトランザクション・パフォーマンスが低下しているか、または時間どおりに完了していないかも示されます。トランザクションに対して収集された測定に基づいて、固定値およびベースラインのサービス・レベル合意(SLA)を作成することもできます。

デフォルトのトランザクション定義は次の方法でカスタマイズできます。

- トランザクションに含まれている操作を変更し、終了操作を変更します。これは、トランザクションに一方向操作が含まれているため、全体的なリクエスト・フローよりも少ない操作数にトランザクションを制限するため、またはサービスの呼出しがまれであって検出期間内で見つからない場合にサービスを追加するために行う場合があります。

- メッセージ・キーを使用してメッセージを相関させます。

- トランザクションに関する詳細情報を表示する機能をオンにします。

次の各項では、トランザクション定義に追加できる機能について説明します。

5.1.5 その他の機能

次に示すのは、トランザクション・パフォーマンスとメッセージ・コンテンツのより詳細な状況を表示するために追加できる機能です。

5.1.5.1 セグメンテーション

トランザクションの測定値は、ホスト・アドレスに基づいて切り分けることも、個々のコンシューマごとに切り分けることもできます。コンシューマ・セグメンテーションは、特定の顧客との使用契約がある場合、またはサービスの使用が特に多いか少ない顧客を識別する場合に有用なことがあります。

ホスト・アドレスによるセグメンテーションは、ネットワークにおけるリクエストの分散を把握するのに役立ちます。一部のネットワーク・セグメントまたはホストでトランザクションの不均衡な負荷が発生しているかどうか、または問題のあるトランザクションがすべて特定のホストで実行されていることを検出できます。

5.1.5.2 インスタンスとプロパティのロギング

インスタンス・ロギングを有効にすると、指定した時間間隔に取得されたトランザクション・インスタンスのリストを表示できます。指定したインスタンスをアセンブルおよび検査し、そのインスタンスにプロパティ値がある場合はそれを表示し、これらのプロパティ値に基づいて各種条件を作成できます。

ログに記録されたプロパティに対して検索を行い、関連するトランザクション・インスタンスを見つけることもできます。

5.1.5.3 メッセージ・コンテンツ・ロギング

メッセージ・コンテンツ・ロギングを有効にすると、指定した操作のメッセージ・コンテンツを表示でき、そのリクエストまたはレスポンス・メッセージのコンテンツに基づいて操作を検索できます。

5.1.6 サービス・レベル合意および条件

トランザクションに対して有効にした機能によって、トランザクション全体および選択した操作の情報が記録されます。結果を分析してパフォーマンスの問題を検出する必要があるこの継続的な監視以外に、条件およびサービス・レベル合意を使用して、特別な状況についてアラートを出すようにBusiness Transaction Managementを構成することもできます。

- サービス・レベル合意は、測定の集計に基づいてトランザクションのパフォーマンス標準を定義します。その後、Business Transaction Managementはこれらの標準からの差異を監視し、差異が発生するとアラートが発行され、管理コンソールに表示されます。

- 指定したメッセージ・プロパティの値が発生したとき、または障害が発生したときに、予期されるメッセージが到着しない場合に、条件によりアラートを出すようにできます。これらは、特定のトランザクション・インスタンスにおける問題を検出できるようにするツールです。条件がトリガーされ、満たされると、Business Transaction Managementは該当するトランザクション・インスタンスをアセンブルし、これによってユーザーはその内容を表示し、トラブルシューティングまたはその他のパフォーマンス評価に必要な分析を実行できます。

5.2 プロパティについて

プロパティは、操作のリクエストまたはレスポンス・フェーズに関連付けられる値を保持する変数です。プロパティ値は、メッセージ要素、要素のフラグメント、同じメッセージの複数の要素を組み合せた値、またはメッセージ要素を使用する式に対応します。メッセージ・ヘッダーまたはボディのメッセージ要素を使用してプロパティ値を定義できます。

プロパティは一般的に、検索の簡素化、メッセージ・コンテンツのログを記録しないメッセージ要素の表面化、条件の定義などに使用されます。

この項では、プロパティを定義および使用できる様々な方法について説明します。また、任意の操作用にBTMによって定義されている標準プロパティについても説明します。

プロパティ定義は、プロパティが定義されたサービス操作が含まれているトランザクションの「プロパティ」タブに表示されます。プロパティ定義は、サービス操作、エンドポイント操作、サービスおよびエンドポイントの「プロパティ」タブにも表示されます。ただし、プロパティの変更または削除は、トランザクションの「プロパティ」タブからのみ可能です。

5.2.1 プロパティの使用方法

プロパティを使用すると、次のことを実行するのに役立ちます。

- ドリルダウンしないと表示できないようなメッセージの様々な側面を表面化します。プロパティを使用すると、メッセージ・コンテンツをログに記録しなくてもメッセージ要素の値を表示できるようになり、パフォーマンスを向上させることができます。

- トランザクションを構成する操作を手動で相関させることができるキーを定義します。

- コンシューマ別にトランザクションをセグメント化します。

- メッセージ・プロパティの値に応じた条件を定義します。

たとえば、顧客IDを含むサービス要素があるとします。操作を含むトランザクションで例外を経験した顧客を知りたい場合は、顧客ID要素の値を保持するプロパティを作成できます。そうすると、パフォーマンス結果を調べたときに、そのトランザクションで例外を経験した顧客のIDが明確に表示されます。

次の項で説明する標準プロパティは、Business Transaction Managementによって定義されており、ユーザー定義プロパティはその名前が示すとおり、5.2.3項「ユーザー定義プロパティ」で説明するようにユーザーによって定義されます。

5.2.2 標準プロパティ

次の表に示すプロパティは、BTMによって任意のメッセージ用に定義されています。標準プロパティは、メッセージのフェーズ(リクエスト、レスポンスおよびフォルト)ごとに定義されています。aggregateCount、aggregateFaultCountおよびECIDベースのプロパティを検索で使用できます。ECIDベースのプロパティは手動キーに対して使用できます。

表5-1 標準プロパティ

メッセージ・フェーズ

プロパティ名

説明

リクエスト

aggregateCount

このexecute文に関連付けられたコール数。詳細は、4.1.4.1項「JDBCサマリー・データの表示の理解」を参照してください。

aggregateFaultCount

指定したexecute文に関連付けられたフォルト数。詳細は、4.1.4.1項「JDBCサマリー・データの表示の理解」を参照してください。

arrivalTime

1970年1月1日00:00:00 UT以降に経過したミリ秒として測定された、リクエスト・メッセージの着信時刻。

count

リクエストされた操作が現在のトランザクション・インスタンスで呼び出された回数。操作が正常に実行されなかった場合でも、各リクエストによってカウントは増分されます。

exists

リクエスト・メッセージが現在のトランザクション・インスタンスの一部として着信した場合にtrueとなるブール式。

interactionId

内部でのみ使用されます。

requestECID

選択した操作のリクエスト・フェーズに関連付けられたECID。詳細は、5.9.2.1項「ECIDの基本」を参照してください。

sender

非推奨。使用しないでください。このプロパティは将来のリリースで削除されます。

リクエスト・メッセージの送信者を識別する文字列。これは通常、受信側サービスがデプロイされているアプリケーション・サーバーに送信側アプリケーションから提供される資格証明のユーザー名部分です。このプロパティは、アプリケーション・サーバーによってユーザーが認証された場合にのみ設定されます。

レスポンス

arrivalTime

1970年1月1日00:00:00 UT以降に経過したミリ秒として測定された、レスポンス・メッセージの着信時刻。

exists

レスポンス・メッセージが現在のトランザクション・インスタンスの一部として着信した場合にtrueとなるブール式。

interactionId

内部でのみ使用されます。

responseECID

選択した操作のレスポンス・フェーズに関連付けられたECID。詳細は、5.9.2.1項「ECIDの基本」を参照してください。

responseTime

ミリ秒として測定された、リクエスト・メッセージの着信とそれに対応するレスポンス・メッセージの着信との間の時間間隔。

sender

非推奨。使用しないでください。このプロパティは将来のリリースで削除されます。

フォルト

actor

フォルト・メッセージのfaultactor要素の値。メッセージのパス内で誰がフォルトを発生させたかに関する情報が提供されます。

arrivalTime

1970年1月1日00:00:00 UT以降に経過したミリ秒として測定された、フォルト・メッセージの着信。

code

フォルト・メッセージのfaultcode要素の値。フォルトを識別するためのアルゴリズム・メカニズムが提供されます。

detail

フォルト・メッセージのdetailcode要素の値。Body要素に関連するアプリケーション固有のエラー情報が提供されます。

exists

フォルト・メッセージが現在のトランザクション・インスタンスの一部として着信した場合にtrueとなるブール式。

responseTime

ミリ秒として測定された、リクエスト・メッセージの着信とそれに対応するフォルト・メッセージの着信との間の時間間隔。

sender

非推奨。使用しないでください。このプロパティは将来のリリースで削除されます。

string

フォルト・メッセージのfaultstring要素の値。人間が読めるフォルトの説明が提供され、アルゴリズム処理用ではありません。

5.2.3 ユーザー定義プロパティ

プロパティは、メッセージ・コンテンツまたはメッセージ・ヘッダー(SOAPヘッダー、HTTPヘッダー、JMSメッセージ・プロパティなど)を含むリクエストまたはレスポンス・メッセージに対して定義された任意のXPath式に基づくことができます。

最も単純なタイプのプロパティは、単一のメッセージ要素の値を保持します。たとえば、次のようなメッセージ要素があります。

OrcerServiceImpl.submit.request.order.orderId

この要素の値を値として持つOrder_IDという名前のプロパティを作成できます。

1つ以上のメッセージ要素を含む計算の結果を格納するプロパティを作成することもできます。たとえば、価格を保持する要素に定数を乗算して税を計算する場合があります。

OrderServiceImpl.submit.request.order.grandTotal *.0825

その結果をTax_Dueという名前のプロパティに格納できます。

必要なデータをメッセージから直接は抽出できない場合もあります。そのような場合は、XPath式に基づくプロパティを作成してメッセージからデータを抽出し、計算を実行できます。

たとえば、メッセージに数が不定の<item>要素が含まれている場合、プロパティを作成してメッセージ内の<item>要素の数をカウントし、その値を格納できます。

また、XPath式を使用して、エンコードされたXMLドキュメントを含むXML要素からデータを抽出する場合もあります。

最後に、WSDLがないサービスがある場合があります。Business Transaction Managementを使用すると、このサービスからのメッセージをログに記録し、XMLビューを使用して必要な要素を取得して目的のプロパティを定義できます。

次の各項では、プロパティの作成、変更、複製および削除の詳細について説明します。

5.3 プロパティの使用

プロパティは、操作(メッセージ)のリクエストまたはレスポンス・フェーズに関連付けられる値を保持する変数です。この項では、Business Transaction Managementを使用してプロパティを使用する方法について説明します。内容は、次のとおりです。

- プロパティの定義

- WSDLがないか不完全なサービスのプロパティ

- プロパティ定義の表示

- プロパティ値の表示

- プロパティの変更

- プロパティ定義の複製

- プロパティの削除

5.3.1 プロパティの定義

メッセージ・プロパティを定義するために使用するプロセスは、プロパティが単一のメッセージ要素、要素のフラグメント、要素の組合せ、要素を含む式のいずれに対応するかによって異なります。

任意のビューでサービス、操作またはエンドポイントを選択し、次に、「作成」メニューから「メッセージ・プロパティの作成: Name」を選択して、メッセージ・プロパティの作成ツールにアクセスできます。

作成するプロパティの種類に関係なく、(プロパティ値を入力するメッセージ要素を指定する以外に)次の情報を指定する必要があります。

- プロパティの「名前」。

- プロパティ値を定義するためにそのコンテンツを使用する「操作」(メッセージ)。

- プロパティの目的またはこのプロパティについて保持するその他のノートを説明するオプションの「説明」。

- プロパティの値が取得される「プロパティ・ソース」。

- 特定の属性を介してプロパティをコンシューマにマップする必要があるかどうか。プロパティを特定のコンシューマ属性に関連付ける場合は、「コンシューマ・マッピング」チェック・ボックスを選択します。デフォルトでは、システムで定義されているユーザー属性は「コンシューマ名」のみです。必要に応じて他のコンシューマ属性を定義できます。

- プロパティの値にアクセスできるのは、機密情報の表示がロールで許可されているBusiness Transaction Managementユーザーのみかどうか。アクセスを制限するには、「秘密として扱う」チェック・ボックスを選択します。

メッセージが収集された後で新しいプロパティを定義した場合、新しく定義されたプロパティはログ・メッセージには含まれません。

次の手順では、単一の要素、要素のフラグメントまたは複数のメッセージ要素に基づいてプロパティを作成する方法について説明します。

単一要素に基づくプロパティの定義

1. 任意のビューで、サービス、操作またはエンドポイントを選択します。

2. 「作成」メニューから「メッセージ・プロパティの作成: Name」を選択します。

3. プロパティの名前を指定します。名前を指定しない場合は、メッセージ要素名がプロパティ名に使用されます。

4. プロパティ・ソース: 当該の要素がメッセージ・コンテンツの一部かメッセージ・ヘッダーの一部かを指定します。
「ヘッダー」を選択した場合、ヘッダー名、フェーズ(リクエスト、レスポンス、フォルト)およびデータ型を指定するために使用する必要がある小さいダイアログがBusiness Transaction Managementによって表示されます。次に、手順8にスキップします。手順5から8は、「メッセージ・コンテンツ」を選択した場合に適用されます。

5. 「メッセージから選択」リンクをクリックして、メッセージ要素を表示します。

6. 「メッセージ」ドロップダウン・リストを使用して「リクエスト」または「レスポンス」を選択します。

7. メッセージ要素をダブルクリックして選択します。

8. このプロパティをコンシューマ属性にマップする場合は、「コンシューマ・マッピング」チェック・ボックスを選択します。

9. 複数ある場合は、属性を選択します。

10. プロパティ値へのアクセスを制限する場合は、「秘密度」チェック・ボックスを選択します。

11. 「OK」をクリックします。

算術式に基づくプロパティの定義

1. 任意のビューで、サービス、操作またはエンドポイントを選択します。

2. 「作成」メニューから「メッセージ・プロパティの作成: Name」を選択します。

3. プロパティの名前を指定します。名前を指定しない場合は、Business Transaction Managementによって要素名がプロパティ名に使用されます。

4. プロパティ・ソース: 「メッセージ・コンテンツ」を選択します。

5. 「メッセージから選択」リンクをクリックして、メッセージ要素を表示します。

6. 「メッセージ」ドロップダウン・リストを使用して「リクエスト」または「レスポンス」を選択します。

7. メッセージ要素をダブルクリックして選択します。

8. 「XPathに変換」項目をクリックします。要素のXPath定義が表示されます。

9. 「XPath」ボックスで、目的の式を作成します。たとえば、税を計算する税プロパティを定義する場合は、Price要素の元のXPath式を使用できます。

/soapenv:Envelope/soapenv:Body/*[local-name(.)='submit']/^*
[1]/^tns1:OrderItems/^tns1:Price

次に、10%の税を計算するように次のように定義します。

/soapenv:Envelope/soapenv:Body/*[local-name(.)='submit']/^*
[1]/^tns1:OrderItems/^tns1:Price * .10

10. このプロパティをコンシューマ属性にマップする場合は、「コンシューマ・マッピング」チェック・ボックスを選択します。

11. 複数ある場合は、属性を選択します。

12. プロパティ値へのアクセスを制限する場合は、「秘密度」チェック・ボックスを選択します。

13. 「OK」をクリックします。

要素の部分的なコンテンツに基づくプロパティの定義

これは、ネストされたxmlドキュメントがあり、ネストされた要素をプロパティの値に含める場合に役立つことがあります。

1. 任意のビューで、サービス、操作またはエンドポイントを選択します。

2. 「作成」メニューから「メッセージ・プロパティの作成: Name」を選択します。

3. プロパティの名前を指定します。名前を指定しない場合は、Business Transaction Managementによって要素名がプロパティ名に使用されます。

4. プロパティ・ソース: 「メッセージ・コンテンツ」を選択します。

5. 「メッセージから選択」リンクをクリックして、メッセージ要素を表示します。

6. 「メッセージ」ドロップダウン・リストを使用して「リクエスト」または「レスポンス」を選択します。

7. メッセージ要素をダブルクリックして選択します。

8. 「XPathに変換」項目をクリックします。要素のXPath定義が表示されます。

9. XPath式を編集して、ネストされた要素にプロパティ値を制限します。

10. このプロパティをコンシューマ属性にマップする場合は、「コンシューマ・マッピング」チェック・ボックスを選択します。

11. 複数ある場合は、属性を選択します。

12. プロパティ値へのアクセスを制限する場合は、「秘密度」チェック・ボックスを選択します。

13. 「OK」をクリックします。

同じメッセージの複数の要素を組み合せたコンテンツに基づくプロパティの定義

これは、手動キーを指定してメッセージを相関させる必要があるが、サービスに対して一意の単一メッセージ要素がない場合に役立つことがあります。2つのメッセージ要素(顧客IDと郵便番号など)を組み合せた一意の値のプロパティを作成できます。

次の手順では、2つの要素を組み合せることを想定します。このケースを拡張して要素を追加できます。

1. 任意のビューで、サービス、操作またはエンドポイントを選択します。

2. 「作成」メニューから「メッセージ・プロパティの作成: Name」を選択します。

3. プロパティ・ソース: 「メッセージ・コンテンツ」を選択します。

4. 「メッセージから選択」リンクをクリックして、メッセージ要素を表示します。

5. 「メッセージ」ドロップダウン・リストを使用して「リクエスト」または「レスポンス」を選択します。

6. メッセージ要素をダブルクリックして選択します。

7. 「XPathに変換」項目をクリックします。要素のXPath定義が表示されます。

8. XPath定義をコピーし、「取消」ボタンを押してメッセージ・プロパティの作成ツールを終了します。

9. 同じ操作を再度選択します。

10. 「作成」メニューから「メッセージ・プロパティ: Name」を選択します。

11. プロパティの名前を指定します。

12. プロパティ・ソース: 「メッセージ・コンテンツ」を選択します。

13. 「メッセージから選択」リンクをクリックして、メッセージ要素を表示します。

14. 「メッセージ」ドロップダウン・リストを使用して「リクエスト」または「レスポンス」を選択します(フェーズは、最初の要素のコピー元のメッセージと同じである必要があります)。

15. メッセージ要素をダブルクリックして選択します。

16. 「XPathに変換」項目をクリックします。要素のXPath定義が表示されます。

17. 最初の要素からコピーしたXPath定義を貼り付けます。要素タイプに応じて、適切な演算子を使用して有効なXPath式を構成します。

18. このプロパティをコンシューマ属性にマップする場合は、「コンシューマ・マッピング」チェック・ボックスを選択します。

19. 複数ある場合は、属性を選択します。

20. プロパティ値へのアクセスを制限する場合は、「秘密度」チェック・ボックスを選択します。

21. 「OK」をクリックします。

5.3.2 WSDLがないか不完全なサービスのプロパティ

Business Transaction Managementでは、コンポーネント・タイプが何であっても、相互接続されたコンポーネントを表すために同じモデルが使用されます。モデルでは、リクエストおよびレスポンスXMLメッセージを送信することによって対話するサービスが示されます。また、モデルでは、各サービスが、サービスの場所およびそのインタフェースを指定するWSDLで記述されていることを想定しています。ただし、検出されたすべてのコンポーネントがこのモデルによって正確に表されるわけではありません。コンポーネントが実際のWebサービスではない場合、対応するWSDLがないか不完全であることがあります。そのような場合は、追加アクションを実行して、このコンポーネントのメッセージ要素のプロパティを作成する必要があります。基本的には、当該の要素を含むメッセージをログに記録し、XMLをプロパティ定義にコピーします。

プロセスは次のとおりです。

1. プロパティを作成する対象の要素を含むトランザクション操作のメッセージ・ロギングを有効にします。

2. システムを介してトラフィックを実行し、トランザクション・インスタンスを少なくとも1つ取得します。

3. コンソールのメイン領域で当該のトランザクションを選択します。

4. 「メッセージ・ログ」タブを開き、メッセージをログに記録した操作を選択します。

5. 拡大鏡アイコンをクリックして「メッセージ・コンテンツ」インスペクタを開きます。

6. 当該の要素がどちらに含まれているかに応じて、リクエストまたはレスポンス・メッセージの「XMLの表示」を選択します。

7. メッセージのXMLをコピーします。

8. 任意のビューで、サービス、操作またはエンドポイントを選択します。(サービスには当該の操作が含まれている必要があります。)

9. 「作成」メニューから「メッセージ・プロパティの作成: Name」を選択します。

10. プロパティ・ソース: 「メッセージ・コンテンツ」を選択します。

11. 「メッセージから選択」リンクをクリックして、メッセージ要素を表示します。すでに入力されている要素ツリー(ある場合)は無視します。

12. 操作フェーズ「リクエスト」または「レスポンス」を選択します。

13. XMLの取得ボタンをクリックして、XMLドキュメントを貼付けウィンドウを開きます。

14. ウィンドウでテキストを貼り付け、「OK」をクリックします。

15. 要素ツリーにメッセージ要素が表示されます。

16. 当該の要素を選択します。

17. このプロパティをコンシューマ属性にマップする場合は、「コンシューマ・マッピング」チェック・ボックスを選択します。

18. 複数ある場合は、属性を選択します。

19. プロパティ値へのアクセスを制限する場合は、「秘密度」チェック・ボックスを選択します。

20. 「OK」をクリックします。

5.3.3 プロパティ定義の表示

操作、エンドポイント、サービスまたはトランザクションの「プロパティ」タブで、プロパティ定義の一部を表示できます。プロパティ名、フェーズ、タイプおよび説明が表示されます。プロパティの秘密度およびコンシューマにマップされた属性も表示されます。

すべての定義を表示するには、「編集」ボタンをクリックして「変更」を選択します。

5.3.4 プロパティ値の表示

次のビューでプロパティ値を表示できます。

- 選択したエンドポイント、操作、サービスまたはトランザクションの「メッセージ・ログ」タブ

- 選択したエンドポイント、操作、サービスまたはトランザクションの「アラート」タブ

- 「トランザクション」ビュー、「インスタンス」タブ

- 「トランザクション・インスタンス」インスペクタ

5.3.5 プロパティの変更

プロパティの定義を変更できます。既存のプロパティのXPath定義を変更した場合、ランタイムによって着信メッセージに基づく新しいXPath定義の計算が開始されます。以前に記録されたメッセージは、古いXPath定義に基づいて計算された値を保持し続けます。

プロパティの名前を変更するには、複製を作成して新しい名前を割り当ててから、元のプロパティを削除する必要があります。

プロパティはトランザクション定義、セグメンテーション、条件およびロギングで重要な役割を果たすため、プロパティ定義の変更によって次のような結果が生じる場合があります。

- プロパティがトランザクション定義でキーとして使用されている場合、トランザクションは無効になります。

- プロパティがトランザクション定義でキーとして使用されている場合、トランザクションは無効になります。

- プロパティが条件で使用されている場合、条件は無効になります。

ユーザーが作成したプロパティを変更するには

1. 当該の操作、エンドポイント、サービスまたはトランザクションの「プロパティ」タブを選択します。

2. 「編集」ボタンをクリックして「変更」を選択します。

3. プロパティ定義を変更します。プロパティの作成の詳細を参照してください。

4. 「OK」をクリックして新しい定義を保存します。

5.3.6 プロパティ定義の複製

プロパティ定義の複製を考慮する理由は2つあります。

- 同様の複雑な式が必要な別のプロパティまたはこのプロパティによって抽出されるコンテンツの一部を含む別のプロパティを作成するための開始点として、元のプロパティを使用する場合があります。この場合は、プロパティを複製して、その定義を部分的に変更します。

- プロパティ名を変更する必要があります。この場合は、プロパティを複製して目的の名前を割り当ててから、元のプロパティを削除できます。プロパティを削除すると重大な悪影響が生じる可能性があります。詳細は、5.11項「トランザクションのトラブルシューティング」を参照してください。

ユーザーが作成したプロパティを複製するには

1. 当該の操作、エンドポイント、サービスまたはトランザクションの「プロパティ」タブを選択します。

2. 「編集」ボタンをクリックして「複製」を選択します。

3. プロパティ定義を変更します。プロパティの作成の詳細を参照してください。

4. 必要に応じて複製の名前を変更します。

5. 「OK」をクリックして、変更したコピーを保存します。

5.3.7 プロパティの削除

プロパティはトランザクション定義、セグメンテーション、条件定義およびロギングで重要な役割を果たすため、プロパティの削除によって重大な結果が生じる場合があります。

- プロパティが相関キーとして使用されている場合、トランザクション定義にとって必須とみなされます。これらのプロパティのいずれかが削除されると、トランザクション全体が無効になり、システム・アラートが生成されます。

- トランザクション・コンシューマ・セグメンテーションに使用されるプロパティが削除されるか、コンシューマとしてマークされなくなるように変更されると、トランザクション・セグメンテーションは取得されなくなります。トランザクションがコンシューマによってセグメント化に対して有効としてマークされている場合、システム・アラートが生成され、コンシューマ・セグメンテーションは無効になります。

- 条件定義で使用されているプロパティが削除されると、条件は無効になり、システム・アラートが生成されます。

- トランザクション内の操作に対して定義され、ログに記録されている(ただし、他の目的では明示的には使用されていない)プロパティが削除されると、ユーザーは、ログ・メッセージのインスタンスを表示したときに、そのプロパティおよび関連付けられたコンテンツを表示できなくなります。

ユーザーが作成したプロパティを削除するには

1. 当該の操作、エンドポイント、サービスまたはトランザクションの「プロパティ」タブを選択します。

2. 「編集」ボタンをクリックして「削除」を選択します。

3. 「OK」をクリックして新しい定義を保存します。

5.4 トランザクションの定義、変更および削除

トランザクションは、1つの単位として監視および管理する一連のサービス操作です。この項では、Business Transaction Managementを使用したトランザクションの定義、トランザクション定義の変更およびトランザクションの削除の方法について説明します。

トランザクションに対してオンにする機能の数が多くなるほど、Business Transaction Managementのパフォーマンスへの影響も大きくなる点に注意してください(特にボリュームが大きい場合)。たとえば、メッセージ・ロギングは、トランザクション内のすべての操作に対して有効にするよりも、関連する狭い領域に制限するのが最適です。次のガイドラインは、トランザクション監視のオプションの相対的なパフォーマンス・コストを示しています。

- 低: 開始メッセージと終了メッセージが同じ場合のコア測定

- 中: セグメンテーション、条件評価

- 高: インスタンス・ロギングおよびメッセージ・ロギング

5.4.1 トランザクションの定義

トランザクションの定義では、次の情報を指定します。

- トランザクションに参加する操作と、トランザクションの開始および終了メッセージ。

- トランザクションをアクティブに監視する必要があるか、または一時的に休止する必要があるか。

- 情報をIPアドレスまたはコンシューマ別にセグメント化するか。

- トランザクション・インスタンスまたはメッセージ・コンテンツをログに記録するか。

- メッセージをどのように相関させるか(フィンガープリントの使用または定義した手動キーの使用)。

- トランザクション・メッセージをどれくらいの期間保持する必要があるか。

次の各項では、トランザクション定義の各側面を指定する方法について説明します。

5.4.1.1 操作の選択およびトランザクションの有効化

トランザクションに参加する操作を定義し、トランザクション監視を有効にすると、「トランザクション」ビューでのトランザクションおよび関連サービスの表示、固定値およびベースラインのサービス・レベル合意(SLA)の作成、「サマリー」タブでのリンク測定のサマリーの表示および適切なビューでのその他の測定の表示を行うことができます。測定については、開始済トランザクションと完了済トランザクションの数、スループット、平均レスポンス時間、最大レスポンス時間およびフォルトを表示できます。

1. トランザクションに含める操作を選択します。任意のビュー(サービス・グラフ、依存性ダイアグラム、データ・グリッドまたはメッセージ検索ツール)から操作を選択できます。

2. 「作成」メニューから「トランザクション」を選択します。Business Transaction Managementによって「トランザクション」ツールが表示され、トランザクションのすべての側面を定義できます。

3. 「定義」タブを選択します(まだ選択していない場合)。このタブに表示されている、定義に必要な基本的な要素(開始メッセージ、終了メッセージおよび最大トランザクション期間)に注意してください。「トランザクション監視の有効化」チェック・ボックスはデフォルトで選択されています。ボックスの選択を解除すると、監視を一時的にオフにしてトランザクション定義を保持できます。
上部ペインには、選択した操作に依存するすべての操作がツールによって表示されます。デフォルトでは、依存性チェーンの最も左にある操作のリクエスト・メッセージが開始操作に指定され、最も左にある操作のレスポンス・メッセージが終了メッセージに指定されます。ツールでは、指定された開始操作が結果の依存性チェーン内のすべてのサービス操作とともに表示されます。デフォルトでは、トランザクションでメッセージを相関させるためにメッセージ・フィンガープリントが使用されます。これらは、トランザクション・マップ内ではフィンガープリント・アイコンで表されます。必要に応じて、Business Transaction Managementで手動キーを使用してメッセージを相関させることもできます。

4. デフォルトでは、トランザクション名は開始操作に基づきます。別の名前を割り当てるには、「トランザクション名」テキスト・ボックスで指定します。

5. デフォルトで選択された開始メッセージおよび終了メッセージを変更する場合は、「開始メッセージ」または「終了メッセージ」ドロップダウン・リストをクリックして、別の開始メッセージおよび終了メッセージを選択します。
開始メッセージと終了メッセージが同じ操作のリクエスト/レスポンス・メッセージではない場合、Business Transaction Managementでパフォーマンスを測定するためには共通のコンテンツを持つキーを指定する必要があります。必要な情報を入力するよう要求されます。ECID値を共通キーとして指定できます。

6. トランザクションをさらにカスタマイズするには、グラフの右にあるボタンを使用して、操作の追加、既存の操作への接続、メッセージ・フローの方向の指定または操作の削除を行います。また、追加した操作をトランザクション内の既存の操作に接続するための手動キーを指定する必要もあります。

7. 新しいトランザクションは、デフォルトで有効になっています。つまり、Business Transaction Managementによってトランザクション・パフォーマンスの監視、測定の収集、トランザクションに条件が定義されている場合は条件の評価が行われています。
トランザクションを無効にするには、「トランザクション監視の有効化」チェック・ボックスをクリックします。これにより、測定収集(セグメント化および非セグメント化)、条件評価、インスタンス・ロギングおよびコンテンツ・ロギングがオフになります。ただし、トランザクションに適用されているSLAは明示的に無効にしないかぎり評価を継続し、起動する可能性があります。トランザクションの無効化は、トランザクション定義を保持したままトランザクション監視を休止する方法の1つです。

8. デフォルトでは、トランザクションのスコープ(完了するまでにかかる時間)は1分に設定されます。Business Transaction Managementでは、トランザクション・メッセージの検出においてこの値がガイドラインとして使用され、一意のコンテンツの出現が予期される時間枠が定義されます。トランザクションの特性に応じて、「最大トランザクション期間」に対して、この値を長い期間に変更できます。(1分という値は、最小設定とデフォルト設定の両方です。)ここでの目的は、正常に完了しそうにないトランザクションを閉じて、必要なリソースを解放することです。

トランザクションの作成後にJDBCサマリー・モードの設定を変更する場合は、さらにトラフィックを実行してからトランザクション定義を更新する必要があります。詳細は、4.1.4.2項「サマリー・オプション変更後のトランザクション定義の更新」を参照してください。

5.4.1.2 セグメンテーションの有効化

Business Transaction Managementでは、IPアドレスに基づいてトランザクションの測定値を切り分けることも、個々のコンシューマごとに測定値を切り分けることもできます。セグメンテーションを有効にするには、「トランザクション」ツールの「セグメンテーション」タブを使用します。セグメンテーションを有効にすると、トランザクションの使用状況SLAを作成し、トランザクション使用状況をクライアントIPアドレスごとに表示し、トランザクション測定結果をコンシューマ別に表示できます。「プロファイル」タブでは、有効化されているセグメントおよびコンシューマ・プロパティとして使用されているプロパティを確認できます。

セグメンテーション・オプションのいずれか、または両方を有効にすることができます。次の図に、セグメンテーションを有効にして特定のプロパティをコンシューマにマップした後のタブの表示を示します。コンシューマ・アイコンに注意してください。

セグメンテーションを有効にするには:

1. 「トランザクション」ツールの「セグメンテーション」タブを選択します。

2. クライアント・アドレス(IP)セグメンテーションを有効にするには、チェック・ボックス「クライアント・アドレスのセグメンテーションを有効化」を選択します。

3. コンシューマ・セグメンテーションを有効にするには、チェック・ボックス「コンシューマ・セグメンテーションを有効化」を選択します。
コンシューマ・セグメンテーションは、トランザクションの開始メッセージのプロパティの定義に依存します。このプロパティは、コンシューマ・ビジネス・オブジェクトにマップするメッセージ要素を示します。トランザクションを定義する前にこのプロパティを定義していない場合は、手順4から9に示すように定義を実行できます。プロパティを定義した場合は、ここでそれを選択します。

4. 「新規プロパティ」ボタンをクリックします。Business Transaction Managementによって「プロパティの作成」ツールが表示されます。

5. プロパティの名前を指定し、必要に応じて説明を入力します。

6. プロパティ・ソース: プロパティ値のソースを「メッセージ・コンテンツ」または「ヘッダー」から選択します。

7. 「メッセージから選択....」リンクを選択し、コンシューマ・ビジネス・オブジェクトにマップする要素を選択します。

8. コンシューマ・マッピング: チェック・ボックス属性コンシューマ名を通じてコンシューマにマップを選択します。必要に応じて後で選択内容を変更できますが、複数のプロパティをコンシューマ・オブジェクトにマップすることはできません。

9. 機密情報が含まれているためコンシューマ名をそのまま表示しない場合は、「秘密として扱う」チェック・ボックスを選択します。

10. 「OK」をクリックします。

5.4.1.3 インスタンス・ロギングおよびメッセージ・コンテンツ・ロギングの有効化

インスタンス・ロギングを有効にすると、指定した時間間隔に取得されたトランザクション・インスタンスのリストを表示できます。これらは、「トランザクション」ビューの「インスタンス」タブに表示されます。指定したインスタンスを検査し、そのインスタンスにプロパティ値がある場合はそれを表示し、プロパティ値に基づいて各種条件を作成できます。これらの任意のインスタンスをアセンブルすることもできます。

インスタンス・ロギングを有効にするには:

1. 「ロギング」タブを選択します。

2. 「インスタンスとプロパティのロギングを有効化」というタイトルのチェック・ボックスを選択します。

メッセージ・コンテンツ・ロギングを有効にすると、指定した操作のメッセージ・コンテンツを表示できます。(この場合、Business Transaction Managementによって、この特定のトランザクション・フローに属しているメッセージではなく、指定した操作のすべてのメッセージがログに記録されます。)メッセージ・コンテンツには様々な方法で到達できます。メッセージ・ログ検索ツールを使用してフリー・テキスト検索に基づいて操作を見つけ、関連するトランザクション・インスタンスを開くか、または「分析」タブおよびアラートからメッセージ・ログにドリルできます。

メッセージ・コンテンツ・ロギングを有効にするには:

1. 「ロギング」タブを選択し、「選択した操作に対するメッセージ・コンテンツ・ロギングを有効化」というタイトルのチェック・ボックスを選択します。

2. コンテンツをログに記録する操作(メッセージ)を選択します。メッセージ・コンテンツのロギングは負荷の高い操作です。メッセージのロギングを開始する前に、対象のメッセージのスコープを限定することをお薦めします。

前述の例は、CreditServiceサービスの操作checkCreditに対してメッセージ・コンテンツが有効であることを示しています。

5.4.1.4 手動キーを使用したトランザクション内のメッセージの相関

デフォルトでは、各メッセージのコンテンツに基づいてフィンガープリント(ハッシュ値)を計算することによって、およびコール・チェーンの最後まで着信メッセージを送信メッセージと組み合せることによって、Business Transaction Managementでトランザクション内のメッセージが相関されます。手動キーを定義することは、メッセージの相関にかわる方法です。手動相関は、トランザクションへのセカンダリ操作フローの追加、終了メッセージと開始メッセージが同じ操作に属していないトランザクションの定義、および欠落メッセージ条件の定義のために使用されます。

トランザクション・メッセージは1つの方法で相関させる必要はなく、一部のメッセージを自動相関させ、他のメッセージを手動キーを使用して相関させることができます。手動キーを定義するには、メッセージ・プロパティにマップする必要があり、そのプロパティによって次に説明する特定の要件が満たされている必要があります。

手動キーはメッセージ・プロパティにマップされます。

プロパティは、メッセージ内の単一要素、要素の組合せ、または要素のフラグメントに対応します。プロパティを定義してから手動キーを定義できます。

手動キーに対して定義するプロパティは、次の2つの要件を満たしている必要があります。

- その値は、相関させているメッセージと同じである必要があります。

- その値は、トランザクションのスコープに対して一意である必要があります(スコープは「最大トランザクション期間」の値によって定義されます)。

たとえば、ショッピング・タイプ・アプリケーションでは、受注IDが手動キーに適した選択肢である場合があります。

次の場合には操作を手動で相関させる必要があります。

- トランザクションへのセカンダリ操作フローの追加。これは、JMSなどの非同期システムの場合に必要になることがあり、基礎となるデータを共有するが因果関係としては接続されない2つの操作フローを接続する場合に望ましいことがあります。たとえば、受注の入力によって定義されるフローと、受注の終了によって定義される別のフローがあります。同じ受注が2つの別々のプロセスに関与します。
この場合、リンクする2つの操作を識別し、メッセージ・プロパティにマップできるそれら2つの操作の共通の要素を見つける必要があります。プロセスとしては、操作をトランザクションに追加し、トランザクション内の既存の操作に接続し、リクエストが進む方向を指定します。2つの操作は「メッセージ・キー」タブに表示され、ここで手動キーを使用してそれらを接続できます。

- 終了メッセージがフローを開始した操作の終了メッセージとは異なるトランザクションの定義。
この場合、メッセージ・プロパティにマップできる開始メッセージと目的の終了メッセージ内の共通の要素を見つける必要があります。終了メッセージを指定すると、開始メッセージと終了メッセージを接続する手動キーの入力を求められます。

- 欠落メッセージ条件の定義。
欠落メッセージ条件では、開始メッセージの発生後、指定した時間内に指定したターゲット・メッセージが着信しない場合にアラートが生成されます。この場合、開始メッセージとターゲット・メッセージに共通の要素に対してキーを定義する必要があります。欠落メッセージ条件を定義すると、開始メッセージとターゲット・メッセージを接続するキーの入力を求められます。

「トランザクションの作成」ツールの「メッセージ・キー」タブを使用して、セカンダリ・フローを追加するときにBusiness Transaction Managementによって操作が相関される方法を定義します。指定した操作が依存性フロー内の複数の操作と相関する場合は、相関ごとに手動キーを作成するオプションがあります。同じキーを使用して3つの異なる操作に相関させる必要も、同じ相関方法を使用する必要もありません。

メッセージを相関させる手動キーを作成するには:

相関を定義する前に必要なプロパティを定義するか、または「メッセージ・キー」タブからプロパティ・ツールにアクセスして、相関を定義するのと同時にプロパティを定義できます。

1. 「メッセージ・キー」タブを選択します。

2. 相関させる操作の組合せの開始操作を選択します。

3. 当該の開始操作の「メッセージ・フィンガープリント」項目をクリックして、キー・ドロップダウン・リストを表示します。Business Transaction Managementによって操作のプロパティのリストが表示され、そこから手動キーとして使用するものを1つ選択できます。

4. キーとして使用するプロパティを選択します。

5. 操作の各呼出しに対して一意の値を持つプロパティが表示されない場合は、ドロップダウン・リストから「新規プロパティ」を選択してプロパティ・ツールを開き、そのツールを使用してメッセージ・キーとして使用するプロパティを定義します。

6. キーを作成した開始操作に対応する終了操作を選択します。

7. 手順4から5を繰り返して、終了操作のキーを選択および定義します。(プロパティ名は異なる場合がありますが、プロパティの値は同じである必要があり、トランザクション・インスタンスに対して一意である必要があります。)

8. 相関させる操作の各組合せに対して手順4から7を繰り返します。(手動キー用に作成したプロパティは、選択したトランザクションの「プロファイル」タブの「プロパティ」ペインに表示されます。)トランザクションの定義が終了すると、手動キーを使用して相関されるすべての操作について、トランザクションを表すグラフィックはフィンガープリント・アイコンではなくキー表示アイコンに変わります。

5.4.1.5 記憶域設定の定義

トランザクションの定義の最後の手順は、アーカイブ設定の定義とメッセージ・コンテンツの索引付けの有効化です。

「記憶域設定」タブを使用してこれらの値を定義します。次の表にデフォルト設定を示し、設定の意味を説明します。

項目

デフォルト値

説明

アーカイブされた条件インスタンスを維持

30日

Business Transaction Managementで、アーカイブされた条件インスタンスをトランザクション・サーバーのデータベースに維持する必要がある時間。
アーカイブされた条件インスタンスは、トランザクションに属している操作のいずれかに対して設定された条件がtrueと評価されたときにアセンブルされて維持されるトランザクション・インスタンスです。(インスタンス・ロギングがオンになっていない場合は、条件を定義するときにオンにする必要があります。)

個々のメッセージを維持

24時間

Business Transaction Managementで、ログ・メッセージをトランザクション・サーバーのデータベースに維持する必要がある最小時間。

メッセージ・ログの切替え

720分

メッセージ・ロギングをオンにした場合は、これによってログ・メッセージの切替え間隔を指定します。切り替えられたメッセージは、「個々のメッセージを維持」に対して定義された時間、メッセージ・ログ・データベースに保持されます。

テキスト索引のメッセージ・コンテンツ

オン

キーワードベースの検索を高速化するテキスト索引をOracleデータベースに作成します(記憶域と初期処理時間が必要になります)。この機能を無効にした場合でもコンテンツベースの検索を実行できますが、時間がかかります。

5.4.2 トランザクション定義の変更

トランザクション定義を変更すると、環境内のトランザクションの定義が変更されます。トランザクション定義の任意の部分を変更できますが、Business Transaction Managementでは定義のバージョンは追跡されないことに注意してください。そのため、定義を変更する部分によっては混乱が発生する場合があります。たとえば、トランザクション定義に対して操作を追加または削除した場合、または操作を相関させるために使用するキーを変更した場合で、変更した定義に先行していたトランザクション・インスタンスをアセンブルしようとすると、予期せぬ結果が生じる場合があります。一方、トランザクションの有効化または無効化や記憶域オプションの変更では、問題は発生しません。

トランザクション定義を変更するには:

1. 「エクスプローラ」→「トランザクション」サマリー・ビューで、対象のトランザクションを選択します。

2. 「変更」メニューから、「TransactionNameの編集」を選択します。

3. トランザクション変更ツールを使用して、トランザクション定義を変更します。定義要素の詳細は、5.4.1項「トランザクションの定義」を参照してください。

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

Business Transaction Managementには、定義を編集しなくてもトランザクションを有効または無効にするために使用できるショートカットがあります。

トランザクションを有効または無効にするには:

1. 「エクスプローラ」→「トランザクション」サマリー・ビューで、対象のトランザクションを選択します。

2. 「変更」メニューから、「TransactionNameの有効化」または「TransactionNameの無効化」を選択します。選択したトランザクションの現在のステータスに応じて、適切なアクションを使用できます。

5.4.3 トランザクション定義の削除

トランザクション定義を削除すると、環境から定義が削除されます。このトランザクションに対して定義されている条件アラートはトリガーされません。このトランザクションの既存のインスタンスはすべて削除されます。

トランザクションを削除するには:

1. 「エクスプローラ」→「トランザクション」サマリー・ビューで、対象のトランザクションを選択します。

2. 「変更」メニューから、「TransactionNameの削除」を選択します。

3. 削除を確定します。

5.5 トランザクション・パフォーマンスの表示および監視

トランザクションの定義後、トランザクションの監視が有効な場合は、Business Transaction Managementによってデフォルトのトランザクション測定ポリシーが適用されます。また、トランザクションのインスタンス・ロギングまたはメッセージ・コンテンツ・ロギングが有効な場合は、適切な情報のロギングが開始されます。

トランザクションに参加しているサービスをトラフィックが通過すると、Business Transaction Managementによって、選択したトランザクションのコア測定がメイン領域に表示されます。これには、開始済トランザクションと完了済トランザクションの数、スループットおよび平均レスポンス時間が含まれています。タブ領域には、トランザクション・パフォーマンスとその定義に関する詳細情報が表示されます。次の情報が含まれます。

- トランザクションのパフォーマンス情報およびトランザクションに含まれる操作のマップを示す「サマリー」タブ。

- 時間の経過に伴うトランザクション・パフォーマンスのグラフィカル・ビューと、条件、コンシューマ使用状況またはクライアント・アドレスごとにセグメント化されたパフォーマンス、および違反アラートのサマリー情報を示す「分析」タブ。このタブには、独自のカスタム・チャートおよび内訳を作成するオプションもあります。

- 指定した期間にこのトランザクションについてトリガーされたアラートを示す「アラート」タブ。

- 「インスタンス」タブ。インスタンス・ロギングを有効にした場合、このタブを使用してインスタンスをアセンブルし、インスタンスのパフォーマンス情報を表示できます。

- 「メッセージ・ログ」タブ。メッセージ・ロギングを有効にした場合、このタブを使用して、ログに記録された操作の任意のリクエストまたはレスポンス・メッセージのコンテンツを表示できます。

- このトランザクションに現在関連付けられているサービス・レベル合意のステータスおよび定義を表示する「SLA準拠」タブ。

- 定義タブ。これらのタブには、トランザクションに関連付けられているトランザクション定義とポリシー、条件およびプロパティに関する情報が含まれています。

この項では、トランザクション属性を使用してトランザクション表示をフィルタ処理する方法、トランザクションのサマリーおよび分析パフォーマンス情報を表示する方法およびアラートを表示して応答する方法について説明します。

トランザクション・パフォーマンスの測定に使用されるインスツルメントの詳細は、6.3項「インスツルメントについて」を参照してください。

5.5.1 トランザクションのメイン・ビューのフィルタ処理

デフォルトでは、ナビゲータから「トランザクション」を選択すると、すべてのトランザクションがメイン領域に表示されます。「フィルタ」リンクまたはドロップダウン・リストを使用して、現在定義されているトランザクションのサブセットが表示されるようにBusiness Transaction Managementを設定できます。フィルタを使用すると、ビューをカスタマイズでき、目的の特性に焦点を当てることができます。

5.5.2 パフォーマンス情報のサマリーおよび分析

Business Transaction Managementでは、「トランザクション」ビューの「サマリー」および「分析」タブを使用して、トランザクション・パフォーマンスのサマリーおよび詳細分析が表示されます。この項では、これらの表示について説明します。

5.5.2.1 「サマリー」タブ

「サマリー」タブでは、4つのペインと1つのグリッド・ビューを使用して、トランザクション・サマリー・ダッシュボードにパフォーマンス情報を表します。これらのほとんどは説明不要ですが、「遅延分析」ペインは例外であり、これについては次に詳細に説明します。

トランザクション・サマリー・ダッシュボードには、次のものが含まれています。

- トランザクションのコンプライアンス全体を示す「ステータス」ペイン。

- 開始済トランザクションと完了済トランザクションの数、平均レスポンス時間および最大レスポンス時間を示す測定とベースライン・ペイン。ベースラインが定義してある場合、これらは図でグレーの線で示されます。

- トランザクション・リンクごとに平均レスポンス時間を示すトランザクションのマップ。カーソルを各サービス・アイコンに置くと、そのサービスのパフォーマンスの詳細情報が取得されます。矢印の厚みはスループットを示します。

- マップ・ペインと一緒に使用できる「遅延分析」ペインでは、トランザクションの各ホップ(リンク)で消費されるレスポンス時間全体の割合が図で示されます。
グリッドの色付けされた各領域はトランザクション・リンクに対応します。色付きの領域内をクリックすると、マップ内の対応するリンクがハイライト表示され、そのホップでの所要レスポンス時間の割合が表示されます。

このペインの下部のグラフには、平均レスポンス時間と最大レスポンス時間および開始済トランザクションが表示されます。ペイン内をクリックすると、縦の赤線が表示され、色付けされた割合がメッセージ・トラフィック・フローにどのように対応しているかが示されます。

- トランザクションを構成する論理および物理操作と、違反アラート、平均レスポンス時間、最大レスポンス時間、スループットおよびフォルトのそれぞれに関するインスツルメントを示すグリッド・ビュー。

5.5.2.2 「分析」タブ

「トランザクション」ビューの「分析」タブでは、「サマリー」タブの測定を時間の経過に伴う傾向として図で表示できます。「分析」タブには、トランザクション・パフォーマンス・データの6個のビューがあります。これらについて、次の表で説明します。

ビュー

説明

パフォーマンス

2色に分けられたチャートが表示され、一方は開始済トランザクション、完了済トランザクションおよび条件を追跡し、もう一方は平均レスポンス時間と最大レスポンス時間を追跡します。

条件

指定期間にトリガーされた条件に関する情報(満たされた条件の名前、条件アラートがトリガーされたエンドポイント、トリガーされた条件アラートの数)が表示されます。

コンシューマ使用状況

コンシューマ別にセグメント化することを選択した場合: サービス・コンシューマとそれらが関連した開始済トランザクションと完了済トランザクションの数、各コンシューマの平均レスポンス時間および最大レスポンス時間が表示されます。

クライアント・アドレスによるブレークダウン

IPアドレス別にセグメント化することを選択した場合: トランザクションに関連するサービスのホスト、それぞれで開始および完了したトランザクションの数、各ホストの平均レスポンス時間および最大レスポンス時間が表示されます。

カスタム・チャート

カスタム・チャートのパフォーマンス結果が表示されます。選択したインスツルメントでカスタマイズされたチャートや表を設定できます。
「インスツルメントの選択」をクリックして、チャートや表に表示するインスツルメントを選択します。複数のインスツルメントを選択できます。

カスタム内訳

測定するカスタム・パフォーマンス情報および測定が実行される対象セグメントを定義します。
「インスツルメントの選択」をクリックして、表に表示するインスツルメントを選択します。複数のインスツルメントを選択できます。「セグメントの選択」をクリックして、測定をセグメント化する方法を選択します。複数のセグメントを選択できます。

5.5.3 アラートの表示および応答

アラートは、選択したトランザクションの「アラート」タブに表示されます。そのタブの「フィルタ」ボタンを使用して、アラートが表示される時間範囲を設定できます。

次のいずれかの状況が発生した場合、システムにより自動的にアラートが生成されます。

- SLA施行ポリシーによって、失敗アラート、警告アラートまたはコンプライアンス・アラートが発行されます。

- 条件がtrueに評価されます。

アセンブルされたトランザクション・インスタンスを調べ、適切なアクションを実行することで、条件によってトリガーされたアラートに応答できます。

5.6 「上位10件のトランザクション」ダッシュボード

「上位10件のトランザクション」ダッシュボードを使用すると、システム内で最も負荷がかかっているコンポーネントの状態をすばやく識別および評価できます。

ダッシュボードを表示するには、「ダッシュボード」→「上位10件のトランザクション」を選択します。

ダッシュボードには4つの表が表示されます。各表は特定のインスツルメントに基づいており、そのインスツルメントで測定が最も高い(稼働時間のみは最も低い)10件のトランザクションが表示されます。

トランザクションに対して表示されるデータのデフォルトの評価期間は7日間です。評価期間を変更するには、一番上に表示されている「時間間隔」コントロールをクリックします。期間は、過去1日間、過去1時間または過去10分間に変更できます。

「上位10件のトランザクション」ダッシュボードには、次の特性を持つ10個のトランザクション・タイプを表示する表があります。

- 最も多い開始済トランザクション数(「最多開始済」表)

- 最も多い完了済トランザクション数(「最多完了済」表)

- 最も遅い平均レスポンス時間(「最遅平均レスポンス時間」表)

- 最も多い条件アラート数(「最多条件アラート」表)

各表には、インスツルメントの数値とチャートが表示されます。カーソルをチャートに合わせて、特定の時間区分の詳細情報を表示します。

詳細な情報および分析を参照するには、トランザクションまたはサービスをダブルクリックしてタブ領域を表示し、「分析」タブを選択します。

5.7 トランザクション・インスタンスの表示

トランザクションは、通常、指定期間に何度か実行されます。トランザクション・インスタンスのロギングを有効にしているか、フォルト監視を有効にしている場合、Business Transaction Managementは、トランザクションに含まれるメッセージのフローを追跡し、これらを特定のトランザクション・インスタンスにマップします。これは、次の場合、トランザクション・インスタンスのメッセージをアセンブルします。

- フォルトの結果アラートが生成される場合、または条件が満たされる場合

- アセンブリを明示的に要求する場合

トランザクション・インスタンスをアセンブルすると、「インスタンス」タブを使用して、そのインスタンスのパフォーマンスの詳細情報を表示できます。「メッセージ・ログ」タブを使用して、特定のプロパティ値を含むメッセージを検索することもできます。メッセージのコンテンツを表示するには、メッセージ・コンテンツ・ロギングを有効にする必要もあります。

この項では、次のことを実行する方法を説明します。

- すべてのトランザクション・インスタンスのサマリーの表示とこれらのサブセットの検索

- インスタンスのアセンブルおよび検査

5.7.1 取得したトランザクション・インスタンスの表示

トランザクションのタブ領域の「インスタンス」タブでは、取得したトランザクション・インスタンスを表示できます。

表のID列に、アセンブルされたインスタンス(ID値が割り当てられている)とアセンブルされていないインスタンス(「アセンブル」ボタンがある)の両方が表示されます。

各インスタンスの情報により、インスタンスの取得時間、トランザクション・インスタンス全体の応答時間、プロパティの値(プロパティを作成した場合)が示されます。

「インスタンスの表示」フィルタ処理制御では、指定期間に発生したインスタンスをリストしたり、アセンブルしたインスタンスのみを表示したりすることができます。

どのインスタンスをアセンブルするかは、目的によって異なります。たとえば、レスポンス時間が異常に遅いインスタンスをアセンブルする場合や、プロパティ値が予想外のインスタンスをアセンブルする場合などがあります。

大量のメッセージを取得している場合、「メッセージ・ログ」タブを使用し、プロパティ値に基づいて検索対象となるメッセージの量を減らしてから、インスタンスを1つ以上アセンブルできます。

5.7.2 インスタンスのアセンブルおよびインスタンス・インスペクタの使用方法

インスタンスをアセンブルするには、「インスタンス」タブでインスタンス・インスペクタ・アイコン(拡大鏡)をクリックします。

Business Transaction Managementによって「トランザクション・インスタンス・インスペクタ」が表示されます。このビューは、トランザクション・インスタンスの識別情報(上部)、マップ・ビュー(中央)およびトランザクション・インスタンスに含まれているすべての操作を表示するグリッド・ビュー(下部)という3つの部分で構成されています。

インスペクタの上部には、トランザクションの名前、アセンブルしたインスタンスの実行開始時間、そのID、メッセージ交換の数、交換したメッセージの総数、開始メッセージから終了メッセージまでのレスポンス時間が表示されます。この領域には警告またはフォルトも表示されます。

それに続くインスタンス・マップでは、トランザクション・インスタンス全体と、リクエスト/レスポンス・リンクごとに指定されたレスポンス時間を表示できます。カーソルを操作名に移動すると、サービス・タイプ、エンドポイント名およびホスト名とポートが表示されます。コールされなかった操作およびJDBCコールを非表示にするオプションがあります。JDBCコールを非表示にすると、データベースをコールする操作が多数ある複雑なトランザクションのコール・グラフを大幅に簡素化できます。

インスペクタ・ウィンドウの一番下にあるグリッド・ビューには、トランザクション・インスタンスに含まれる各メッセージの詳細が表示されます。プロパティ値を定義してある場合、ビューにはプロパティ値を表示する列が含まれています。表示される情報は、JDBCサマリー・モードの設定の影響を受ける場合があります。詳細は、4.1.4.1項「JDBCサマリー・データの表示の理解」を参照してください。

操作の拡大鏡(ティアオフ・コントロール)をクリックすると、「メッセージ・コンテンツ」インスペクタ・ウィンドウが開き、その操作に対してメッセージ・コンテンツ・ロギングを有効にしている場合、選択したメッセージのコンテンツが表示されます。

5.8 ログ・メッセージおよびプロパティの表示

トランザクションの「メッセージ・ログ」タブを使用して、次の情報を表示できます。

- インスタンス・ロギングが有効な場合、指定期間にログに記録された各メッセージに関する情報と、メッセージに関連付けられたプロパティの値を表示できます。メッセージ・ログ検索ツールを使用して、関連するプロパティ値を含んでいるか、メッセージに関連付けられたECID値に基づくメッセージを検索することもできます。

- メッセージ・コンテンツ・ロギングが有効な場合、指定期間にログに記録された各メッセージに関する情報と、そのコンテンツを表示できます。この場合、プロパティ値およびECID値に基づいてメッセージを検索する以外に、メッセージ要素のコンテンツに基づいて検索することもできます(フリー・テキスト検索)。

Business Transaction Managementは、次の操作を行った場合のみ、メッセージ・コンテンツまたはインスタンス、およびプロパティ値のログを記録します。

- トランザクションに対して監視を有効化しました。

- トランザクションに対して適切なタイプのロギング(インスタンスまたはメッセージ)を有効化しました。

- メッセージ・ロギングの場合、1つ以上の操作を選択しました。

ログが記録された情報は、トランザクションの作成時に定義する記憶域設定に従って保存されます。

この項では、メッセージに関する情報の表示、メッセージ・ログでのメッセージの検索、およびロギングの有効化または無効化を行う方法について説明します。

5.8.1 ログ・メッセージおよびプロパティに関する情報の表示

指定したトランザクションの「メッセージ・ログ」タブには、メッセージのリストを表示するグリッド・ビューを使用して情報が表示され、リクエスト・メッセージの着信時刻、選択した操作を含むサービス、サービスを実装するエンドポイントの場所、操作(メッセージ)および操作のタイプが表示されます。操作にプロパティが関連付けられている場合、その値は、タイトルがプロパティ名になる追加列に表示されます。

メッセージ・コンテンツのロギングが有効な場合、メッセージをダブルクリックすると、メッセージのコンテンツが表示されます。

グリッドに表示されるメッセージのセットは、タブの上部に表示されるフィルタの設定によって異なります。これを使用して次のものを表示できます。

- すべての操作、またはドロップダウン・リストから選択した特定の操作

- すべてのレスポンス、成功した操作のみ、障害のみ

- 最後に指定された期間で示される時間間隔内、特定の時間以降、または特定の時間と時間の間に到着したメッセージ。

これらの制御を使用して、グリッドに表示されるメッセージの選択を絞り込むことができます。フィルタ設定を変更したら、「検索」を再度クリックしてグリッドに再移入します。

検索をさらに限定するには、「コンテンツの選択...」リンクからアクセスするメッセージ検索ツールを使用します。これにより、プロパティ値やメッセージ・コンテンツに基づいて(メッセージ・コンテンツが有効な場合)メッセージを検索できます。このツールについては、次の項で説明します。

5.8.2 メッセージ・ログ検索ツールの使用方法

メッセージ・ログ検索ツールを使用すると、(ビュー・フィルタによって定義される制限以外に)検索のスコープおよび基準をさらに絞り込むことができます。このツールを起動するには、「表示」メニューから「メッセージ・ログの検索」を選択します。これにより、ロギングが有効になっている監視対象トランザクションに属するメッセージを検索できます。

トランザクションの「メッセージ・ログ」タブから「コンテンツの選択...」リンクをクリックして、現在選択されているトランザクションに属するメッセージを検索することもできます。ただし、このより制限された検索には、検索結果を取得したときに関連トランザクションを検索する追加オプションはありません。

メッセージ・ログ検索ツールには検索基準を定義するために使用できる4つのメイン領域があり、それらはユーザー定義プロパティを使用した検索用の領域、ECIDベースの検索用の領域、プロパティaggregateCountおよびaggregateFaultCountに関連する検索用の領域、「フリー・テキスト検索」というラベルの付いた領域です。これらの領域内のコントロールを使用して、基準と一致するメッセージのセットを検索します。基準を指定すると、ツールの上部にあるテキスト・ボックス内で検索式が構成されます。ボックスをクリアしてやりなおすには、「クリア」ボタンを押します。

Oracle問合せ言語を使用して問合せを構成する方法の詳細は、次の場所を参照してください。

http://download.oracle.com/docs/cd/B28359_01/text.111/b28304/cqoper.htm#BABBJGFJ

検索で使用される式を定義したら、「OK」ボタンをクリックします。次に、「検索」ボタンをクリックして、新たに定義された検索基準に従ってグリッドに再移入します。

次の各項では検索のタイプごとに詳細を説明しますが、1つのタイプに制限されず任意の組合せで使用できることに注意してください。たとえば、特定のプロパティとECID値を持つメッセージを検索できます。

5.8.2.1 ECIDベースの検索

メッセージ(操作)にリクエストまたはレスポンスECIDが割り当てられている場合は、特定のECID値が割り当てられているそれらのメッセージを検索できます。ECIDの意味および割当ての詳細は、5.9項「その他の診断ツールへのアクセス」を参照してください。

ECIDベースの検索を実行するには、ECIDフィールドで一致基準を選択し、ECID入力フィールドにECID値を入力するか貼り付けます。ECID値は、それが表示されている任意の場所からコピーできます。列からコピーする場合は、列を拡張して文字列値全体を取得するようにします。メッセージ・ログ検索ツールによって、すべてのトランザクション・インスタンスでの指定したECIDのすべての操作がグリッド・ビューに表示されます。

図5-1 ECIDベースの検索

指定したECIDを含む特定のトランザクション・インスタンスを表示する場合は、メッセージ・ログ検索ツールのグリッド・ビューで当該の操作を選択し、メッセージ・ログ検索ツールで「表示」→「関連トランザクション」→「target_Transaction」を選択します。当該のインスタンスがインスタンス・インスペクタ・ウィンドウに表示されます。

5.8.2.2 プロパティ・ベースの検索

当該のトランザクションに対して定義されているプロパティが、「メッセージのプロパティ検索」領域に表示されます。ドロップダウン・リストを使用して、プロパティ・ベースの検索基準を指定します。

- 数値の場合は、ドロップダウン・リストによって、プロパティがより小さい、等しい、より大きい、等しくないなどのメッセージを検索できます。

- 文字列値の場合は、ドロップダウン・リストによって、同様の一致オプションのセットが提供されます。

5.8.2.3 フリー・テキスト検索

この検索オプションを使用するには、メッセージ・コンテンツ・ロギングを有効にしておく必要があります。

「メッセージに含まれるテキスト」というラベルが付いたボックスに、検索する文字列を入力します。引用符で囲まれた文字列を検索する場合以外は、文字列を引用符で囲まないでください。

5.8.3 メッセージ・ロギングおよびインスタンス・ロギングの有効化および無効化

メッセージ・ロギングおよびインスタンス・ロギングを有効または無効にするには、次の手順を実行します。

1. 対象となるトランザクションを選択します。

2. 「変更」→「TransactionNameの編集」を選択します。

3. 次に表示されるダイアログで、「ロギング」タブを選択します。

4. 表示されるチェック・ボックスを使用して、メッセージ・コンテンツ・ロギングおよびインスタンス・ロギングを有効または無効にします。

5. メッセージ・ロギングを有効にする場合は、ログに記録する特定の操作を選択します。

5.9 その他の診断ツールへのアクセス

トランザクション、サービス、エンドポイントおよび操作に関して提供されるメトリック以外に、Business Transaction Managementでは、リクエストが実行されるJVMコンテキストの詳細を表示でき、分散JVM間で実行される場合のリクエストの詳細を表示できます。

追加のビューは次のとおりです。

- JVMDビューでは、指定の操作が実行される期間内で、実行中のJava仮想マシン(JVM)プロセスの詳細を表示できます。スレッドを実行するためのスタック・フレーム、スレッド状態に関する情報、メソッド実行の頻度やコストに関する集計情報、JavaおよびDBロックの保持に関する情報、Javaヒープのオブジェクトに関する詳細を確認できます。JVMDでは監視する各JVMの履歴データも保存されるため、過去に発生した出来事に関連するデータを表示したり、履歴傾向の要点を取得することができます。

- 「インスタンス診断リクエスト」ビューでは、WebLogicドメインでリクエストのパスをトレースしたり、リクエストの特定のインスタンスに関連するすべてのメトリックのレポートを生成することができます。

次の各項では、これらのビューがトランザクション操作に関連する場合にそこから取得できる情報について説明し、Business Transaction Managementコンソールからこれらのビューにアクセスする方法について説明します。

これらのビューにアクセスするようにBusiness Transaction Managementを構成する方法の詳細は、5.9.3項「JVMDおよびRIDビューへのアクセスの有効化」を参照してください。

5.9.1 JVMDビューの使用方法

JVMDを使用して追加情報にアクセスすることは、次のような状況で有用です。

- トランザクションのサマリー情報を表示しているときに、特定の操作が異常に遅いか障害があることに気付きました。そのステップの実行に関する詳細を取得する必要があり、このポイントからJVMDへのドリルを開始します。

- ログに記録されたトランザクション・インスタンスの詳細を表示しているときに、トランザクションのステップのいずれかが予期したとおりに動作しなかったことに気付きました。このステップの実行に関する詳細がJVMDから必要であり、このポイントからJVMDへのドリルを開始します。

- メッセージ・ログ検索ツールでログ・メッセージのコレクションを表示しているときに、異常または通常以外のメッセージに気付きました。JVMDを使用してそのメッセージの処理の詳細を取得する必要があり、このポイントからJVMDへのドリルを開始します。

次のエントリ・ポイントからJVMDコンソールにアクセスできます。

- サービス、エンドポイント、論理操作、物理操作またはトランザクションの「メッセージ・ログ」タブ。行を右クリックし、ドロップダウン・リストから「JVMDにドリルダウン」を選択します。

- 「トランザクション・インスタンス・インスペクタ」。(グラフまたはグリッド・ビューで)操作を右クリックし、ドロップダウン・リストから「JVMDにドリルダウン」を選択します。ステップが繰り返し実行される場合は、それが実行された最初のエンドポイントが選択されます。

- メッセージ・ログ検索ツール。メッセージ行を右クリックし、ドロップダウン・リストから「JVMDにドリルダウン」を選択します。

これらのいずれの場合も新しいウィンドウが開き、JVMDビューが表示されます。VMが複数台ある場合は、VMグループ・ターゲットと、そのグループの集計情報がJVMDに表示されます。

JVMDページへのアクセスを有効にする方法の詳細は、5.9.3項「JVMDビューおよびRIDビューへのアクセスの有効化」を参照してください。

5.9.2 「インスタンス診断リクエスト」ビューの使用方法

「インスタンス診断リクエスト」ビューで操作(メッセージ)に関する情報を表示するには、そのメッセージに実行コンテキスト識別子(ECID)が割り当てられている必要があります。この項では、ECIDとは何か、ECIDを割り当てる方法、トランザクションへのマップ方法、Business Transaction Managementコンソールから「インスタンス診断リクエスト」ビューにアクセスして使用する方法について説明します。

JRF 11.1.1.1.0以上のWebLogic (10.3.x)ドメインで実行されている操作についてのみ、「インスタンス診断リクエスト」ビューにデータが表示されます。(SOA 11g、OSB 11gおよびFusion Applicationsのインストールには、すでにJRFが含まれています。)

「インスタンス診断リクエスト」ページへのアクセスを有効にする方法の詳細は、5.9.3項「JVMDビューおよびRIDビューへのアクセスの有効化」を参照してください。

メッセージ・リクエストまたはレスポンスのECID情報は、JVMDエージェントのインストールまたはEMコンソールへの接続の構成を行っていなくてもBusiness Transaction Managementコンソールに表示されますが、これらの前提条件を満たしていないと、指定したECIDの「インスタンス診断リクエスト」ビューを開くことはできません。

メッセージ・ログ検索ツールを使用して、指定したECIDを持つすべてのメッセージを検索できます。詳細は、5.8.2項「メッセージ・ログ検索ツールの使用方法」を参照してください。

5.9.2.1 ECIDの基本

ECIDは、Oracleテクノロジ・スタックでコンポーネントに対するリクエストを追跡するための識別子です。通常はリクエストを処理する最も外側のOracleコンポーネントによって生成され、そのリクエストを処理するOracleコンポーネントによって伝播される場合があります(サーバーの境界を越える場合もあります)。ECIDの作成と伝播により、コンポーネント間でのコンテキストおよび診断データの共有ができるようになります。

実行コンテキスト対応コンポーネントによって処理されたトランザクション操作(メッセージ)は、すべてのリクエスト・ステップによって共有されるECIDが割り当てられた、リクエスト内のステップを表します。Business Transaction Managementによって、メッセージに関連付けられたECIDがあることが検出された場合、そのECIDはメッセージ・リクエストおよびレスポンスの固有のプロパティとして割り当てられ、ECIDの値はメッセージ・ヘッダーに書き込まれます。指定した操作およびフェーズのECID値は、標準プロパティrequestECIDおよびresponseECIDに格納されます。

トランザクションは複数のOracle実行コンテキストにわたる場合があるため、トランザクション内の異なるメッセージは異なるECIDを持つ可能性があります。また、同じECIDが異なるトランザクション内の操作によって共有されることもあります。次の項では、ECIDがトランザクション操作(メッセージ)にどのようにマップされるかについて説明します。

ECIDを使用してJVMDビューまたはRIDビューにドリルダウンする以外に、ECIDは次の状況でも有用です。

- 開始メッセージと終了メッセージが異なるトランザクションを定義します。この場合、共通のECID値を使用して開始メッセージと終了メッセージを相関させることができます。これにより、BTMによってこのようなトランザクションのパフォーマンスを測定できます。

- ECIDを共有されるキー値として使用して、接続されていない2つの操作を手動で相関させます。

- 特定のECID値を持つメッセージを検索します。

5.9.2.2 ECIDとトランザクション操作間の対応

トランザクションがどのように定義およびデプロイされているかに応じて、含まれているメッセージに1つ以上のECIDがある場合があります。ECIDとトランザクション・メッセージ間のマッピングを理解することが重要です。この項では2つの可能性について説明します。

- 複数のトランザクション定義、1つのECID
A→B→C→D→というコール・チェーンについて考えます。ABCを含むトランザクションXおよびCDEを含むトランザクションYを定義した場合、単一の呼出しから発生したXのインスタンスおよびYのインスタンス内のメッセージは、同じECIDを持ちます。

- 複数のECID、1つのトランザクション
トランザクションXにコール・チェーンA→B→Cが含まれており、BがOracle以外のプラットフォームで実行される場合、操作Bに対応するメッセージにはECIDはなく、AとCのメッセージは異なるECIDを持ちます。

- 特定の操作で、リクエストのECIDがレスポンスのECIDと異なる場合があります。

つまり、単一のトランザクションに複数のECIDがあること(またはその逆)は何かが誤っていることを意味するわけではなく、操作フローおよび呼出し境界に関する重要な情報が提供されます。

5.9.2.3 「インスタンス診断リクエスト」ビューへのアクセス

指定したECIDに関する情報が表示される「インスタンス診断リクエスト」ビューには、次の場所からアクセスできます。

- 「トランザクション・サマリー」タブ。(グラフまたはグリッド・ビューで)操作を右クリックし、ドロップダウン・リストから「インスタンス診断リクエスト」を選択します。

- サービス、エンドポイント、論理操作、物理操作またはトランザクションの「メッセージ・ログ」タブ。行を右クリックし、ドロップダウン・リストから「インスタンス診断リクエスト」を選択します。

- 「トランザクション・インスタンス・インスペクタ」。(グラフまたはグリッド・ビューで)操作を右クリックし、ドロップダウン・リストから「インスタンス診断リクエスト」を選択します。

- メッセージ検索ログ・ツール。メッセージ行を右クリックし、ドロップダウン・リストから「インスタンス診断リクエスト」を選択します。

「インスタンス診断リクエスト」ページに、指定したECIDの情報が表示されない場合があります。これは、JVM監視ツールのデフォルトのサンプル率がステップ期間よりも長く、指定したECIDがサンプル期間外に実行された可能性があります。

「インスタンス診断リクエスト」ページには、指定したECIDを持つリクエスト・ステップが実行されたJVMのリストが表示されます。各JVMに対して、次の詳細が表示されます。

- リクエストが実行された1つ以上のターゲットJVM。
リクエスト・ステップのRID (関係ID)が異なる場合、JVMは同じECIDで複数回表示される可能性があります。(RIDは、現在のステップの実行とリクエスト全体の実行との関係を表す連続的な数字です。)

- リクエストの開始時間および期間。

- リクエスト名、リクエスト内の個別のステップ(jsp、EJB、DBなど)。

- JVMによるCPUおよびメモリーの使用。

- ガベージ・コレクション統計(GCメジャー/マイナー)。

「インスタンス診断リクエスト」ビューの最下部に表示される棒グラフには、リクエストの期間内に取得された各JVMスナップショットのスレッドの状態が表示されます。色ごとに様々なスレッドの状態が表され、色分けは右側に表示されます。

棒グラフの任意の棒をクリックして、指定したスレッドおよびスレッド・スタックの詳細を示すペインを表示できます。

「リクエスト集計」タブには、トランザクションに関連する情報は含まれていません。

「インスタンス診断リクエスト」ページには、様々な方法でアクセスできます。たとえば、特定の操作で異常に時間がかかっていることに気付き、そのランタイム・コンテキストの詳細が必要になったとします。その操作にECIDがある場合、「インスタンス診断リクエスト」ページにドリルして詳細を取得できます。また、外部ソースからECIDを取得し、このECIDを持つメッセージがトランザクションに参加しているかどうかを確認します。メッセージ・ログ検索ツールを使用して、このECIDに関連付けられたすべてのメッセージを検索します。メッセージを見つけたら、対応するサービスおよび操作を確認し、関連インスタンスを表示して、当該のメッセージを含んでいたトランザクション・インスタンスを見つけることができます。

5.9.3 JVMDビューおよびRIDビューへのアクセスの有効化

注意:
JVMDがインストールされているマシンが完全修飾ドメイン名(FQDN)によってEnterprise Managerインスタンスで認識されている場合のみBTMからJVM診断にアクセスできます。マシンが短い形式(server1.oracle.comではなくserver1など)でEMに検出/登録されている場合、その特定のサーバーのJVM診断にアクセスできません。FQDNを持つマシンのJVM診断へは引き続きアクセスできます。

「JVM診断」ビューおよび「インスタンス診断リクエスト」ビューへのアクセスを有効にするには、次のことを実行する必要があります。

- 監視対象のサービスをホストしているすべてのノードにJVMDエージェントをインストールします。

- JVMDマネージャをEMにデプロイします。

- 監視対象のサービスをホストしているすべてのノードにBusiness Transaction Managementオブザーバをインストールします。(トラフィックを監視できる場合は、すでにそうなっています。)

- RIDのみ: インスタンス・ロギングを有効にします。メッセージ・コンテンツにアクセスするには、メッセージ・コンテンツ・ロギングも有効にする必要があります。

- 次に説明するように、EMコンソールにアクセスするようにBusiness Transaction Managementを構成します。

注意:
ECID情報は、JVMDエージェントのインストールまたはEMコンソールへの接続の構成を行っていなくてもBusiness Transaction Managementコンソールに表示されますが、これらの前提条件を満たしていないと、指定したECIDの「インスタンス診断リクエスト」ビューを開くことはできません。

EMコンソールへの接続

次の手順では、EMコンソールへの接続方法について説明します。これは、「JVM診断」ページおよび「インスタンス診断リクエスト」ページへのドリルダウンを有効にするために必要です。

1. ナビゲータから「システム・サービス」を選択します。

2. 「AP_Sphere_Service」エントリを見つけて選択します。

3. 「管理」→「設定データの編集: AP_Sphere_Service」を選択します

4. 「XMLの編集」ボタンをクリックします。

5. XMLドキュメントの下部までスクロールし、「emgcURL」要素を見つけます。

6. EMコンソールのベースURLが含まれるように、このXML要素を編集します。たとえば、EMコンソールがhttps://adc2101158:4473/emで実行されている場合は、https://adc2101158:4473を入力し、編集したエントリは次のようになります。

<pfx6:emgcURL>https://adc2101158:4473</pfx6:emgcURL>

ネームスペース接頭辞はpfx6以外の場合もありますが、XMLテキストに表示された値を使用します。

7. 「適用」ボタンをクリックして、変更を保存します。

「JVM診断」コンソールにアクセスするときは、そのログイン情報を入力する必要があります。シングル・サインオンはサポートされていません。

5.10 トランザクションに関する情報の取得

トランザクションを定義すると、詳細領域のタブを使用して、トランザクションに適用されているポリシー、条件およびプロパティに関する情報を取得できます。トランザクションのプロファイルを表示することもできます。場合によっては、タブに表示されている要素の定義またはステータスを変更することもできます。

5.10.1 プロファイル情報の取得

「トランザクション」ビューの「プロファイル」タブを使用して、トランザクションのマップやその定義を確認します。

「プロファイル」タブでは、本質的には「変更」メニューから「TxNameの編集」を選択してトランザクション定義を表示した場合に表示されるのと同じ情報が提供されます。かわりに「プロファイル」タブを選択すると、他のタブまたはビューへの切替えが容易になり、意図しない変更が防止され、次の3つの追加情報が提供されます。

- 定義の最終変更日

- トランザクションに定義されたユーザー属性

- CLIコマンドでトランザクションを特定する場合に必要になることがあるトランザクション識別子

5.10.2 ポリシー情報の取得

「ポリシー」タブを使用して、トランザクションに関連付けられたポリシーに関する情報を表示します。

タブには、適用されるポリシーに関する情報がデフォルトで表示されます。フィルタ制御を使用して、変更されたポリシー、無効になったポリシー、保留中のポリシー、拒否されたポリシーおよび適用されなかったポリシーを表示できます。

適用されたポリシーの名前は、ツリー・ビューの「名前」列に表示されます。ポリシー・ノードを展開すると、次の情報が表示されます。

- ポリシー・ステータス詳細は、ポリシーの適用で生じる問題をリストします。

- 監視対象オブジェクト・タイプは、ポリシーの適用先ターゲットを指定します。

- 「場所」は、ターゲット・エンドポイントのアドレスを指定します。

- 管理の仲介は、ポリシーを適用するBusiness Transaction Managementエージェントを指定します。

「ポリシー」タブのポリシー名をダブルクリックすると、選択したポリシーのアラート、プロファイルおよびターゲット情報の表示に使用できる新しいウィンドウが開きます。

5.10.3 条件定義の取得および変更

「トランザクション」ビューの「条件」タブを使用して、トランザクションに対して定義した条件を表示します。このタブでは、次の操作を行うことができます。

- フォルト監視のステータス(有効または無効)を表示および変更します。

- 条件の定義とステータスを表示します。

- 条件ごとに表示される「編集」ドロップダウン・リストを使用して、条件定義の変更、条件の複製または条件の削除を行います。

5.10.4 プロパティ情報の取得

「トランザクション」ビューの「プロパティ」タブを使用して、指定したトランザクションに含まれるメッセージに定義されたすべてのプロパティのリストを表示します。このタブには、プロパティのリスト以外に、次の内容に関する情報が表示されます。

- プロパティが定義されるサービスと操作。

- 操作のフェーズ(リクエスト/レスポンス)。

- プロパティ値のデータ型。

- 値の大文字/小文字の区別。

- コンシューマにマップされるかどうか(左側の人型アイコンで示される)、コンシューマにマップされるどの属性に関連付けられるか。

- プロパティを作成したときに値を指定した場合の説明。

リストされる各プロパティの「編集」ドロップ・ダウン・リストで、プロパティ定義を変更、複製または削除できます。

5.11 トランザクションのトラブルシューティング

この項では、トランザクションの使用における問題を解決するのに役立つ情報を提供します。

トランザクションのパフォーマンス監視が予期したとおりに機能しない場合、考慮する必要がある最も一般的な2つの問題は次のとおりです。

- 結果を予期している対象期間内に、サービスにトラフィック・フローがあったかどうか。Business Transaction Managementでは、非アクティブなサービスのパフォーマンスは測定できません。

- 測定または分析が依存する機能が有効になっているかどうか。機能とは、コンシューマ・セグメンテーション、インスタンス・ロギング、メッセージ・コンテンツ・ロギングおよび最も基本的にはトランザクション監視のことです。トランザクションの「プロファイル」タブを確認して、目的の機能が有効であることを確認します。

トランザクションの監視が有効な場合、結果を得ようとする期間にトラフィック・フローがある場合、および必要な機能がアクティブ化されている場合は、完全で正しいデータが表示されます。そうならない場合は、次の考えられる問題と解決方法の説明を参照してください。

注意:
問題に関係している可能性がある情報について、「過去1時間のアラート」→「システム・アラート」を確認してください。

トランザクションを作成できない

Business Transaction Managementではトランザクション定義を検証できず、定義済トランザクションを作成できません。次の原因が考えられます。

- トランザクション内の操作の名前に特殊文字が含まれています。Business Transaction Managementではピリオドが含まれた名前は処理できますが、その他の特殊文字では問題が発生する場合があります。

- 別のトランザクションによって使用されている開始操作を選択しました。

- 開始操作とは異なる終了操作を選択しましたが、開始メッセージと終了メッセージを相関させる手動キーを指定しませんでした。

- 接続されていないフローがトランザクション定義内にあります。

- 開始操作と終了操作が異なっており、異なるメッセージ・ログ・データベースが使用されています。

トランザクションが無効になっている

トランザクションの監視を明示的には無効にしていないが、測定が収集されず、ロギングおよび条件処理が無効です。「プロファイル」タブに表示されるステータスを確認すると、トランザクションのステータスが無効またはシステム無効です。

これには様々な理由があります。

- トランザクション定義でキーとして使用されていたプロパティを変更または削除しました。

- トランザクション定義に含まれていたサービスまたは操作を削除しました。

- トランザクション定義に含まれていたサービスを無効にしました。

- 開始操作と終了操作が異なるトランザクションについて、1つ以上の開始/終了操作エンドポイントが同じメッセージ・ログ・データベースを共有しなくなっています。

- コンシューマ・セグメンテーションに使用されているプロパティを削除するか、ユーザーがコンシューマ・セグメンテーションに使用されているコンシューマ・プロパティを編集してコンシューマ・マッピング情報を削除します。

パフォーマンス測定が不完全または不正確である

これには様々な理由があります。

- 「最大トランザクション期間」に対して指定した値が、トランザクションにとって短すぎます。

- 1つの操作を共有する複数のトランザクションを定義しました。トランザクションそれぞれの合計レスポンス時間は正確ですが、共有操作へのリンク測定では各コール元からの呼出しの合計が表示されます。トランザクションABCおよびYBCを示す次の図では、BCリンクのレスポンス時間は合計になります。

- トランザクションの実行が終了していません。

- Business Transaction Managementでは、レスポンス時間を定義するために開始操作と終了操作が使用されます。これらの操作は「最大トランザクション期間」に対して定義された期間内に1回のみコールされると想定されます。また、その期間に表示されるコンテンツは一意であることも想定されます。これらの要件が満たされない場合、トランザクションに対して生成されるパフォーマンス測定は正確でない場合があります。

セグメント化された情報がない

コンシューマ・セグメンテーションが有効ですが、コンシューマの情報が収集されません。

- コンシューマ・セグメンテーションに使用されるプロパティが削除または変更されたため、コンシューマにマップされなくなっているかどうかを確認します。

- トランザクション定義を以前のリリースからインポートした場合、コンシューマ・マッピング情報はインポートされません。トランザクション定義を変更してマッピング情報を再作成する必要があります。

ログに記録されたインスタンスまたはメッセージに予期した情報が含まれていない

ログに記録されたインスタンスについて、予期した情報に関連付けられているプロパティが削除されたかどうかを確認します。

1つのトランザクションのすべてのメッセージが同じデータベースに記録される必要があります。トランザクションがファイアウォールを越えるため、この要件が満たされない場合があります。この場合、Business Transaction Managementサポートの支援が必要になる場合があります。

ログに記録されたメッセージの問題については、ログ・ポリシー設定を確認し、その内容をBusiness Transaction Managementサポートに報告する必要がある場合があります。

条件が無効になっている

条件定義で使用されるプロパティが変更または削除されたかどうかを確認します。

インスタンス・ロギングを無効にしており、それに依存するトランザクションに対して有効な条件が少なくとも1つあります。

条件によってアラートがトリガーされない

条件を評価する必要があるときにトランザクション・サーバーが停止していました。サーバーのステータスを確認してください。

欠落メッセージ条件が誤ってトリガーされる

欠落メッセージ条件がトリガーされますが、メッセージは存在しており、収集されています。これは、監視処理が特に遅く、トランザクションの存続時間が期限切れになった後に欠落メッセージ条件が評価された場合に発生する可能性があります。まれな状況です。

5.11.1 ログ・ポリシー設定の表示

トランザクションの記憶域設定に基づいて、Business Transaction Managementによってトランザクションごとにログ・ポリシーが作成され、トランザクションの監視およびログ・メッセージの保存の際にこのポリシーが参照されます。ログ・ポリシー設定の一部は、トランザクションを定義するときに指定した情報から導出されます。次の表に、ログ・ポリシー設定とトランザクション定義ランタイム設定の間の対応を示します。

ログ・ポリシー・フィールド

トランザクション定義ランタイム設定

説明

保証格納期間

個々のメッセージを維持
デフォルト: 24時間

Business Transaction Managementで、アセンブルしていないメッセージをトランザクション・サーバーのデータベースに維持する必要がある時間。したがって、これらのメッセージはアセンブリ可能です。

切替え間隔(分)

メッセージ・ログの切替え
デフォルト: 720分

トランザクションを支援するログ・ポリシーの切替え間隔を指定します。切り替えられたメッセージは、「個々のメッセージを維持」に対して定義された時間、保持されます。

テキスト索引のメッセージ・コンテンツ

テキスト索引のメッセージ・コンテンツ

キーワードベースの検索(フリー・テキスト検索)の高速化を可能にするテキスト索引をOracleデータベースに作成します(追加記憶域と初期処理が必要になります)。

ログ・ポリシーの名前は、「TransactionNameのシステム生成ログ・ポリシー」になります。このポリシーを表示する必要があるのは、ロギングの問題をトラブルシューティングするときのみです。

トランザクションのログ・ポリシー設定を表示するには

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

2. メイン領域で、「TransactionNameのシステム生成ログ・ポリシー」エントリを選択します。

3. タブ領域が開いていない場合は開き、「プロファイル」タブを選択します。トランザクションのログ・ポリシーの設定が表示されます。

6 サービスの監視

この章では、Business Transaction Managementを使用してサービスを監視する方法について説明します。監視に使用するインスツルメントの意味および「上位10件のサービス」ダッシュボードについて説明します。内容は、次のとおりです。

- サービスの監視方法

- 「上位10件のサービス」ダッシュボード

- インスツルメントについて

6.1 サービスの監視方法

この項では、サービスを監視する方法をリストします。最も一般的な方法から最も特定的な方法への順でこれらの監視タスクをリストし、タスクごとに、監視を実行できるビューへのナビゲート方法を説明します。

監視するには:

- サービスの全体的なステータス。稼働中/停止しているサービスの合計数とSLA警告/失敗
「ダッシュボード」→「操作状態サマリー」→「サービス」にナビゲートします。

- 最も負荷が高いサービス
「ダッシュボード」→「上位10件のサービス」にナビゲートします。

- すべてのサービス、エンドポイントおよび操作(稼働中/停止ステータス、SLA準拠およびパフォーマンスを含む)にわたる現在のサマリー情報

1. 「エクスプローラ」→「サービスからエンドポイントへ」にナビゲートするか、または「エクスプローラ」→「サービスから操作へ」にナビゲートし、メイン領域を参照します。
「サービスからエンドポイントへ」では物理的なビューが提供され、これを使用するとサービスからエンドポイント、さらに物理的な操作へとドリルダウンできます。「サービスから操作へ」では論理的なビューが提供され、これを使用するとサービスから物理的な操作へとドリルダウンできます。

2. メイン領域で、目的のサービスまたはエンドポイントを選択します。

3. 「サマリー」タブを選択します。

- 特定のサービス、エンドポイントまたは操作の現在の詳細なパフォーマンスおよび使用状況
特定のサービス、エンドポイントまたは操作→「分析」タブにナビゲートします。

- 特定のサービス、エンドポイントまたは操作の現在の詳細なSLA準拠
特定のサービス、エンドポイントまたは操作にナビゲートし、「コンプライアンス」タブをクリックします。

- 特定のサービス、エンドポイントまたは操作に影響する問題の最近の履歴
特定のサービス、エンドポイントまたは操作にナビゲートし、「アラート」タブをクリックします。

- ログ・メッセージ
特定のサービス、エンドポイントまたは操作にナビゲートし、「メッセージ・ログ」タブをクリックします。メッセージ・ロギングは、サービス・エンドポイントがトランザクションに含まれ、メッセージ・ロギングがそのトランザクションに対して有効になっている場合にのみ使用できます。

6.2 「上位10件のサービス」ダッシュボード

「上位10件のサービス」ダッシュボードでは、システム内で最も負荷が高いサービスをすばやく特定し、その状態を評価できます。

上位10件のサービスを表示するには、「ダッシュボード」→「上位10件のサービス」を選択します。

ダッシュボードには4つの表が表示されます。各表は特定のインスツルメントに基づき、そのインスツルメントの上位10件(稼働時間は例外的に下位10件)の測定値を持つサービスがリストされます。

サービスに対して表示されるデータのデフォルトの評価期間は7日間です。評価期間を変更するには、一番上に表示されている「時間間隔」コントロールをクリックします。期間は、過去1日間、過去1時間または過去10分間に変更できます。

「上位10件のサービス」ダッシュボードには、次の特性を備えた10件のサービスをリストする表が表示されます。

- 最高スループット(「最大の負荷」表)

- 最小稼働時間(「稼働中の問題」表)

- 最も遅い平均レスポンス時間(「最遅平均レスポンス時間」表)

- 最多フォルト数(「最多フォルト」表)

各表には、インスツルメントの数値とチャートが表示されます。カーソルをチャートに合わせて、特定の時間区分の詳細情報を表示します。

詳細な情報および分析を参照するには、トランザクションまたはサービスをダブルクリックしてタブ領域を表示し、「分析」タブを選択します。

6.3 インスツルメントについて

Business Transaction Managementでは、様々なインスツルメントを使用して、ビジネス・トランザクションとその基礎となるサービスや操作のパフォーマンスおよび使用状況の特性を測定します。これらのインスツルメントは、対話形式で監視する管理コンソールの様々な部分に表示されます。これらのインスツルメントの大部分は、サービス・レベル合意(SLA)を定義する基礎としても使用できます。

これらのインスツルメントが作用する期間は、評価期間(SLAの場合)または表示期間(監視コンソールの対話型監視の場合)のいずれかです。次の説明では、インスツルメントが使用されるコンテキストに応じて評価期間または表示期間(あるいはその両方)を表すために、期間という用語を使用します。たとえば現在のコンプライアンス・ステータスなどの一部のインスツルメントでは、現在の値のみが表示されます。

6.3.1 トランザクション・インスツルメント

トランザクションの監視では、次のインスツルメントを使用できます。

平均レスポンス時間

トランザクションの完了にかかった平均時間。トランザクション・インスタンスごとに、インスタンスの開始メッセージが監視された時点から終了メッセージが監視された時点までの時間がインスツルメントによって測定されます。インスツルメントは、期間内に監視されたすべてのインスタンスのレスポンス時間の実行平均を保持します。条件アラートの発生に関係なく、すべての完了済インスタンスがレスポンス時間にカウントされます。

その期間の間、トランザクションが監視されなかった場合、インスツルメント値は「-」に設定されます。レスポンス時間はミリ秒で測定されます。

最大レスポンス時間

トランザクションの完了にかかった最大時間。インスツルメントは、期間内に監視されたすべてのトランザクション・インスタンスのうち最も長い単一レスポンス時間を記録します。

完了済トランザクション

期間内に完了したトランザクション・インスタンスの数。開始と終了の両方のメッセージが観察されれば、条件アラートの発生に関係なく、インスタンスは完了したとみなされます。ただし、終了メッセージがレスポンス・フェーズ(submit.responseなど)にあると定義されている場合に終了操作が失敗すると、終了メッセージが存在することはないため、そのインスタンスはカウントされません。

完了済トランザクション率

期間内の1時間に完了したトランザクション・インスタンスの数。このインスツルメントは完了済トランザクション・インスツルメントからその測定を導出します。

開始済トランザクション

期間内に開始したトランザクション・インスタンスの数。インスタンスは、その開始メッセージが監視されたときに、開始されたとみなされます。

開始済トランザクション率

期間内の1時間に開始したトランザクション・インスタンスの数。このインスツルメントは開始済トランザクション・インスツルメントからその測定を導出します。

条件アラート

期間内にトランザクションで生成された条件アラートの数。

条件アラート率

期間内の1時間にトランザクションで生成された条件アラートの数。このインスツルメントはトランザクション条件アラート・インスツルメントからその測定を導出します。

現在のコンプライアンス・ステータス

トランザクションの現在のコンプライアンス・ステータス。

違反アラート

期間内にトランザクションによって発生したSLA違反または警告の数。

6.3.2 サービスおよび操作のインスツルメント

サービス、エンドポイントおよび操作の監視では、次のインスツルメントを使用できます。

平均レスポンス時間(サービス、エンドポイントおよび操作)

サービスまたは操作がリクエストに応答するために要した時間の平均。リクエストごとに、サービスがリクエストを受信した時点から対応するレスポンスをクライアントに送信した時点までの時間が、インスツルメントによって測定されます。インスツルメントは、期間内に受信されたすべてのメッセージのレスポンス時間の実行平均を保持します。

正常に処理されたリクエストのみがレスポンス時間にカウントされます。フォルトのレスポンス時間はこの測定の計算には含まれません。レスポンス時間は、操作ごとに個別に測定されます。サービスのレスポンス時間は、そのすべての操作の平均レスポンス時間です。この平均は、各操作で処理されたメッセージの数に応じて重み付けされます。

その期間の間、リクエストが監視されなかった場合、インスツルメント値は「-」に設定されます。レスポンス時間はミリ秒で測定されます。

最大レスポンス時間(サービス、エンドポイントおよび操作)

サービスまたは操作がリクエストに応答するために要した時間の最大値。インスツルメントは、期間内に受信したすべてのリクエストのうち最も長い単一レスポンス時間を記録します。

リンクの平均レスポンス時間

アウトバウンド・リクエストに対する平均レスポンス時間。たとえば、orderServiceでは一部のクライアントからのリクエストを受信し、その結果としてcreditCheckServiceにリクエストを送信すると仮定します。この場合、orderServiceは、creditCheckServiceに対するクライアントとして動作します。レスポンス時間は、クライアントとして動作するサービスの視点から測定されます。つまり、クライアント・サービスがリクエストを送信した時点から、レスポンスを受信した時点までが測定され、これは、ネットワーク遅延が存在する場合には、それがレスポンス時間に含まれることを意味します。

正常に処理されたリクエストのみがレスポンス時間にカウントされます。フォルトのレスポンス時間はこの測定の計算には含まれません。その期間の間、リクエストが監視されなかった場合、インスツルメント値は「-」に設定されます。レスポンス時間はミリ秒で測定されます。

トラフィック

期間内にサービスまたは操作が受信したリクエストの数。トラフィック・カウントは、スループットにフォルト・カウントを足した数になります。トラフィック・カウントは、操作ごとに個別に測定されます。サービスのトラフィック・カウントは、そのすべての操作の合計のトラフィック・カウントになります。

スループット

期間内にサービスまたは操作が正常に受信、処理および応答したリクエストの数(つまり、レスポンスの数)。フォルトを生成したメッセージは、スループット・インスツルメントではカウントされません。スループットは、操作ごとに個別に測定されます。サービスのスループットは、そのすべての操作の合計のスループットになります。

スループット率

期間内の1時間に正常に処理されたリクエストの数。このインスツルメントはスループット・インスツルメントからその測定を導出します。

リンク・スループット

期間内に正常に受信、処理および応答された別のサービスに対するアウトバウンド・リクエストの数(つまり、インバウンド・レスポンスの数。サービスからサービスへのコールの説明は、リンクの平均レスポンス時間インスツルメントを参照してください)。

フォルト

期間内にサービスまたは操作によって生成されたフォルトの数。フォルト・カウントは、操作ごとに個別に測定されます。サービスの全体的なフォルト・カウントは、そのすべての操作の合計のフォルト・カウントになります。

フォルト率

その期間の1時間に生成されたフォルトの平均数。このインスツルメントはフォルト・インスツルメントからその測定を導出します。

フォルトの割合

期間内にフォルトを発生させたメッセージの割合。このインスツルメントはフォルトおよびトラフィック・インスツルメントからその測定を導出します。

リンク・フォルト

期間内に別のサービスに対するアウトバウンド・リクエストによって生成されたフォルトの数(サービスからサービスへのコールの説明は、リンクの平均レスポンス時間インスツルメントを参照してください)。

現在のコンプライアンス・ステータス

選択したオブジェクトの現在のコンプライアンス状態。

違反アラート

期間内にサービスまたは操作によって発生したSLA違反または警告の数。

違反アラート%

期間内にサービスまたは操作がSLA違反または警告の状態になった時間のパーセンテージ。

失敗アラート

特定の期間における失敗違反のカウント。

警告アラート

特定の期間における警告違反のカウント。

稼働時間

エンドポイントのコンテナが定期的なpingメッセージに対して正常に応答している時間のパーセンテージ。稼働ステータス・チェックに使用する方法の指定方法は、configureAlivenessCheckコマンドを参照してください。

7 コンシューマの使用

この章では、コンシューマのサービス使用を反映したパフォーマンス結果を表示する方法について説明します。コンシューマ・セグメンテーションの設定方法、コンシューマの作成方法、コンシューマへのメッセージのマップ方法およびコンシューマベースのパフォーマンス情報を表示および管理する方法について説明します。内容は、次のとおりです。

- コンシューマについて

- コンシューマへのメッセージのマッピング

- コンシューマの監視

- コンシューマの追加および削除

- コンシューマ名の編集

- コンシューマ・ラベルのカスタマイズ

7.1 コンシューマについて

個別のトランザクション、サービスおよびエンドポイントのパフォーマンスに基づいてパフォーマンス結果を表示する以外に、Business Transaction Managementではビジネスにとって意味のある条件でパフォーマンス結果を表示できます。サプライヤ、ユーザー、再販業者または顧客といったビジネス基準によってセグメント化されたトランザクション・パフォーマンスを表示できます。また、この情報は、当該のオブジェクトが一連の異なるトランザクションに参加している場合でも表示できます。この目的のために、Business Transaction Managementでは、自分にとって重要な基準を使用してパフォーマンス・データをセグメント化するために定義できるコンシューマ・ビジネス・オブジェクトが用意されています。これにより、ビジネス・オブジェクトを監視して目的が満たされていることを確認できます。次に例を示します。

- 指定したコンシューマによってセグメント化されたパフォーマンスを示すカスタム・グラフを表示できます。

- 指定したコンシューマのシステム・パフォーマンスが定義済のターゲットを満たしていない場合に、Business Transaction Managementでアラートを生成できます。

コンシューマとは、Business Transaction Managementのコンシューマ・ビジネス・オブジェクトで、個々のコンシューマは、環境に対して定義したコンシューマ・ビジネス・オブジェクトのインスタンスです。コンシューマというデフォルト名は、このビジネス・オブジェクトがトランザクションの初期クライアントである可能性があることを意味していますが、受注が発生した国または市や会社名などである可能性もあります。この項では、ここで説明したように幅広い範囲の基準を示す可能性があるという了解のもとで、コンシューマというデフォルト名を使用します。

実際のセグメンテーション基準をより明確にするために、Business Transaction Managementの管理者は、管理コンソールのフィールド、ボタンおよびリンクに表示されるコンシューマ・ラベルをカスタマイズできます。たとえば、管理者はラベルを「コンシューマ」から「部門」、「サプライヤ」などの内容を表す用語に変更できます。

次の各項では、コンシューマの設定方法について説明します。

- コンシューマ・セグメンテーションの設定

- コンシューマの作成

- デフォルトのコンシューマ名の変更

7.1.1 コンシューマ・セグメンテーションの設定

最も単純なケースでコンシューマ別のパフォーマンス・セグメンテーションを取得するには、次のことを実行する必要があります。

1. トランザクションの開始操作で、コンシューマを一意に識別するリクエスト・メッセージ要素を値として持つプロパティを作成します。ID番号、社会保障番号、名前、電子メール・アドレスなどを使用できます。コンシューマが人ではない場合は、会社名や会社を識別するコードなどを使用できます。(プロパティ値に指定する情報は、単一のメッセージ要素、xpath式またはメッセージ・ヘッダー内のコンテンツに基づくことができます。)

2. このプロパティをコンシューマ・ビジネス・オブジェクトのコンシューマ属性にマップします。このマッピング・プロセスは、コンシューマへのメッセージのマッピングと呼ばれます。

3. トランザクション定義でコンシューマ・セグメンテーションを有効にします。

次の図に、emailというプロパティ(トランザクションの開始メッセージのrequest.submit.order.customerEmail要素に関連付けられている)とビジネス・オブジェクトのデフォルト属性Consumer Nameの間の単純なマッピングを示します。

トランザクションに対してコンシューマ・セグメンテーションが有効な場合、トラフィックのフローが開始されると、Business Transaction Managementによって測定結果の収集の一部としてこのトランザクションのemailプロパティの値が検査されます。この例では、プロパティ値が123hop@gmail.comであるとします。

- 名前が123hop@gmail.comである既存のコンシューマが見つかった場合は、そのコンシューマに対して測定が記録されます。

- その名前のコンシューマが見つからない場合は、コンシューマが作成され、名前としてプロパティの値が割り当てられ、そのコンシューマに対して測定が記録されます。

特定の1種類のコンシューマを監視し、コンシューマ名としてプロパティの値を使用できる単純なケースには、Business Transaction Managementでデフォルトで提供されるビジネス・オブジェクトで十分です。現実には、より複雑な状況を処理する必要がある場合があります。そのために、カスタム属性を追加することでコンシューマ・ビジネス・オブジェクトの定義をカスタマイズできます。これらの属性を使用して、コンシューマが異なるプロパティによって識別されていても、Business Transaction Managementで同じコンシューマが認識されるようにすることができます。

たとえば、複数のトランザクションを監視する必要があり、各トランザクションで関連するコンシューマが異なる方法で識別される場合、何が起きるでしょうか。一方のトランザクションではコンシューマは電子メール・アドレスで識別され、他方では社会保障番号で識別されます。

次の図に、2つのトランザクションTx1とTx2を示します。Tx1にはemailプロパティにマップされたcustomerEmail要素があり、Tx2にはSSNumberプロパティにマップされたcustID要素があります。Business Transaction Managementによって両方のトランザクションが監視され、コンシューマがemailプロパティとSSNumberプロパティのどちらによって識別されていても、同じコンシューマが関係していることが認識されるようにします。そのためには、2つのカスタム属性をコンシューマ・ビジネス・オブジェクトに追加し、各プロパティを対応する属性にマップする必要があります。

この例のために、これらのトランザクションに関係するすべてのコンシューマがすでに作成されているとします。トラフィックのフローが開始されると、Business Transaction Managementによって、メッセージが検出された際に表示される各プロパティの値が検査されます。既存のコンシューマに関連付けられた電子メール・アドレスまたは社会保障番号が見つかった場合は、そのコンシューマに対して測定が記録されます。これにより、指定したコンシューマのパフォーマンス情報を確認できます。これは、コンシューマが参加しているすべてのトランザクションでのパフォーマンスの集計です。

このより複雑なケースでは、コンシューマ・セグメンテーションの設定には次の手順が含まれています。

1. 手順2で作成するプロパティに対応するカスタム属性をコンシューマ・ビジネス・オブジェクトに追加します。

2. コンシューマ別にセグメント化するトランザクションごとに、コンシューマを一意に識別するリクエスト・メッセージ要素を値として持つプロパティを作成します。

3. 各プロパティを対応するビジネス・オブジェクト・カスタム属性にマップします。

4. トランザクション定義でコンシューマ・セグメンテーションを有効にします。

(トランザクションのコンシューマ・セグメンテーションを定義するときに手順2から4を一度に実行できます。)

7.1.2 コンシューマの作成

Business Transaction Managementでは、コンシューマは次の方法の1つ以上を使用して作成されます。

- コンシューマ・セグメンテーションが設定してある場合は、Business Transaction Managementによって存在しないコンシューマのメッセージが見つかるとコンシューマが自動的に作成されます。

- 「作成」→「コンシューマ」を選択してコンシューマ名および属性に値を指定したときに入力した情報に基づきます。

- importBusinessObjectコマンドを使用して入力した情報に基づきます。

コンシューマを手動で作成する場合は、後の2つのオプションと同様に、コンシューマ監視はコンシューマ・セグメンテーションを設定した後にのみ開始されます。

7.1.3 デフォルトのコンシューマ名の変更

デフォルトでは、検出されたコンシューマは、コンシューマをマップしたメッセージ・プロパティの値に従って命名されます。たとえば、電子メール・アドレスを保持するプロパティを使用する場合、管理コンソールに表示されるコンシューマの名前はコンシューマの電子メール・アドレスです。プロパティの値がユーザーの氏名の場合は、その名前が管理コンソールに表示されます。コンシューマ・プロファイルを編集することによって、コンシューマに対して表示される名前を編集できます。ユーザー名を表示するために使用される書式の組合せが表示される場合、これは、一部は手動で作成され(実際の名前が割り当てられ)、その他は自動的に追加され、コンシューマにメッセージをマップするために使用されたプロパティの値が割り当てられたことによる可能性があります。

デフォルトのコンシューマ名を変更する場合、セグメンテーションに使用されたプロパティに対応するビジネス・オブジェクトに属性を追加する必要があり、その属性にプロパティをマップする必要があることに注意してください。次の図では、Emailカスタム属性がemailプロパティにマップされています。その後、デフォルトのコンシューマ名を(コンシューマ・プロファイルを編集して)実際の名前に変更した場合、Business Transaction Managementでは引き続き、メッセージを確認してemailプロパティを評価したときにこのコンシューマの測定を収集しますが、「コンシューマ」ビューのメイン・ペインおよびコンシューマの「プロファイル」タブの「名前」フィールドには、指定した名前が表示されます。

7.2 コンシューマへのメッセージのマッピング

コンシューマは、目的の基準に基づいてトランザクション・パフォーマンスをセグメント化できるデフォルトのBusiness Transaction Managementビジネス・オブジェクトです。コンシューマへのメッセージのマッピングは、パフォーマンス情報をセグメント化するために使用する基準をシステムに指定する方法です。マッピング・プロセスでは、コンシューマを識別するプロパティを作成し、そのプロパティをコンシューマ・ビジネス・オブジェクトにマップします。続行する前に、7.1項「コンシューマについて」で詳細を確認してください。

メッセージをコンシューマにマップする前に、次のことを決定します。

- どのようなプロパティを作成する必要があるか。
選択するコンシューマは、ID番号や電子メール・アドレスなど、トランザクションの開始メッセージに含まれている情報によって一意に識別される必要があります。この情報はメッセージ要素またはヘッダー内に含まれています。

- 各プロパティを定義するために、どのようなメッセージ要素またはxpath式を使用するか。(わかりやすくするために、この手順の残りの部分ではこの要素またはヘッダーをConsumer_IDとします。)

- カスタム属性を追加することで、コンシューマ・ビジネス・オブジェクトをカスタマイズする必要があるか。これは、Business Transaction Managementでデフォルトのコンシューマ名を使用しない場合、または異なるトランザクションにわたってコンシューマを追跡しており、コンシューマが各トランザクションで異なる方法で表されている場合に実行する必要があることがあります。

メッセージをコンシューマにマップする基本的な手順は次のとおりです。

1. 必要に応じてコンシューマ・ビジネス・オブジェクトをカスタマイズして、追加のマッピング・オプションをコンシューマに指定します。

2. プロパティを作成するときに、次に説明するマッピング・オプションのいずれかを使用してプロパティをコンシューマにマップします。

このマッピングを完了し、セグメンテーションを有効にしてトラフィックを送信した後、「エクスプローラ」→「コンシューマ」ビューから、または「トランザクション」ビューの「分析」タブから、コンシューマ別にセグメント化されたトランザクション・パフォーマンス情報を表示できます。

7.2.1 コンシューマ・ビジネス・オブジェクトのカスタマイズ

コンシューマ・ビジネス・オブジェクトは、環境全体で確認されます。手動または自動で作成された各コンシューマは、コンシューマ・ビジネス・オブジェクトのインスタンスです。このオブジェクトの構造は、コンシューマの「プロファイル」タブで確認できます。7.1.1項「コンシューマ・セグメンテーションの設定」では、コンシューマ・ビジネス・オブジェクトに属性を追加する必要がある場合がある理由が説明されています。

属性をコンシューマ・ビジネス・オブジェクトに追加するには:

1. 「管理」→「データ・モデル属性の編集」を選択します。「データ・モデル属性の編集」ダイアログ・ボックスが開きます。

2. 「ビジネス・オブジェクト・カスタム属性」セクションまで下にスクロールし、「属性の追加」をクリックします。

3. 属性の「名前」および「タイプ」を指定します。

4. オプションで、属性の表示名を「フォーム・ラベル」フィールドで指定できます。この名前は、コンシューマの「プロファイル」タブで属性を識別するために使用されます。
デフォルトの表示名は「名前」フィールドの値です。

5. オプションで、属性を問い合せるための名前を「問合せラベル」フィールドで指定できます。この名前は問合せ式を構成する際に使用できます。デフォルトの問合せ名は「名前」フィールドの値です。

6. 手順2から5を繰り返して、さらに属性を追加します。

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

7.2.2 マッピング・オプション

プロパティの作成時またはトランザクションの作成時に、メッセージをコンシューマにマップできます。

Consumer_IDの値を保持するメッセージ・プロパティを作成し、プロパティをコンシューマ・オブジェクト上の属性にマップするには、次のことを実行します。

1. セグメント化するトランザクションの開始操作を選択します。

2. 「作成」→「メッセージ・プロパティ: operation_name」を選択します。

「メッセージ・プロパティ」ダイアログ・ボックスが開きます。

1. プロパティの「名前」を指定します。

2. 「プロパティ・ソース」で「メッセージ・コンテンツ」または「ヘッダー」を指定し、「Consumer_ID」を指定します。「ヘッダー」を指定した場合は、メッセージのフェーズ、ヘッダー名およびデータ型を指定できるダイアログが開きます。「コンテンツ」を指定した場合は、「メッセージから選択」リンクを使用して目的のメッセージ要素を選択します。

3. 「コンシューマ・マッピング」セクションで、「属性を通じてコンシューマにマップ」チェック・ボックスを選択し、マップ先のコンシューマ属性を選択します。これは、デフォルトの「コンシューマ名」属性またはコンシューマ・ビジネス・オブジェクトをカスタマイズしたときに作成した属性です。

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

7.3 コンシューマの監視

このトピックでは、コンシューマを監視する様々な方法について説明します。これらの監視タスクを詳細度の低いものから高いものへという順序で示します。タスクごとに、監視を実行できる場所と、より詳細な情報へのリンクを示します。

全般的には、コンシューマ別にセグメント化されたトランザクション・パフォーマンス情報が表示される2つのビューがあります。

- 「エクスプローラ」→「コンシューマ」ビュー: 「分析」、「アラート」、「SLA準拠」タブ

- 「トランザクション」ビュー: 「分析」タブのコンシューマ使用状況ペイン

異なるトランザクションに参加するコンシューマを定義した場合、そのコンシューマの「分析」タブおよびメイン・ビューに表示される情報には、コンシューマが含まれるすべてのトランザクションのパフォーマンス測定を集計した値が表示されます。

コンシューマを監視する前に、メッセージをコンシューマにマップし、コンシューマ別のセグメンテーションを有効にする必要があります。詳細は、7.2項「コンシューマへのメッセージのマッピング」を参照してください。

コンシューマ定義に関する情報を取得するには、「エクスプローラ」→「コンシューマ」ビューでコンシューマを選択し、「プロファイル」タブを選択します。このタブには、コンシューマ名、そのID (一部のCLIコマンドで有用)、コンシューマの作成時に入力した説明およびコンシューマ・ビジネス・オブジェクトに対して作成した属性が表示されます。

コンシューマを監視するには:

- SLA違反があるコンシューマの合計数
「ダッシュボード」→「操作状態サマリー」にナビゲートし、「コンシューマ」情報を検索します。

- コンシューマごとのトランザクション・パフォーマンスおよびトランザクション使用状況
「トランザクション」ビューで「分析」タブ、コンシューマ使用状況パネルにナビゲートし、トランザクションを選択します。

- 特定のコンシューマの詳細な現在のトランザクション・パフォーマンスおよびトランザクション使用状況

1. 「エクスプローラ」→「コンシューマ」ビューにナビゲートします。

2. メイン・ペインでコンシューマを選択します。

3. 「分析」タブを選択します。

4. 時間の経過に伴うパフォーマンスのグラフィック・レンディションについては、「トランザクション・パフォーマンス」を参照します。グリッド・ビューについては、「トランザクション使用状況」を参照します。

- コンシューマおよびIPアドレス別のセグメンテーション

1. 「エクスプローラ」→「コンシューマ」ビューにナビゲートします。

2. メイン・ペインでコンシューマを選択します。

3. 「分析」タブを選択します。「クライアント・アドレス別内訳」を参照します。

- コンシューマ別違反アラート

1. 「エクスプローラ」→「コンシューマ」ビューにナビゲートします。

2. メイン・ペインでコンシューマを選択します。

3. 「分析」タブを選択します。「違反アラート」を参照します。

- 特定のコンシューマの詳細な現在のSLA準拠

1. 「エクスプローラ」→「コンシューマ」ビューにナビゲートします。

2. メイン・ペインでコンシューマを選択します。

3. 「SLA準拠」タブを選択します。

- 特定のコンシューマのSLA違反の最近の履歴

1. 「エクスプローラ」→「コンシューマ」ビューにナビゲートします。

2. メイン・ペインでコンシューマを選択します。

3. 「アラート」タブを選択します。

7.4 コンシューマの追加および削除

Business Transaction Managementでは、コンシューマは次の方法の1つ以上を使用して作成されます。

- コンシューマ・セグメンテーションが設定してある場合は、Business Transaction Managementによって存在しないコンシューマのメッセージが見つかるとコンシューマが自動的に作成されます。

- importBusinessObjectsコマンドを使用して入力した情報に基づきます。

- 「作成」→「コンシューマ」を選択してコンシューマ名および属性に値を指定したときに入力した情報に基づきます。

この項では、この最後のオプションである、管理コンソールを使用してコンシューマを作成する方法について説明します。コンシューマを削除する方法についても説明します。

管理コンソールを使用してコンシューマを追加するには

1. 「作成」→「コンシューマ」を選択します。
「コンシューマの作成」ダイアログ・ボックスが開きます。表示されるコンテンツは、コンシューマ・ビジネス・オブジェクトをどのように定義したかによって異なります。定義したカスタム属性が「属性」領域に表示されます。

2. 内容を表す名前とノートを入力します。
「名前」フィールドの値は、管理コンソールでコンシューマの表示名として使用されます。

「ノート」フィールドの値に対してフィルタ処理を設定できます。

3. コンシューマ・ビジネス・オブジェクトに対して定義された属性の値を「属性」フィールドに入力できます。

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

管理コンソールを使用してコンシューマを削除するには

1. 「エクスプローラ」→「コンシューマ」ビューで、削除するコンシューマを選択します。

2. 「変更」→「consumer_nameの削除」を選択します。
コンシューマの削除ダイアログ・ボックスが開きます。

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

7.5 コンシューマ名の編集

コンシューマは、検出されてBusiness Transaction Managementスフィアに追加されるときに、コンシューマをマップしたメッセージ・プロパティの値に従って命名されます。たとえば、電子メール・アドレスを保持するメッセージ・プロパティにマップした場合、管理コンソールに表示されるコンシューマの名前はコンシューマの電子メール・アドレスです。

コンシューマの名前は、コンシューマ・プロファイルを編集することによって編集できます。

これは、コンシューマ・オブジェクトに対してカスタム属性を作成し、そのカスタム属性にメッセージ・プロパティをマップした場合にのみ実行する必要があります。そうしないと、そのコンシューマについてメッセージ・トラフィックがセグメント化されなくなります。詳細は、7.2項「コンシューマへのメッセージのマッピング」を参照してください。

たとえば、次のコンシューマ・プロファイルでは、「名前」フィールドを編集して、電子メール・アドレスが表示されているコンシューマの名前を入力できます。名前フィールドに入力した内容が、コンソールにコンシューマを表示するために使用される書式およびコンテンツになります。ただし、セグメンテーションに使用されるプロパティは「ユーザーID」属性にマップされている必要があり、これは電子メール・アドレスのままです。

コンシューマ・プロファイルを編集する別の理由として、ノートの追加があります。「ノート」フィールドの値を使用してフィルタ処理を設定できます。

コンシューマ・プロファイルを編集するには:

1. 「エクスプローラ」→「コンシューマ」ビューから、プロファイルを編集するコンシューマを選択します。

2. 「変更」→「プロファイルの編集: consumer_name」を選択します。
「プロファイルの編集: consumer_name」ダイアログ・ボックスが開きます。編集を行います。

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

7.6 コンシューマ・ラベルのカスタマイズ

必要なBusiness Transaction Managementアプリケーション・ロール: btmadmin。

管理コンソールで、「コンシューマ」という用語をデフォルトで使用するラベルのテキストをカスタマイズできます。たとえば、個人別ではなく部門別にサービス・レベルおよび使用状況を監視する場合があります。この場合、「コンシューマ」のかわりに「部門」という用語を使用するように管理コンソールでラベルを変更すると有用な場合があります。用語の単数形と複数形の両方を指定する必要があります。

変更したラベルは、ナビゲータ、「分析」ペインの名前、フィルタ・ツールなどで使用されます。

コンシューマ・ラベルを変更するには:

1. 「管理」→「データ・モデル属性の編集」を選択します。
「データ・モデル属性の編集」ダイアログ・ボックスが開きます。

2. 最下部までスクロールして「ビジネス・オブジェクト・ドメイン」セクションを見つけます。

3. 新しいラベルの単数形を「名前」フィールドに入力します。

4. 新しいラベルの複数形を「複数ラベル」フィールドに入力します。

5. 必要に応じて「説明」フィールドを編集します。

6. 「適用」をクリックします。

7. 「表示」メニューから「リフレッシュ」をクリックして、Webブラウザをリフレッシュし、変更の結果を確認します。

8 アラートの構成および表示

Business Transaction Managementでは、定義されたパフォーマンス標準に違反するか、指定した条件が満たされると、アラートが発生します。この章では、サービス・レベル合意と条件を定義および使用する方法について説明します。これらの強力なツールを使用すると、重要な局面でパフォーマンスを評価できます。

この章には次の項が含まれます:

- アラートについて

- サービス・レベル合意について

- サービス・レベル合意の定義

- SLAポリシーの使用

- SLA準拠の監視

- 「SLA準拠」タブ

- サービスまたはエンドポイントの停止時間のスケジューリング

- 条件について

- 条件の使用

- 条件アラート情報の表示

8.1 アラートについて

サービス、エンドポイントおよびトランザクションのパフォーマンスの進行中の監視以外に、特定のイベントが発生したときに、Business Transaction Managementでアラートが発生するようにできます。

Business Transaction Managementでは、次の複数のタイプのアラートが発行されます。

- サービス・レベル合意アラート(違反アラートやSLAアラートとも呼ばれる)は、エンドポイント、サービスまたはトランザクションに定義したパフォーマンスの標準からの差異が発生した場合に発行されます。これらの標準は、固定値、または履歴によって決定されるベースラインに基づきます。
パフォーマンスの標準は1つ以上のサービス・レベル合意ポリシーを使用して定義し、その後、エンドポイント、サービス操作またはトランザクションに適用します。

SLA違反アラートは、関連付けられたサービス、エンドポイント、操作またはトランザクション・インスタンスの「アラート」タブで、問合せ、フィルタおよび表示できます。過去1時間のSLAアラートは「過去1時間のアラート」→「SLAアラート」ビュー(ナビゲータから)を使用して表示します。また、アラートは操作サマリー・ダッシュボードにも表示されます。

この場合は、パフォーマンスが、SLAポリシーに設定された「警告値」しきい値を逸脱すると警告アラートが発行され、SLAポリシーに設定された「失敗値」しきい値を逸脱すると失敗アラートが発行されます。「警告値」はオプションです。

- 条件アラートは、条件が満たされると発行されます。
条件はトランザクションに対して作成され、トランザクション・インスタンス別の評価メッセージとメッセージ・コンテンツに基づきます。

条件アラートは、関連付けられたトランザクション・インスタンスの「アラート」タブで、問合せ、フィルタおよび表示できます。過去24時間に発行されたアラートは、「過去1時間のアラート」→「条件アラート」ビュー(ナビゲータから)を使用してフィルタおよび表示できます。ダッシュボードには様々な条件アラート数が含まれています。

トランザクションに対するフォルト監視を実行できるように、プロパティ値のテストのために、または欠落メッセージをレポートするために、特定の条件を定義できます。

- システム・アラートでは、監視インフラストラクチャの状態に関する情報を提供します。Business Transaction Managementでは、致命的エラーの発生、コンテナの停止、ポリシーの拒否、使用中の属性の削除などの状況で、システム・アラートを発行します。
システム・アラートをチェックするには、次のいずれかのことを実行します。

- ナビゲータで、「過去1時間のアラート」→「システム・アラート」を選択します。

- ナビゲータで「管理」→「システム・ポリシー」を選択し、次に、「アラート」タブをクリックします。

8.2 サービス・レベル合意について

サービス・レベル合意(SLA)ポリシーを使用すると、ビジネス・アプリケーションのパフォーマンスの標準を設定して、その標準からの差異を監視できます。差異が発生すると、アラートが発行されて管理コンソールに表示されます。

SLAを使用して、次のようなイベントに関する情報を取得できます。

- トランザクションの全体のフォルト率が1%を超過する場合

- サービスのレスポンス時間が履歴の標準を15%下回る場合

- トランザクションのコンシューマの最大レスポンス時間が1秒を超える場合

SLAポリシーは、複数の異なるオブジェクト(トランザクション、サービス、エンドポイント、個々の操作およびコンシューマ)に適用できます。また、すべてのトランザクションや指定されたオブジェクトの任意のサブセットなど、システム内の任意の数のオブジェクトに、1つのSLAポリシーを適用することもできます。一部のSLAポリシーは、一部のオブジェクトにのみ適しています。

SLAを定義する場合は、次の情報を指定する必要があります。

- タイプ: 固定、ベースラインまたは使用状況

- 指定されたオブジェクトのパフォーマンスがどのような目的を満たす必要があるか

- SLAが実施される期間

- SLAが適用されるオブジェクトの選択に使用される基準

SLAの状態への影響なくエンドポイントをシャットダウンする必要がある場合は、エンドポイントをシャットダウンする前に、その停止時間をスケジュールできます。スケジュール済停止時間の間もインスツルメント測定の収集と表示は継続されますが、それらの測定結果はSLA評価には使用されません。

8.2.1 パフォーマンス目標

SLAポリシーを作成するときには、いくつかのパフォーマンス目標を指定し、各目標はいずれかの監視インスツルメントに基づきます。たとえば、平均レスポンス時間インスツルメントに基づくパフォーマンス目標を指定できます。また、有効範囲、警告値が何によってトリガーされるか、および失敗値が何によってトリガーされるかも指定します。「警告値」はオプションです。

8.2.2 評価期間

Business Transaction Managementでは、周期ベースでSLAに対してシステムのパフォーマンスを評価します。SLAを作成する場合は、次のことを指定します。

- 評価対象の期間

- 期間は固定か継続か

- 評価がいつ発生するか

固定期間は定義された時間に開始および終了し、評価は期間の終わりに1回のみ発生します。評価タイミングは、評価が発生する、つまり期間の終わりでもある正確な時間を指定することによって設定します。たとえば、固定期間を1か月に設定し、評価をその月の2日目の正午に開始できます。

連続する固定期間は重複しません。

継続期間は評価タイミングに相対的に開始および終了します。評価タイミングは、評価の頻度を指定することによって設定します。各評価において、期間の終わりが評価のタイミングとなり、始めはそれよりも期間の長さの分だけ前になります。たとえば、期間は継続する10分、評価の発生は2分ごとと定義できます。

連続する継続期間は重複します。

8.3 サービス・レベル合意の定義

サービス・レベル合意(SLA)は、SLAポリシーを作成することによって定義します。選択したSLAポリシーのタイプに応じて、ポリシーを適用する前に一連のタスクを実行することが必要となる場合があります。3つのタイプは次のとおりです。

- 固定値: 最も基本的なSLAです。すべてのトランザクション、サービス、エンドポイントや操作の使用状況にわたるパフォーマンスを評価します。コンシューマ使用状況には使用できません。履歴パフォーマンスは考慮されません。

- ベースライン: このSLAを使用すると、履歴パフォーマンス測定に相対的なパフォーマンス目標を指定できます。すべてのトランザクション、サービス、エンドポイントや操作の使用状況にわたるパフォーマンスを評価します。コンシューマ使用状況には使用できません。

- 使用状況: このSLAでは、コンシューマ単位でパフォーマンスを評価します。パフォーマンスがパフォーマンス目標から逸脱したコンシューマに対してのみアラートが発行され、個々のコンシューマのパフォーマンスを監視できます。このタイプのSLAはトランザクションとともに使用できます。

8.3.1 固定値のSLAの定義

1. SLAがサービス用かトランザクション用かを決定します。
サービス用のSLAを作成する場合は、「作成」→「SLAポリシー」→「サービスSLA」を選択した後、サブメニューから「固定値」タイプを選択します。

トランザクション用のSLAを作成する場合は、「作成」→「SLAポリシー」→「トランザクションSLA」を選択した後、サブメニューから「固定値」タイプを選択します。

SLAポリシー・ツールが開きます。

2. 評価期間を指定します。

3. 目標を選択します。「インスツルメントの選択」をクリックし、パフォーマンス目標の設定に使用する、それぞれのインスツルメントのチェック・ボックスを選択して、「OK」をクリックします。

4. 「操作の選択」をクリックし、パフォーマンス目標を設定する操作を選択して、「OK」をクリックします。
これで、SLAポリシー・ツールに、選択したインスツルメントごとに1つのパフォーマンス目標が表示されるようになります。

(操作を選択するには、最初にオブジェクトを選択し、次に、「作成」→「SLAポリシー: selected_object」を選択することによって、ツールを開く必要があります。)

5. パフォーマンス目標の失敗値と警告値を指定します。
目標が操作用のものである場合、これらの値はその操作にのみ関連します。目標がサービスまたはエンドポイント用のものである場合、これらの値はサービスまたはエンドポイントでのすべての操作の合計または平均(インスツルメントがトラフィックなどのカウンタである場合は合計、インスツルメントが平均レスポンス時間などの平均を取得するインスツルメントである場合は平均)に関連します。

6. 「基準」セクションを使用して、ポリシーを適用するオブジェクトを選択します。

7. 「基準」セクションで、オブジェクトをプレビューします。

8. 「適用」をクリックします。

8.3.2 ベースラインSLAの定義

ベースラインを設定する前に、retrieveObjectDataに-deleteオプションを設定して実行することによって、以前に設定されたベースラインを削除できます。

ベースラインSLAを定義する前に、次のことを実行してベースラインを設定する必要があります。

1. トラフィックを実行して、適切なベースライン・データを選択できる期間を特定します。

2. ベースライン・データをエクスポートします。retrieveObjectData CLIコマンドを実行して、SLAのベースラインとして使用するためのパフォーマンス履歴を取得します。

3. retrieveObjectData CLIコマンドの出力ファイルを入力ファイルとして使用して、setBaseLines CLIコマンドを実行し、SLAのベースラインを設定します。

ベースラインSLAを定義するには

1. SLAがサービス用かトランザクション用かを決定します。
トランザクション用のSLAを作成する場合は、「作成」→「SLAポリシー」→「トランザクションSLA」を選択した後、サブメニューから「ベースライン」タイプを選択します。

サービス用のSLAを作成する場合は、「作成」→「SLAポリシー」→「サービスSLA」を選択した後、サブメニューから「ベースライン」タイプを選択します。

SLAポリシー・ツールが開きます。

2. 評価期間を指定します。

3. 目標を選択します。「インスツルメントの選択」をクリックし、パフォーマンス目標の設定に使用する、それぞれのインスツルメントのチェック・ボックスを選択して、「OK」をクリックします。
これで、SLAポリシー・ツールに、選択したインスツルメントごとに1つのパフォーマンス目標が表示されるようになります。

4. パフォーマンス目標の失敗値と警告値を指定します。
目標が操作用のものである場合、これらの値はその操作にのみ関連します。目標がサービスまたはエンドポイント用のものである場合、これらの値はサービスまたはエンドポイントでのすべての操作の合計または平均(インスツルメントがトラフィックなどのカウンタである場合は合計、インスツルメントが平均レスポンス時間などの平均を取得するインスツルメントである場合は平均)に関連します。

5. 「基準」セクションを使用して、ポリシーを適用するオブジェクトを選択します。

6. 「基準」セクションで、オブジェクトをプレビューします。

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

8.3.3 使用状況SLAの定義

使用状況SLAを定義する前に、メッセージをコンシューマにマップし、該当するトランザクションのセグメンテーションを有効にする必要があります。

1. トランザクション用の使用状況SLAを作成する場合は、「作成」→「SLAポリシー」→「トランザクションSLA」を選択した後、サブメニューから「使用状況」タイプを選択します。
SLAポリシー・ツールが開きます。

2. 次のように、ポリシーが適用されるコンシューマを指定します。

1. デフォルトでは、ポリシーはすべてのコンシューマに適用されます。ポリシーをコンシューマのサブセットに制限するには、システム内のすべてのコンシューマをクリックし、「コンシューマのサブセット」を選択します。

2. 次に、表示された「フィルタ」ボタンをクリックし、フィルタの設定ダイアログ・ボックスでコンシューマのサブセットを指定します。

3. 評価期間を指定します。

4. 目標を選択します。「インスツルメントの選択」をクリックし、パフォーマンス目標の設定に使用する、それぞれのインスツルメントのチェック・ボックスを選択して、「OK」をクリックします。
これで、SLAポリシー・ツールに、選択したインスツルメントごとに1つのパフォーマンス目標が表示されるようになります。

5. 「操作の選択」をクリックし、パフォーマンス目標を設定する操作を選択して、「OK」をクリックします。
操作を選択するには、最初にオブジェクトを選択し、次に、「作成」→「SLAポリシー: selected_object」を選択することによって、ツールを開く必要があります。

目標が操作用のものである場合、これらの値はその操作にのみ関連します。目標がサービスまたはエンドポイント用のものである場合、これらの値はサービスまたはエンドポイントでのすべての操作の合計または平均(インスツルメントがトラフィックなどのカウンタである場合は合計、インスツルメントが平均レスポンス時間などの平均を取得するインスツルメントである場合は平均)に関連します。

6. パフォーマンス目標の失敗値と警告値を指定します。

7. 「基準」セクションを使用して、ポリシーを適用するオブジェクトを選択します。

8. 「基準」セクションで、オブジェクトをプレビューします。

9. 「適用」をクリックします。

8.4 SLAポリシーの使用

SLAポリシーを定義した後、それを表示、変更、無効化、複製または削除することが必要になる場合があります。この項では、これらのタスクを実行する方法について説明します。

SLAポリシー定義を表示するには

1. 「エクスプローラ」→「SLAポリシー」タブを選択します。

2. 「プロファイル」タブを選択します。

エンドポイント、サービスまたはトランザクションにどのポリシーが適用されているかを表示するには

1. メイン領域で、対象となるオブジェクトを選択します。

2. 「ポリシー」タブを選択します。

あるポリシーが適用されているすべてのオブジェクトを表示するには

1. 「SLAポリシー」ビューで、対象となるポリシーを選択します。

2. 「ターゲット」タブを選択します。

ポリシーのステータスを表示するには

ポリシーのステータスは、その「プロファイル」タブの右上の隅に表示されるか、または、個々のターゲットを表示することを選択した場合には「ポリシー」タブの「ポリシー・ステータス」列に表示されます。ステータス値には、applied, pending, rejected, disabledまたはdeletedが含まれます。

SLAポリシーを変更するには

1. 「エクスプローラ」→「SLAポリシー」を選択します。

2. メイン領域で関心のあるポリシーを選択します。

3. 「変更」→「定義の編集: <policy>」を選択します。

4. 必要な変更を加え、「適用」をクリックします。

ポリシーを無効化するには

ポリシーは2通りのうちの1つの方法で無効にできます。2番目の方法は1番目の方法の省略バージョンです。

- ポリシーを変更してそのポリシーを無効にします。「変更」→「定義の編集」を選択します。ポリシー定義の「有効」チェック・ボックスを選択解除し(た後、「適用」をクリックし)ます。

- メイン・ペインでポリシーを選択し、「変更」→「policyNameの無効化」を選択します。

ポリシーを複製するには

ポリシーの複製は、複雑な基準や設定を定義してあり、すでに定義済のものに非常に類似したポリシーを定義する作業が再度発生しないようにする場合に役立ちます。

1. メイン・ペインでポリシーを選択します。

2. 「変更」メニューから「ポリシーの複製」を選択します。

3. 複製されたポリシーは、デフォルトで、オリジナルに_1の拡張子が付いた名前になります。必要に応じて独自の名前を指定できます。

4. 任意の設定や基準を変更します。

5. 「適用」をクリックします。

ポリシーを削除するには

ポリシーを削除するには、メイン・ペインでポリシーを選択し、「変更」メニューから「<Policy>の削除」を選択します。

8.5 SLA準拠の監視

この項では、SLAの準拠を監視できる方法をリストします。監視タスクは高レベルから低レベルの順に(上から下へ)並べられます。それぞれのタスクにはナビゲーションの指示が示されます。

監視するには:

- 全体的な現在のSLA準拠
「ダッシュボード」→「操作状態サマリー」に移動します。

- すべてのSLA違反アラートの最近の履歴デフォルトでは過去1時間のデータが表示されますが、フィルタを使用して、より長い期間を表示できます。
「過去1時間のアラート」→「SLAアラート」にナビゲートします。

- 特定のオブジェクト(たとえば、PlaceOrderという名前のトランザクション)の、全体の現在のSLA準拠
メイン領域で、特定のオブジェクトのオブジェクト・タイプ→「コンプライアンス・ステータス」アイコンにナビゲートします。

たとえば、ナビゲータで「トランザクション」を選択し、メイン領域で、トランザクションの「コンプライアンス・ステータス」アイコンを参照します。緑色の円は、そのオブジェクトが現在準拠していることを示します。

- 特定のオブジェクト(たとえば、PlaceOrderという名前のトランザクション)の、詳細な現在のSLA準拠
特定のオブジェクト→「SLA準拠」タブにナビゲートします。

たとえば、ナビゲータで「トランザクション」を選択し、メイン領域で対象となるトランザクションを選択して、「SLA準拠」タブをクリックします。

- 特定のオブジェクトのSLA違反アラートの最近の履歴
特定のオブジェクト→「アラート」タブにナビゲートします。

また、特定のオブジェクトの「分析」タブを使用して「違反アラート」パネルを参照し、特定の期間にトリガーされた違反を確認することもできます。

8.6 「SLA準拠」タブ

「SLA準拠」タブには、選択したオブジェクト(トランザクション、サービス、エンドポイント、操作またはコンシューマ)のSLA準拠の現在の状態が表示されます。一部のタイプの情報は特定のタイプのオブジェクトにのみ関連するため、「コンプライアンス」タブのレイアウトはオブジェクトごとに異なる場合があります。

「SLA準拠」タブには、「しきい値のコンプライアンス」と「ベースライン」の2つのサブタブがあります。

- 「しきい値のコンプライアンス」サブタブでは、選択したオブジェクトのリアルタイム監視が行われます。

- 「ベースライン」サブタブには、参照ポイントとして使用できるオブジェクトの履歴ベースライン値が表示されます。選択したオブジェクトのベースラインが定義されている場合のみデータが表示されます。(詳細は、8.3.2項「ベースラインSLAの定義」を参照してください。)

コンシューマのベースラインはありません。他のオブジェクト・タイプの「しきい値のコンプライアンス」サブタブに表示される情報は、コンシューマの「SLA準拠」タブに直接表示されます。次に、この情報について説明します。

「しきい値のコンプライアンス」サブタブでは、グリッド・ビューが使用されます。各行は、1つのパフォーマンス目標を表します。

列には、目標を特定して定義する各種統計情報が表示されます。また、リアルタイムの監視値を示す2つの動的列もあります。「値」列と「現在のステータス」列です。

「現在のステータス」列の値には次の3つがあります。

- 緑色の円はオブジェクトがSLA準拠であることを示します。

- 黄色の三角は目標の警告のしきい値に現在違反していることを示します。

- 赤色のひし形は目標の失敗のしきい値に現在違反していることを示します。

「値」列には、目標がベースとするインスツルメントの現在の値が表示されます。

値の横の拡大鏡をクリックすると、インスツルメントの最新履歴を示すチャートがポップアップ表示されます。次に例を示します。

チャートにはSLAの評価期間と等しい期間が表示されます。右端は現在の時間です。この例では、黄色の線の上の値は警告のしきい値を超えています。赤色の線の上にあるものは失敗のしきい値を超えています。(指定したしきい値を常に上回る必要がある目標を設定した場合は、色付けされた警告領域および失敗領域はしきい値の線の下に表示されます。)

目標が使用状況SLAの一部である場合、目標はコンシューマ別にのみリストされます。使用状況SLAの一部ではない目標の「コンシューマ」列は空です。

8.7 サービスまたはエンドポイントの停止時間のスケジューリング

SLAの状態への影響なくサービスをシャットダウンする必要がある場合は、サービスをシャットダウンする前に、その停止時間をスケジュールする必要があります。スケジュール済停止時間の間もインスツルメント測定の収集と表示は継続されますが、それらの測定結果はSLA評価には使用されません。

サービスの停止時間をスケジュールするには、最初に停止時間スケジュールを作成し、次に、そのスケジュールをサービスの各エンドポイントに追加する必要があります。

また、この項では、スケジュールを表示する方法、エンドポイントからスケジュールを削除する方法およびすべてのエンドポイントからスケジュールを削除する方法についても説明します。

停止時間スケジュールを作成するには

1. 「作成」→「スケジュール」を選択して、「スケジュールの作成」ツールを開きます。

2. スケジュールに説明的な名前を付けます。

3. 「スケジュール・タイプ」を「カスタム」に設定します。

4. 最初のドロップリストをクリックし、停止時間の繰返し間隔を選択します。たとえば、次のスケジュールでは、停止時間に毎週を選択し、曜日、開始時間、停止期間の継続時間、および開始の日付を指定しています。

日付を選択するオプションを使用すると、毎月の第1日のように、月での日付を数字でスケジュールできます。

曜日を選択するオプションを使用すると、毎月の第1月曜日のように、曜日名でスケジュールできます。

5. 残りのフィールドとドロップリストを使用して、停止時間が開始する時刻、その継続時間、および最初に発生する日付を指定します。

6. スケジュールに追加の停止時間をスケジュールするには、「新しい期間を追加」をクリックします。

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

エンドポイントに停止時間スケジュールを追加するには

1. エンドポイントを選択します。

2. 「変更」→「エンドポイント停止時間スケジュールの設定」を選択します。
「エンドポイント停止時間スケジュールの設定」ツールが開きます。

3. 停止時間スケジュールを「スケジュールの選択」ドロップリストから選択します。

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

エンドポイントのスケジュール済停止時間を表示するには

1. エンドポイントを選択します。

2. 「停止時間」タブを開きます。
スケジュールの名前と、その後に、そのスケジュールに対して指定されたすべてのイベントのリストが表示されます。

すべてのスケジュールを表示するには

1. ナビゲータから、「エクスプローラ」→「スケジュール」を選択します。

2. 現在定義されているスケジュールが、メイン・ペインにリストされます。

3. 「プロファイル」タブには、メイン・ペインで選択されたスケジュールの定義が表示されます。

1つのエンドポイントから停止時間スケジュールを削除するには

1. エンドポイントを選択します。

2. 「変更」→「エンドポイント停止時間スケジュールの設定」を選択します。
「エンドポイント停止時間スケジュールの設定」ツールが開きます。

3. 「スケジュールの選択」ドロップリストから、「停止時間なし」を選択します。

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

すべてのエンドポイントから停止時間スケジュールを削除するには

1. ナビゲータで、「スケジュール」を選択します。

2. サマリー領域で、削除するスケジュールを選択します。

3. 「変更」→「schedule_nameの削除」を選択します。

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

8.8 条件について

1つ以上の条件を1つのトランザクションに関連付けることができます。条件は、Business Transaction Managementがトランザクションのインスタンスに対して評価する式です。条件を使用して、Business Transaction Managementから次の種類のイベントについて通知されるようにできます。

- $10,000を超えるオーダーが処理されます。

- ある顧客のフォルト率が1%を超えます。

- トランザクション・インスタンスが予想される完了時間を超えました。

トランザクションに対して3つのタイプの条件を定義できます。

- コンテンツベースの条件。指定した条件が満たされた場合に、アラートを発行します。基準では、特定の操作に対し、プロパティ値またはフォルト、あるいはその両方を指定できます。

- 欠落メッセージ条件。指定したメッセージが、指定された期間内に発生しない場合に、アラートを発行します。

- フォルト監視条件。トランザクションのいずれかの操作でフォルトが発生した場合に、アラートを発行します。これらのタイプの条件は、トランザクション内のすべての操作に対するすべてのフォルトに、コンテンツベースの条件を定義することと同じです。フォルト監視条件はデフォルトでは無効です。

条件がTrueに評価されると、Business Transaction Managementによって次のことが実行されます。

- 条件定義で指定された重大度に基づき、条件アラートを作成します。

- 条件の発生回数を追跡します。

- Trueに評価されたトランザクションのインスタンスをアセンブルし、ログに記録します。

- 「記憶域設定」タブで、トランザクションの「アーカイブされた条件インスタンスを維持」値に対して指定された時間の長さだけ、ログに記録されたトランザクション・インスタンスを維持します。デフォルトでは30日です。

条件はインスタンス単位で評価されるため、インスタンス・ロギングが有効化されている必要があります。トランザクションの条件を定義した場合、インスタンス・ロギングを有効にしていないと、そのトランザクションについては自動的にオンになります。

条件を定義するときには、条件がTrueに評価された場合に発行されるアラートに重大度レベルも割り当てます。重大度レベルは、情報、警告および失敗です。

8.9項「条件の使用」では、条件の定義、条件情報の表示、条件の変更、および条件の削除方法について説明します。

8.8.1 条件の定義および評価

コンテンツベースの条件を定義する場合は、次の制限に注意する必要があります。

- 条件定義には複数の句を含めることができますが、すべての句で同一のメッセージ(operation.request、operation.replyまたはoperation.fault)を参照する必要があります。

- コンテンツベースの条件では、プロパティ値またはフォルト値、あるいはその両方をテストできます。両方の場合、プロパティを操作のフォルト・フェーズで定義する必要があります。

- 条件定義では、フォルト・コードを除き、プロパティを介して参照されるメッセージ要素のみを使用できます。

コンテンツベースの条件は、それが定義されたメッセージが発生したときに評価されます。条件がTrueに評価された場合、その条件を満たしたインスタンスがトランザクション内からコールされたことを確認するために、Business Transaction Managementによって、トランザクションの開始メッセージへの相関付けが実行されます。該当する場合は、結果のインスタンスがアセンブルされ、トランザクションの記憶域設定「アーカイブされた条件インスタンスを維持」で指定された継続時間にわたって保存されます。

欠落メッセージ条件の評価は、トランザクションの開始メッセージが発生したときに開始されます。その後、条件定義で指定された期間、メッセージが探されます。その期間にメッセージが発生しないと、欠落メッセージ条件がTrueに評価されます。

トランザクションに対する条件を定義すると、それがトランザクションの「条件」タブにリストされます。

8.8.2 条件アラートの解釈

通常、アラートは、エラーの発生などの悪い状況が発生したことを通知するものと考えられています。ただし、Business Transaction Managementでは、どのような種類のメッセージのパターンの発生を示すためにも、条件アラートが使用されます。このため、条件定義に応じて、顧客がオーダーを倍増させた、プロセスの効率が一定のレベルを達成した、特定の地域の売上が標準を超えた、などのポジティブなイベントをアラートで通知できます。重大度の設定を使用して、アラートがポジティブなイベントを示す(情報レベル)か、ネガティブなものを示す(警告または失敗レベル)かを通知できます。

アラートが発行された場合、その状況に対処するいくつかの方法があります。次のことができます。

- ログに記録されたインスタンスの表示

- 電子メールによる当事者への通知

発生した条件アラートは、関連トランザクション・インスタンスの「アラート」タブで、問合せ、フィルタおよび表示できます。また、すべてのオブジェクトについて、過去24時間に作成されたアラートも、「条件アラート」ビュー(ナビゲーション・バーから)を使用してフィルタおよび表示できます。ダッシュボードには、様々なアラート数も含まれています。

8.9 条件の使用

この項では、条件の使用に伴う次のタスクを完了する方法について説明します。

- フォルト監視の有効化と無効化

- 条件の定義

- 条件の有効化と無効化

- 条件情報の表示

- 条件定義の変更

- 条件定義の複製

- 条件の削除

8.10項「条件アラート情報の表示」では、アラート数と、ある条件が満たされたときに生成されるアラートの表示に関する情報を提供します。

8.9.1 フォルト監視の有効化と無効化

トランザクションを作成すると、トランザクションに対してフォルト監視条件が自動的に作成され、無効化されます。

フォルト監視ステータスをチェックするには

1. 対象となるトランザクションを選択します。

2. 「条件」タブをクリックします。フォルト監視状態が表示されます。

3. 「編集」ボタンをクリックしてフォルト監視を有効化できます。または、次に説明するように「変更」メニューを使用できます。

フォルト監視を有効化するには

1. フォルト監視を有効化するトランザクションを選択します。

2. 「変更」→「フォルト監視を有効化/無効化: TransactionName」を選択します。選択したオブジェクトの「フォルト監視の編集」ツールが表示されます。

3. 「重大度」ドロップダウン・リストを使用して、オブジェクトのフォルト生成アラートに関連付ける重大度レベルを選択します。サービスの「条件」タブに、そのサービスに対してフォルト監視が有効化されていることが表示され、フォルト監視の重大度ステータスも表示されます。

4. 無効化するには、「条件」タブの「編集」ボタンをクリックし、表示されたダイアログで有効化のチェック・ボックスを選択解除します。また、「変更」メニューから監視の有効化/無効化項目を使用することもできます。

8.9.2 条件の定義

条件を定義する方法は、それがコンテンツベースの条件であるか欠落メッセージ条件であるかに応じて異なります。これらのオプションについては後述します。

コンテンツベースの条件を定義するには

- 条件を定義するトランザクションを選択します。

- 「作成」→「トランザクション条件」→「コンテンツ条件: TransactionName」を選択します。「条件の作成」ツールのダイアログが表示されます。

- 「名前」テキスト・ボックスで、条件の名前を指定します。

- 「重大度」ドロップダウン・リストから、この条件に関連付ける重大度の値を選択します。
条件に重大度を関連付けると、この属性に基づいて、アラートのビューをフィルタできます。

- 「有効」チェック・ボックスを使用して、条件を有効または無効にします。

- オプション: 「説明」テキスト・フィールドを使用して、ブール式を読まなくても、この条件の性質や使用方法を理解できるようにするための説明を指定します。

- 「基準」領域のボタンと項目を使用して、条件を評価するときに使用されるブール式を作成します。3つのボタンが表示され、これらから、条件を構成する要素を選択できます。(すべての句が同じメッセージ(操作フェーズ)に属する必要があります。
「プロパティ」ボタンは、選択したオブジェクトにプロパティが定義してある場合にのみ表示されます。)次の表に、ボタンの使用方法の説明を示します。ボタンをクリックして要素を選択すると、条件を定義するために使用している「基準」に行が追加されます。それぞれの行で、演算子およびテストする値を選択します。

完了したら、「適用」をクリックします。

ボタン

説明

新規プロパティ

条件の基礎となるプロパティを定義する必要があり、まだ定義していない場合は、「新規プロパティ」ボタンを使用して作成できます。

プロパティ

既存のプロパティを選択します。

フォルト

ステータスの確認対象となる操作を選択し、「基準」セクションで、特定のコードを探すか、またはすべてのフォルトとするかを指定します。

欠落メッセージ条件を定義するには

欠落メッセージ条件を定義するには、着信時刻の確認対象となるメッセージ、およびそのメッセージがどれだけの時間ない場合にアラートを発生させるかを指定する必要があります。欠落メッセージは、リクエスト、レスポンスまたはすべてのフォルトにできます。

1. 条件を定義するトランザクションを選択します。

2. 「作成」→「トランザクション条件」→「欠落メッセージ条件: TransactionName」を選択します。「相関の作成」ツールのダイアログが表示されます。

3. 「名前」テキスト・ボックスで、条件の名前を指定します。

4. 「重大度」ドロップダウン・リストから、この条件に関連付ける重大度の値を選択します。条件に重大度を関連付けると、この属性に基づいて、アラートのビューをフィルタできます。

5. 「有効」チェック・ボックスを使用して、条件を有効または無効にします。

6. オプション: 「説明」テキスト・フィールドを使用して、ブール式を読まなくても、この条件の性質や使用方法を理解できるようにするための説明を指定します。

7. 「基準」領域でドロップダウン・リストを使用して、条件が評価されるときにBusiness Transaction Managementが評価するブール式を作成します。3つのドロップダウン・リストが表示され、これらから、条件を構成する要素を選択できます。

ドロップダウン・リスト

説明

操作名

ドロップダウン・リストから操作を選択します。

操作フェーズ

ドロップダウン・リストから、「リクエスト」、「レスポンス」または「フォルト」を選択します。

評価期間

「トランザクションの最大トランザクション期間が切れる前」または「タイマーを使用」のいずれかの評価の期間を選択します。
「タイマーを使用」を選択する場合は、期間をミリ秒で指定する必要があります。

いずれの場合も、トランザクションの開始メッセージが着信すると、Business Transaction Managementによって、インスタンス単位の時間の計測が開始されます。

8.9.3 条件の有効化と無効化

条件を個別に有効化および無効化したり、複数の条件を一度に有効化および無効化できます。

個々の条件を有効化または無効化するには

1. その条件が定義されているトランザクションを選択します。

2. 詳細領域で、「条件」タブをクリックします。

3. 有効化または無効化する条件の「編集」ボタンをクリックします。

4. ドロップダウン・リストから「変更」を選択します。

5. 確認ダイアログで「有効化/無効化」チェック・ボックスを選択すると、条件のステータスが変更されます。

6. 「適用」をクリックします。

選択した条件を有効化または無効化するには

1. 条件を有効化または無効化するトランザクションを選択します。

2. 「変更」→「条件を有効化/無効化: TransactionName」を選択します。

3. 確認ダイアログで「すべて有効化」または「すべて無効化」ボタンをクリックして条件のステータスを変更するか、ラジオ・ボタンを使用して、対象となる条件を選択します。

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

8.9.4 条件情報の表示

1. 「トランザクション」ビューから、対象となるトランザクションを選択します。

2. 「条件」タブをクリックして、定義済のすべての条件を参照します。アイコンは条件の重大度レベルを示します。緑色は情報、黄色は警告、赤色は失敗です。

8.9.5 条件定義の変更

1. 対象となるトランザクションを選択します。

2. 詳細領域で、「条件」タブをクリックします。

3. 条件の「編集」ドロップダウン・リストから、「編集」を選択します。

4. 「条件」ツールを使用して、定義を変更します。

8.9.6 条件定義の複製

1. 対象となるトランザクションを選択します。

2. 「条件」タブをクリックします。

3. 条件の「編集」ドロップダウン・リストから、「複製」を選択します。

4. 必要に応じて定義を変更します。

5. 「適用」をクリックします。

8.9.7 条件の削除

1. 対象となるトランザクションを選択します。

2. 「条件」タブをクリックします。

3. 対象となる条件のドロップダウンの「編集」メニューから、「削除」を選択します。

8.10 条件アラート情報の表示

条件がTrueに評価されると、その発生が追跡され、条件アラートが自動的に作成されます。この項では、Business Transaction Managementで件数や条件アラート情報が表示される様々な方法について、および、アラートを保存する時間を変更する方法について説明します。

アラートを手動で削除することはできません。

8.10.1 件数情報の表示

条件アラートの件数情報は、次のように表示できます。

- 「操作状態サマリー」ダッシュボードで(アラートの各タイプの件数)

- 「上位10件のトランザクション」ダッシュボードで

- トランザクションの「アラート」タブで

- トランザクションの「分析」タブの「パフォーマンス」ペインで

- トランザクションの「分析」タブの「条件」ペインで

また、列チューザを使用して「条件アラート」と「条件アラート率」インスツルメントを選択することによって、トランザクションのサマリー・ビューを編集し、条件アラートの件数と、現在の条件アラート率が表示されるようにできます。「条件アラート」インスツルメントでは、指定された期間における条件の発生を指定します。「条件アラート率」インスツルメントでは、指定された期間における1時間当たりの条件の発生の数を指定します。

8.10.2 アラートおよび詳細情報の表示

条件アラートは、次の方法で表示できます。

- 関連付けられたサービス、エンドポイント、操作またはトランザクション・インスタンスの「アラート」タブで。拡大鏡アイコンをクリックするか、アラートをダブルクリックすると、選択されたアラートの詳細情報が別のウィンドウに表示されます。

- 過去1時間に発生した条件アラートについては、ナビゲータから、「条件アラート」ビューで。タブ領域の「情報」タブには、選択されたアラートの詳細情報が別のウィンドウに表示されます。

条件アラートの詳細には、次の情報が含まれています。

- 条件の名前と重大度、およびアラートをトリガーした評価の式。

- サマリー情報: トランザクションの名前、それが取得された時間(開始時間)、そのID、メッセージ交換と合計メッセージの数、トランザクションのレスポンス時間、およびトランザクションの実行中に発生したすべての条件アラート(重大度フラグの表示付き)。

- 条件式がTrueに評価された操作を赤色の破線の矢印で示すトランザクションのグラフ。それぞれの操作に対するリクエストおよびレスポンス・メッセージを表示するには、グラフの下のリストの、該当する操作のインスペクタ・アイコンをクリックします。

8.10.3 アラートの有効期限の変更

デフォルトでは、ログに記録されたアラートの情報は、1年(31536000秒)後に失効します。

アラートの有効期限は、次のように変更できます。

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

2. サマリー・ペインで、「AP_Notifier_Service」を選択します。

3. 「管理」メニューから、設定データの編集: AP_Notifier_Serviceを選択します。

4. 「ログ通知の有効期間(秒単位)」フィールドを適切な数字(秒単位)に変更します。

5. 「適用」をクリックします。

9 レポートの作成

この章では、Business Transaction Managementによって収集されたパフォーマンス情報を基にレポートを作成する方法について説明します。

次の項で構成されます。

- 概要

- レポートの生成

9.1 概要

Business Transaction Managementでは、レポートの作成を支援する次の要素が提供されています。

- retrieveObjectDataコマンド。レポートで使用するデータを生成します。コマンド・パラメータを使用して、目的のデータを指定します。たとえば、サービス別のフォルト・カウント、トランザクション別の最大レスポンス時間、トランザクション別の条件アラート率などに関するデータを抽出できます。

- HTML、PDF、RTF、Excel、PowerPoint、MHTMLおよびデータ形式で適切に形式化されたレポートを作成するためにOracle BI Publisher (11 g)で使用できるテンプレート。

- 生成するレポートのタイプに合わせて使用できるretrieveObjectDataコマンドの例。

- データを生成しないでレポート・ツールを試すために使用できるretrieveObjectData出力ファイルの例。

レポートの作成に役立つ素材は、次のディレクトリにあります。

BTM_Install_Directory\samples\reports

このディレクトリには2つのサブディレクトリが含まれています。

- templates: このディレクトリには、Oracle BI Publisher (11 g)アプリケーションで提供されているテンプレート・ツールでのみ使用できるテンプレートが含まれています。また、reports.xlsファイルも含まれ、このExcelスプレッドシートには、テンプレートごとに適切なretrieveObjectDataコマンドが示され、このコマンドでレポートを生成するためにテンプレートに結合される出力データが提供されます。
たとえば、AvgResponseTimeByServiceテンプレートとともに使用されるretrieveObjectDataコマンドは、次のとおりです。

btmcli retrieveObjectData -s sphere -l sphereLogin -type service
-attributeNames  friendlyName averageResponseTime -inTheLast 24h
-intervalSize 1h -format xmltable > AvgResponseTimeByService.xml

また、FaultCountByServiceテンプレートとともに使用されるretrieveObjectDataコマンドは、次のとおりです。

btmcli retrieveObjectData -s sphere -l sphereLogin -type service
-attributeNames friendlyName faultCount -inTheLast 24h -intervalSize 1h
-format xmltable > FaultCountByService.xml

- sampleData: このディレクトリには、データを生成しないでレポートの外観を確認するために使用できるretrieveObjectData出力ファイルの例が含まれています。

9.2 レポートの生成

テンプレートおよびコマンドラインの例を参考にすると、任意の出力データおよびテンプレートを作成し、レポートを生成する方法について学習できます。また、listInstrumentsコマンドを使用して、retrieveObjectDataコマンドに使用する属性名およびセグメント名を決定することが必要になる場合もあります。

BI Publisherでの作業時にBusiness Transaction Managementのテンプレートを使用する方法については、http://www.oracle.com/support/contact.htmlまたはhttp://www.oracle.com/accessibility/support.html(聴覚障害者向け)を参照してください。

10 コマンドおよびスクリプト

この章では、コマンドおよびスクリプトの実行に使用できる、Business Transaction Managementコマンドライン・インタフェース(CLI)について説明します。ここでは、CLIの使用方法、ヘルプとバージョン情報の取得方法、コマンドの安全な実行方法について説明し、コマンドとともに使用するように設定できるシステム変数を示します。内容は、次のとおりです。

- コマンドライン・インタフェース(CLI)について

- ヘルプおよびバージョン情報の取得

- CLIコマンドおよびスクリプトの実行

- CLIコマンドにアクセスする場合のセキュリティ・オプション

- コマンド一覧
環境変数

- 属性名

Business Transaction Managementでは、コマンドに加えていくつかのユーティリティも提供します。これらについては、第11章「ユーティリティ」で説明します。

10.1 コマンドライン・インタフェース(CLI)について

Business Transaction Managementコマンドライン・インタフェース(CLI)では、コマンドラインからまたはスクリプト(bash、perl、ruby、DOS)を使用することで管理コマンドを発行できます。CLIは、UNIXおよびDOSコマンドラインから、およびBusiness Transaction Managementインストールを使用するその他の環境から使用できます。

CLIコマンドを使用すると、システムの構成、DNS別名の管理、レプリケーション問題の解決、サービスの登録、メタデータの管理、監視の制御、ポリシーの適用、データの移行またはレポートに必要なデータの生成を行うことができます。

CLI実行可能ファイル(Windowsではbtmcli.bat、UNIX系システムではbtmcli.sh)は、BTM_Install_Directory/toolsディレクトリにあります。Windowsプラットフォームでは、CLIはBusiness Transaction ManagementにバンドルされているJREを使用します。UNIX系システムでは、次のいずれかを実行して、使用するJREを指定する必要があります。

- JAVA_HOME環境変数を設定し、BTMi_nstall_dir/_server/jreディレクトリを削除します。

- BTM_install_dir/server/jreを有効なJREディレクトリへのリンクで置き換えます。

追加のアクションを実行するためのいくつかのコマンドライン・ユーティリティがあります。詳細は、11.1項「コマンドライン・ユーティリティについて」を参照してください。

10.1.1 ヘルプおよびバージョン情報の取得

すべてのCLIコマンドのリストとヘルプの概要を取得するには、次のコマンドを入力します。

C: > btmcli help

個々のコマンドの詳細なヘルプを取得するには、次のようなコマンドを入力します。

C: > btmcli help commandName

バージョン情報を取得するには、次のコマンドを使用します。

C: > btmcli -v

10.1.2 CLIコマンドおよびスクリプトの実行

Business Transaction Management CLIコマンドまたはスクリプトは、どのコマンド・シェルでも次の構文を使用して実行できます。

btmcli commandName commandFlags

単一のコマンドを実行するには、コマンド・プロンプトでコマンドとそのパラメータを指定します。次に例を示します。

C: btmcli encryptPassword -password "abracadabra"

スクリプトを実行するには、コマンド・プロンプトでスクリプトの名前を指定します。次に例を示します。

C: > myBTMScript.cmd

- スクリプトには、任意のBusiness Transaction Management CLIコマンドを含めることができます。

- スクリプト・ファイルの名前には、オペレーティング・システムに応じた拡張子(.cmd、.bat、.sh)が付いている必要があります。

- スクリプトのコメントは、オペレーティング・システムに応じた形式にする必要があります。

- スクリプトでは、10.1.5項「環境変数」で説明している環境変数を使用できます。

10.1.3 CLIコマンドにアクセスする場合のセキュリティ・オプション

ほぼすべてのCLIコマンドでは、コマンドを実行するために、資格証明をusername:passwordという形式で指定する必要があります。

この資格証明は、次のいずれかの方法で指定できます。

- コマンドに対して-lフラグを使用します。

- AP_USER_LOGIN環境変数を資格証明の値に設定します。この場合、-lフラグを指定する必要はありません。

-lフラグまたは環境変数のいずれを使用するかにかかわらず、次の2通りのうちの1つの方法で資格証明を指定できます。

- コマンドの入力時にユーザー名とパスワードを直接指定するか、またはAP_USER_LOGIN環境変数をそのusername:password値に設定する方法。

- 資格証明ストアにusername:password資格証明を作成し、その資格証明名をコマンドに渡すか、またはAP_USER_LOGIN環境変数をその資格証明名の値に設定する方法。

次の例では、btmcli configureコマンドを使用してそれぞれのケースを説明しています。

1. 次のコマンドでは、-lフラグを使用してユーザー名とパスワードを指定しています。

btmcli configure -i myConfigureFile -s http://uitst3:8080/btmcentral/sphere/
-l joanna:abracadabra

2. 次のコマンドでは、AP_USER_LOGIN環境変数がjoanna:abracadabraに設定されているため、-lフラグは指定されません。

btmcli configure -i myConfigureFile -s http://uitst3:8080/btmcentral/sphere

3. 次のコマンドでは、JoannaCredという資格証明が、credStoreToolコマンドにより次のように定義されています。

btmcli credStoreTool -createCred JoannaCred -credType up
-credValue joanna:abracadabra

configureコマンドは次のようになります。

btmcli configure -i myConfigureFile -s http://uitst3:8080/btmcentral/sphere/
-l JoannaCred

4. 次のコマンドでは、JoannaCredという資格証明が、credStoreToolコマンドにより次のように定義されています。

btmcli credStoreTool -createCred JoannaCred -credType up
-credValue joanna:abracadabra

AP_USER_LOGIN環境変数はJoannaCred=joanna:abracadabraに設定されています。configureコマンドは次のようになります。

btmcli configure -i myConfigureFile -s http://uitst3:8080/btmcentral/sphere/

10.1.4 コマンド一覧

次の表に、CLIコマンドのアルファベット順のリストと、コマンド・アクションの概要を示します。

コマンド名

説明

addBaseAddressAlias

指定されたベース・アドレスのエントリ・ポイントの、指定された別名を追加します。この別名をベース・アドレスとして持つ他のエントリ・ポイントがすでにスフィアで認識されている場合には、2つのエントリ・ポイントとそのコンテンツがマージされ、重複したWSDLとエンドポイントは削除されます。

addNodeAlias

登録済のノードにネットワーク別名を追加します。

addPathAlias

addPathAliasコマンドを使用して、指定のWSDLまたはエンドポイントにアクセスするときに使用できる代替URLパスを表す別名を追加します。この別名を指定すると、検出時にアーティファクトが重複して作成されないようにできます。

configure

構成xmlファイルを読み取り、その情報を使用して指定のスフィアURLに関連付けられているインストールを構成します。

configureAlivenessCheck

デフォルトのpingを使用するのではなく、スフィアがエンドポイントの稼働ステータスをチェックする際に優先される方法を指定します。

createOrUpdateGenre

新規サービス・ジャンルまたはエンドポイント・ジャンルの名前を指定し、新規ジャンルを表すために使用するカスタム・アイコンを示します。

createOrUpdatePolicy

指定されたポリシーをスフィアで直接作成または更新します。

createSettingsDocument

createSettingsDocumentコマンドを使用して、createOrUpdatePolicyコマンドへの入力として使用する設定ドキュメントを作成します。

credStoreTool

資格証明ストアから、指定したタイプの資格証明を作成、取得または削除します。

deleteAll

検出されたオブジェクトを、トランザクション、プロパティ、登録済サービスおよびコンテナなどの関連アーティファクトとともに削除します。削除された項目に関連付けられている履歴データも削除します。

encryptPassword

Business Transaction Management暗号化エンジンを使用して、指定されたテキスト文字列を変換します。変換後の暗号テキストがコマンド出力に表示されます。

exportBusinessObjects

createOrUpdatePolicyコマンドへの入力用の設定ドキュメントを作成します。

exportMessages

指定された期間のエンドポイントのメッセージをエクスポートします。メッセージのエクスポートは、テストおよびデバッグで役立ちます。
ファイルにメッセージをエクスポートすることもでき、ユーザーが実行するかどうかに関係なく、出力は常にコンソールに送信されます。

exportPolicies

指定されたポリシーをstdoutまたは指定の出力ファイルのいずれかにエクスポートします。ポリシーは名前またはタイプを指定してエクスポートするか、一連のポリシーを定義する問合せを使用してエクスポートできます。

exportPolicyTemplates

指定されたポリシー・テンプレートをstdoutまたは指定の出力ファイルのいずれかにエクスポートします。ポリシー・テンプレートは名前またはタイプを指定してエクスポートするか、一連のポリシーを定義する問合せを使用してエクスポートできます。

exportProfile

指定されたオブジェクトのプロファイル値を、stdoutまたは指定の出力ファイルのいずれかにエクスポートします。プロファイルは名前またはIDを指定してエクスポートできます。

exportSchedules

ターゲット・スフィアからスケジュールをエクスポートします。スケジュールはファイルまたはstdoutに出力できます。スケジュールは、名前を指定してエクスポートするか、一連のポリシーを定義する問合せを使用してエクスポートできます。

exportTransactionDefns

指定されたトランザクション定義をエクスポートします。出力ファイルを指定しない場合、定義はstdoutに送信されます。

getSetupData

指定されたサービスの設定ファイルを標準出力に書き込みます。この設定ファイルを、putSetupDataコマンドの入力として使用できます。

importBusinessObjects

指定されたXMLファイルで説明されている、指定された1つ以上のビジネス・オブジェクトをターゲット・スフィアにインポートします。このコマンドでは、デフォルトで、インポートされたオブジェクトより古い既存オブジェクトがすべて置き換えられます。

importPolicies

以前に作成されたエクスポート・ファイルに含まれるポリシーをインポートします。インポートするポリシーは、-iパラメータで指定されたファイルから、またはそのようなファイルが指定されていない場合はstdinから取得されます。

importPolicyTemplates

以前に作成されたエクスポート・ファイルに含まれるポリシー・テンプレートをインポートします。インポートするポリシー・テンプレートは、-iパラメータで指定されたファイルから、またはそのようなファイルが指定されていない場合はstdinから取得されます。

importProfile

以前にエクスポートされたオブジェクト・プロファイルをシステムにインポートします。プロファイルをインポートしても新規オブジェクトは作成されず、既存オブジェクトのプロファイル属性が更新されるのみであることに注意してください。

importSchedules

以前にエクスポートされたスケジュールをターゲット・スフィアにインポートします。このコマンドでは、デフォルトで、インポートされたスケジュールより古い既存スケジュールがすべて置き換えられます。

importTransactionDefns

以前にエクスポートされたトランザクション定義を指定のスフィアにインポートします。このコマンドでは、デフォルトで、インポートされた定義より古い既存定義がすべて置き換えられます。

listInstruments

システムのポリシー・テンプレートで定義されているインスツルメントおよび各インスツルメントの属性名とセグメントをリストします。この情報をretrieveObjectDataコマンドの引数として使用できます。

listNodeAliases

単一のネットワーク・ノードまたは既知のすべてのネットワーク・ノードの別名をすべてリストします。

mergeServices

指定されたサービスの2つのバージョンをマージします。このコマンドでは、ソース・バージョンを削除し、そのエンドポイントをターゲット・バージョンに移動します。
マージ後のターゲット・バージョンには、両方のバージョンのエンドポイントがすべて含まれます。ソース・バージョンに含まれているプロファイル属性またはメッセージ・プロパティで、マージ後のバージョンで保持する必要があるものは、ターゲット・バージョンで再作成する必要があります。

moveEndpoints

指定されたサービスのソース・バージョンからターゲット・バージョンに1つ以上のエンドポイントを移動します。

moveMeasurements

スフィアから削除したサービスまたはエンドポイントに対して収集される測定を、論理的に継続する他のエンドポイントまたはサービスに移動します。

putSetupData

指定されたファイルまたは標準入力から設定ファイルを読み取り、それを指定されたサービスの設定データとして保存します。

registerDevice

管理デバイスをスフィアに登録します。現在サポートされているデバイス・タイプは、ハードウェアおよびソフトウェアのロード・バランサのみで、完全にサポートされているロード・バランサはF5 BigIPのみです。
複数のデバイスを登録する場合は、setDefaultLoadBalancerコマンドを使用してデフォルト・デバイスを設定できます。

registerExternalContainer

(監視対象コンテナに含まれない) 1つ以上のエントリ・ポイントのエンドポイントを、独自の外部コンテナにまとめます。これは手動で登録されたエンドポイントでのみ必要です。

registerMonitor

モニター・エージェントをBusiness Transaction Managementに登録します。

removeBaseAddressAlias

指定された別名を、指定のベース・アドレスのエントリ・ポイントから削除します。別名は、このエントリ・ポイントのみに対してローカルに定義されている必要があります。ネットワーク・ノード・レベルで定義されている別名は、removeNodeAliasコマンドを使用して削除する必要があります。

removeDuplicateEndpoint

指定された重複エンドポイントを削除します。このコマンドは通常、パスは同じだが、システムで認識されなかったDNS別名が原因で異なるホスト名を持つ2つのエンドポイントをシステムが検出した場合に使用します。このコマンドを実行すると、これ以降の検出によって重複エンドポイントが再作成されないように、欠落している別名も追加されます。

removeNode

スフィアからネットワーク・ノードを削除します。

removeNodeAlias

登録済のノードから別名を削除します。

removePathAlias

指定のWSDLまたはエンドポイントにアクセスするときに使用できる代替URLパスを表す別名を削除します。これ以降の登録や検出では、2つのパスが別々のものとして扱われます。

removePolicy

適用済のポリシーを削除し、オプションでポリシーの削除が完了するまで待機します。

removePolicyTemplate

指定されたポリシー・テンプレートをシステムから削除します。

renameEndpoint

スフィアにある指定のエンドポイントのわかりやすい名前を変更します。

resetSphereUrl

このスフィアに現在登録されているコンテナ・サービスのスフィアURLが、現在のスフィアURLと一致していることを確認します。このコマンドを使用する必要があるのは、スフィアのベース・アドレスが変わったときです。

retrieveObjectData

1つ以上のオブジェクトのプロファイル・データと測定データを取得します。このデータは、レポート・ツールの入力として使用できます。

sendEventNotification

通知サービスを使用してイベント通知を作成および送信します。通知の処理方法は、現在アクティブなサブスクリプションによって決定されます。

sendToNotifier

通知サービスに処理のためにコマンドを送信します。コマンドはXML入力ファイルで指定されます。このコマンドは、通知サービスによって返されるレスポンス・ドキュメントを返します。

setBaselines

管理対象オブジェクトのベースラインを設定します。入力ドキュメントの形式は、retrieveObjectDataコマンドの出力と同じです。

setDefaultLoadBalancer

監視対象メッセージ・トラフィックから検出されたルーティング・エントリ・ポイントをモデリングするために使用するデフォルト・デバイスを設定します。
既知のロード・バランサが1つのみの単純な環境では、そのデバイスが自動的にデフォルトとして使用されます。追加のデバイスを登録した場合は、このコマンドを使用して、ルーティング・エントリ・ポイントのモデリングにどのデバイスを使用するかを設定します。

showService

サービスのわかりやすい名前、修飾名または任意のエンドポイントのURLで指定された、サービスの構造を示します。サービスの1つのバージョンを指定したり(-version)、より詳細な情報を表示するように指定することもできます(-verbose)。

unmonitorEndpoint

指定のエンドポイントが登録されているモニター・エージェントによる、エンドポイントの監視を停止します。監視が停止すると、パフォーマンス測定は記録されず、メッセージはログに記録されず、トランザクションはトレースされません。

unregister

サービス、WSDLまたはエンドポイントをスフィアから登録解除します。

unregisterContainer

指定されたコンテナを登録解除します。

unregisterMonitor

指定されたモニター・エージェントをスフィアから登録解除します。このコマンドは、モニターが完全にオフラインになっているときにのみ使用してください。モニターは、システムが停止状態とマークするまで十分に長い時間オフラインにしてから登録解除してください。

updateProfileData

指定したオブジェクト・セットのプロファイル属性データを更新します。このコマンドは既存オブジェクトのみを更新し、指定されたオブジェクトを見つけることができない場合はエラーを返します。

10.1.5 環境変数

次の表に、よく使用されるコマンド・フラグのかわりに、Business Transaction Managementコマンドで使用するよう定義できる環境変数を示します。

環境変数

対応するフラグ名

対応するフラグのロング名

説明

AP_SPHERE_URL

-s

-sphereUrl

スフィアのURL。http://hostname:port/apcentral/sphere/
.NETの例: http://host:port/apcentral/sphere/soa.asmx

AP_USER_LOGIN

-l

-userLogin

次のいずれかの形式のスフィアのログイン資格証明。
username:password

credName=myCredentialName

通常、これらは管理権限を持つユーザーの資格証明です。

詳細は、12.3.1項「認証およびロール・マッピング」を参照してください。

encryptPasswordコマンドを使用して、CLIで使用するパスワードを暗号化できます。

10.1.6 属性名

CLIコマンドには、属性名をフラグ値として渡す必要があるものが多くあります。この項では、様々なオブジェクト・タイプの有効な属性名を示します。

エンドポイント属性

名前

名前

名前

エイリアス

friendlyName

operationsNote

binding

gateway

qualifiedName

businessContact

genericNote

relativeLocation

businessNote

genre

service

contact

interface

serviceQName

container

isAlive

relativeLocation

defaultCredentials

lastIsAliveChangeDate

service

dependsOnEndpoint

lastManagementChangeDate

serviceQName

デプロイメント

lastManagementChangeIdentity

serviceDescriptionURL

description

lastUpdateIdentity

supportContact

endpointAppProtocol

lastUpdateMarker

supportNote

endpointSoftwareType

location

targetEndpoint

endpointSource

managingIntermediaries

technicalContact

endpointTransportProtocol

note

technicalNote

endpointType

操作

testingNote

firstRegistryDate

operationsContact

uddiBusinessKey

--

--

uddiKey

操作属性

名前

dependsOn

operationName

operationType

propertyOverrides

インタフェース属性

名前

名前

名前

businessContact

name

supportNote

businessNote

namespace

technicalContact

classifications

note

technicalNote

contact

操作

testingNote

description

operationsContact

uddiBusinessKey

friendlyName

operationsNote

uddiKey

genericNote

owningEndpoint

--

lastUpdateIdentity

sourceType

--

lastUpdateMarker

supportContact

--

インタフェース操作属性

名前

classification

documentation

operationName

operationType

プロパティ

sampleMessageNotes

サービス属性

名前

名前

名前

alive

lastIsAliveChangeDate

serviceSource

applicationGroup

lastManagementChangeDate

serviceType

businessContact

lastManagementChangeIdentity

supportContact

businessNote

lastUpdateIdentity

supportNote

category

lastUpdateMarker

technicalContact

contact

managedDescriptionURL

technicalNote

deploymentNames

note

testingContact

description

操作

testingNote

documentation

operationsContact

uddiBusinessKey

endpoints

operationsNote

uddiKey

firstRegistryDate

organization

version

friendlyName

originalDescriptionURL

--

lastDeployDate

primaryDeploymentName

--

lastDeployIdentity

qualifiedName

--

トランザクション属性

トランザクション属性はfriendlyNameのみです。

コンテナ属性

名前

名前

名前

administratorUI

lastIsAliveChangeDate

phaseInLifeCycle

baseAddress

lastDeployIdentity

supportContact

businessContact

lastDiscoveryDate

supportNote

businessNote

lastManagementChangeDate

technicalContact

connectionLimit

lastManagementChangeIdentity

technicalNote

contact

lastUpdateIdentity

testingContact

containerInfo

lastUpdateMarker

testingNote

firstRegistryDate

note

uddiBusinessKey

friendlyName

operationsContact

uddiKey

genericNote

operationsNote

--

hostName

osName

--

implementationType

osVersion

--

ipAddress

owner

--

isAlive

performanceRating

--

デプロイメント属性

名前

名前

名前

businessContact

isAlive

supportContact

businessNote

lastDeploymentDate

supportNote

contact

lastDeploymentIdentity

technicalContact

container

lastIsAliveChangeDate

technicalNote

deploymentCategory

lastUpdateIdentity

testingContact

deploymentStatus

lastUpdateMarker

testingNote

deploymentType

note

uddiBusinessKey

description

operationsContact

uddiKey

firstRegistryDate

operationsNote

--

friendlyName

pluginAgentPossible

--

genericNote

pluginAgentPossibleText

--

連絡先ID属性

名前

emailAddress

informationURL

name

phoneNumber

usage

ノート・タイプ属性

theNoteおよびusageの2つの属性名があります。

説明属性

contactsおよびnotesの2つの属性名があります。

10.2 addBaseAddressAlias

addBaseAddressAliasコマンドを使用して、指定のベース・アドレスを持つエントリ・ポイントの指定された別名を追加します。

この別名をベース・アドレスとして持つ他のエントリ・ポイントがすでにスフィアで認識されている場合には、2つのエントリ・ポイントとそのコンテンツがマージされ、重複したWSDLとエンドポイントは削除されます。

addBaseAddressAliasコマンドで実行される内容は、removeDuplicateEndpointコマンドでベース・アドレスのみが異なる2つのエンドポイントを指定した場合と同じになります。

-forceオプションを使用すると、エントリ・ポイントとその別名が作成された後に、このエントリ・ポイントに対応するすべてのエンドポイントが検出または登録されるため、重複エンドポイントが(誤って)作成されること自体がなくなります。

addNodeAliasコマンドにより作成される別名とは異なり、addBaseAddressAliasコマンドまたはremoveDuplicateEndpointコマンドにより作成される別名は単一のエントリ・ポイントに適用されます。ネットワーク・ノード・レベルで、同じ別名がメッセージの監視または検出により自動的に、またはaddNodeAliasコマンドにより手動で追加されると、ローカルで定義されたエントリ・ポイントの別名がその別名で置き換えられ、この別名を、removeBaseAddressAliasコマンドを使用して削除することはできません。

このコマンドで定義する変更をコミットする前に、コマンドの結果をプレビューできます。プレビュー後、実際に変更を実行するには、-Pオプションを指定せずにもう一度コマンドを実行する必要があります。

addBaseAddressAliasコマンドにより作成した別名を削除するには、removeBaseAddressAliasコマンドを使用します。

12.7項「検出問題の解決」では、このコマンドを使用して検出の問題を解決する方法について説明しています。

コマンド構文

btmcli addBaseAddressAlias -baseAddress address -alias address [-P] [-f]
-s sphereURL -l username:password

名前

ロング名

説明

-baseAddress

--

スフィアにある既存のエントリ・ポイントのベース・アドレス。scheme://host:port/という形式を使用します。

-alias

--

前述のエントリ・ポイントの別名として使用するベース・アドレス。

-P

-preview

コマンドの結果をプレビューしますが、実際にはモデルを変更しません。

-f

-force

指定のベース・アドレスを持つエントリ・ポイントが存在しない場合に、それを作成します。このオプションを使用して、重複エンドポイントが検出される前に、システムに別名を指定します。

-s

-sphereUrl

スフィアのURL。http://hostname:port/btmcentral/sphere/
スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、addBaseAddressAliasコマンドを示します。

btmcli addBaseAddressAlias -baseAddress http://jbujes:8080
-alias http://1.2.3.4:8080 -s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.3 addNodeAlias

addNodeAliasコマンドを使用して、正規名で示されるネットワーク・ノードに指定された別名を追加します。ノードが存在しない場合は、ノードも作成される-forceオプションを指定しないかぎり、別名は追加されません。

addNodeAliasコマンドで作成される別名を削除するには、removeNodeAliasコマンドを使用します。

このコマンドを使用して検出の問題を解決する方法の詳細は、12.7項「検出問題の解決」を参照してください。

コマンド構文

btmcli addNodeAlias -n nodeName -alias aliasName [-f]
-s sphereURL -l username:password

名前

ロング名

説明

-n

-name

ネットワーク・ノードの正規名。通常は完全修飾ドメイン名です。たとえば、jbujes-myPC.edgility.comです。

-alias

-alias

ネットワーク・ノードの別名。これには、ドメイン名または静的IPアドレスを指定できます。

-f

--

ネットワーク・ノードが不明の場合でも、別名(およびその正規ネットワーク・ノード)を強制的に作成します。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、addNodeAliasコマンドを示します。

btmcli addNodeAlias -n jbujesPC.edgility.com -alias Athena
-s http://localhost:8080/btmcentral/sphere/ -l admin:abracadabra

10.4 addPathAlias

addPathAliasコマンドを使用して、指定のWSDLまたはエンドポイントにアクセスするときに使用できる代替URLパスを表す別名を追加します。この別名を指定すると、検出時にアーティファクトが重複して作成されないようにできます。

通常、パス別名は次のいずれかの状況で自動的に追加されます。

- registerコマンドがHTTPリダイレクトを検出し、リダイレクトされたURLで作成されたサービス記述子に元のURLを別名として追加する場合。

- ユーザーがremoveDuplicateEndpointコマンドを使用して、既存エンドポイントについて、非正規URLで監視されているメッセージ・トラフィックが原因で作成された不要な重複を削除する場合。

2番目の状況では、元のエンドポイントが登録または検出されるときに別名を追加することで、重複の作成を防止できます。したがって、テストでこの問題が観測された環境の再作成に使用されたスクリプトに、addPathAliasコマンドを追加することができます。

addPathAliasコマンドで作成される別名を削除するには、removePathAliasコマンドを使用します。

ホスト名の別名についてはaddNodeAlias、WSDLのURLのオーソリティにおける他の別名についてはaddBaseAddressAliasも参照してください。

このコマンドの使用方法の詳細は、「検出問題の解決」の項を参照してください。

コマンド構文

btmcli addPathAlias -s wsdlUrl | -e endpointUrl -alias pathAlias
-s sphereUrl -l username:password

名前

ロング名

説明

-w

-wsdlUrl

別名を追加するWSDL (サービス記述子)の完全URL。

-e

-endpointUrl

別名を追加するエンドポイントの完全URL。複数のエンドポイントが一致する場合は、そのすべてに別名が追加されます。

-alias

--

同じ記述子またはエンドポイントにマップされる代替パス。これは、/で始まるURLのパス部分のみです。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、addPathAliascommandを示します。

btmcli addPathAlias -e http://jbujes:7001/bookmart/credit/CreditService
-alias /bookmart/amex/CreditService
-s http://jbujes:8080/btmcetnral/sphere/ -l admin:abracadabra

10.5 configure

configureコマンドを使用して、Business Transaction Managementを、ブラウザベースの構成ウィザードのかわりに初期構成に使用するように構成します。configureコマンドは、Business Transaction Managementの様々な設定を含む入力ファイルとともに使用します。

configureコマンドを実行する前に、組込みデータベースとOracle Databaseのいずれに情報を保存するかを決定する必要があります。Oracle Databaseに情報を保存する場合は、configureコマンドを実行する前にデータベースをインストールして設定する必要があります。

構文の説明に続く項では、構成プロセスおよび入力ファイルに関する追加情報を示します。

コマンド構文

btmcli configure -i inputFile -sphereUrl -l username:password

名前

ロング名

説明

-i

-inputFile

Business Transaction Managementインストールの構成に使用する構成ファイルへのパス。

-s

-sphereUrl

構成するスフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、configureコマンドを示します。

btmcli configure -i myConfigFile.xml -s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.5.1 configureコマンドの動作

configureコマンドは、すべてのBusiness Transaction Managementサービスについて、現在の構成の状態を確認します。すべてのサービスが構成済の状態である場合、コマンドは終了し、Business Transaction Managementが構成済であることをユーザーに通知します。構成済のサービスと未構成のサービスが混在している場合、configureコマンドは未構成のサービスの構成を試みます。エラーまたは例外が発生した場合は、Business Transaction Managementによりエラーが記録され、構成は続行します。configureコマンドが完了すると、成功および失敗したサービス構成をすべて示すメッセージが返されます。

すべてのBusiness Transaction Managementサービスが正常に構成された場合、このコマンドから構成済のメッセージが返されます。

エラーが発生した構成試行の後で、もう一度configureコマンドを実行でき、実行すると、前回の構成試行でエラーが返されたサービスの構成がシステムにより試行されます。configureコマンドでは、構成の成功が報告されたサービスの再構成は行われません。

正常に構成されたサービスを再構成するには、getSetupDataおよびputSetupDataコマンドを実行します。

Business Transaction Managementサービスを再構成した場合は必ず、サーバーを再起動する必要があります。

10.5.2 構成ファイル

ブラウザベースの構成ウィザードを使用してBusiness Transaction Managementをインストールおよび構成した場合、essentialConfiguration.xmlという名前の構成ファイルが作成されます(各種プラットフォーム上での場所は、12.4項「Business Transaction Managementのバックアップおよびリストア」を参照してください)。このファイルは、新規Business Transaction Managementシステムを初期化する際の出発点として使用でき、この場合、目的の設定を指定するようにファイルの内容を変更する必要があります。このファイルがconfigureコマンドの入力ファイルになります。構成ファイル内のプリファレンス名およびその値では、いずれも大文字と小文字が区別されます。

構成ウィザードとは異なり、configureコマンドでは、構成の途中で停止して後で構成を再開することができません。必須パラメータがファイルに含まれていないとconfigureコマンドによってエラーが返されるため、configureコマンドには完全な構成ファイルが必要です。

パスワードの暗号化

構成ファイルに暗号化されたパスワードを設定するには、encryptPasswordコマンドを実行し、生成された値をコピーして構成ファイルに貼り付けます。

構成ファイルで平文のパスワードを使用した場合、Business Transaction Managementでは、該当するシステム・サービスの設定データに構成情報を保存するときにパスワードが暗号化されます。

構成ファイルのパラメータ

次の表に、configureコマンドの構成ファイルで使用するパラメータを示します。

別名のプリファレンス

Business Transaction Managementの一元的サービス(スフィア、パフォーマンスおよびトランザクション監視)を実行しているノードの別名値を指定できます。いずれの場合も、プリファレンス値は、それぞれのサーバー上のサービスにアクセスするために使用できる代替DNS名/IPアドレスのカンマ区切りリストです。

たとえば、スフィアURLがhttp://server1:8080/apcentral/sphere/ですが、server1マシンにspherehostというDNS別名もある場合、これを反映するためにsphereAliasesをspherehostに設定できます。マシンのプライマリIPアドレスは10.10.22.44ですが、スフィアのコンテナがすべてのlPアドレスをリスニングしており、マシンに10.10.22.47で実行されている2つ目のネットワーク・インタフェースがある場合は、これらの両方の別名を反映するためにsphereAliasesにspherehost, 10.10.22.47を設定します。

Business Transaction Managementの一元的サービスがすべて同じコンテナで実行されている場合(デモの例)、performanceAliasesおよびtransactionAliasesは無視されます。サーバーが異なるコンテナで実行されているものの、スフィアと同じマシン上である場合、別名は同じノード定義に適用されます。したがって、実際には、パフォーマンスおよびトランザクションの別名は個別に追跡されるのではなく、スフィアの別名に追加されます。

注意: すべてのパラメータはtype=booleanですが、acceptLicenseTermsパラメータは例外でtype=stringです。

パラメータ名

必須かどうか

説明

sphereUrl

はい

構成するスフィアのURL。スフィアはbtmMainにデプロイされます。
値は、configureコマンドの-sフラグで指定される値と同じである必要があります。

http://hostname:port/btmcentral/sphere/

databaseChoice

はい

Business Transaction Managementデータベースで使用するデータベースのタイプを示します。
次のいずれかを使用します。

- embedded (Javaプラットフォームの場合のみ)

- oracle

embeddedを指定すると、それ以降のデータベース設定はすべて無視されます。

nodeAliases

いいえ

スフィアを実行しているノードの別名。
前述の別名のプリファレンスの説明を参照してください。

performance.nodeAliases

いいえ

パフォーマンス・サーバー(btmperformance.war)を実行しているノードの別名。
前述の別名のプリファレンスの説明を参照してください。

transaction.nodeAliases

いいえ

トランザクション・サーバー(btmexmrt.war)を実行しているノードの別名。
前述の別名のプリファレンスの説明を参照してください。

deploymentUsername、deploymentPassword

はい

Business Transaction Managementサービスの中には検出を実行するためにアプリケーション・サーバーと通信するものがあり、これらのサービスはアプリケーション・サーバーの管理ユーザーにマップされている一連の管理資格証明を必要とします。
これは、Tomcatを除くすべてのアプリケーション・サーバーで必須です。

agentServiceDB_databaseUrl、agentServiceDB_provider、agentServiceDB_userName、agentServiceDB_password

いいえ

エージェント・メッセージ・ログ・データベース。デフォルトでは、コンテナ内のすべてのエージェントがこのデータベースにログを記録します。この動作は初期構成後にオーバーライドできます。12.2.2項「メッセージ・ログ・データベースの設定」を参照してください。
databaseChoiceがEmbeddedの場合、これは必須です。

sphereServiceDB_databaseUrl、sphereServiceDB_provider、sphereServiceDB_userName、sphereServiceDB_password

いいえ

スフィア・データベース設定。
databaseChoice != Embeddedの場合は必須です。

exmServiceDB_databaseUrl、exmServiceDB_provider、exmServiceDB_userName、exmServiceDB_password

databaseChoice != Embeddedの場合は必須です。

例外管理コンポーネント・データベース設定。
databaseChoice != Embeddedの場合は必須です。

performanceDB_databaseUrl、performanceDB_provider、performanceDB_userName、performanceDB_password

databaseChoice != Embeddedの場合は必須です。

パフォーマンス・コンポーネント(SLM)データベース設定。
databaseChoice != Embeddedの場合は必須です。

performanceUrl

はい

Business Transaction Managementのパフォーマンス(SLM)コンポーネントに接続するために使用するURL (このコンポーネントはbtmPerformanceServerにデプロイされます)。パフォーマンス・コンポーネントは、構成時に実行されている必要があります。
btmPerformanceServerは通常、スフィアとは別のコンテナにデプロイされます。performanceURLをスフィアとは別のノードに指定した場合、Business Transaction Managementはリモート・コンテナもスフィアに登録します。

transactionURL

いいえ

Business Transaction Managementのトランザクション・コンポーネントに接続するために使用するURL (このコンポーネントはbtmTransactionServerにデプロイされます)。トランザクション・コンポーネントは、構成時に実行されている必要があります。
btmTransactionServerは通常、スフィアとは別のコンテナにデプロイされます。transactionURLをスフィアとは別のノードに指定した場合、Business Transaction Managementはリモート・コンテナもスフィアに登録します。

base_locationType、base_directory、
base_maxDuration、base_maxSize、base_numFiles

オプション

デフォルトでは、トレース・ログ・ファイルはBTMStorageRoot/deployment_name/system_service/logdirディレクトリに保存されます。
BTMStorageRootはアプリケーション・サーバーによって異なります(詳細は、12.4項「Business Transaction Managementのバックアップおよびリストア」を参照)。

別の場所にトレース・ログ・ファイルを保存するには、次に示すパラメータを使用します。

注意: これらのパラメータは、aqms、通知およびドメインの各システム・サービスのトレース・ログ・ファイル設定には影響しません。

- base_locationType: この必須パラメータの値は、defaultまたはcustomである必要があり、値がcustomの場合は、base_directoryパラメータに値を指定する必要があります。

- base_directory: Business Transaction Managementがログ・ファイルを作成するディレクトリです。base_locationType = customの場合、このパラメータに値を指定する必要があります。base_locationType = defaultの場合は、このプリファレンスを使用しないでください。

注意: 前述のパラメータを使用してディレクトリの場所を変更した場合、base_maxDuration、base_maxSizeおよびbase_numFilesパラメータ設定も含める必要があります。

- base_maxDuration: ログ・ファイルの存続時間。この存続時間に達したログ・ファイルはローテーションされます(管理コンソールを使用してBusiness Transaction Managementを構成した場合、デフォルト設定は168です)。

- base_maxSize: すべてのログ・ファイルの合計サイズ(KB単位)。ログ・ファイルがこの設定より大きくなると、ログ・ファイルのローテーションが実行されます(管理コンソールを使用してBusiness Transaction Managementを構成した場合、デフォルト設定は50000です)。

- base_numFiles: 同時に存在できるログ・ファイル数(管理コンソールを使用してBusiness Transaction Managementを構成した場合、デフォルト設定は7です)。base_maxSizeおよびbase_numFilesは、各ログ・ファイルの最大サイズを指定します。特定のファイルでこのサイズに達すると、そのファイルのローテーションが実行されます。

10.6 configureAlivenessCheck

configureAlivenessCheckコマンドを使用して、コンテナまたはエンドポイントの稼働ステータスをスフィアがチェックするかどうか、およびチェックする場合に優先されるメソッドを指定します。

コマンド構文

btmcli configureAlivenessCheck -baseAddress baseAddress | -e epUrl1 [[epUrl2]...]
-method standard | skip | getwsdl |geturl | ping
[-alternateUrl alternateUrl]
[-endpointDreds username:password]
[-pingHostPort host:port]
-s sphereUrl -l username:password

名前

ロング名

説明

-baseAddress

--

稼働ステータス・チェックを構成するベース・アドレス。このフラグの効果は、-methodフラグの設定によって異なります。
-methodがstandard、geturlまたはpingに設定されている場合、ベース・アドレスは1回のみテストされ、このベース・アドレスにあるすべてのエンドポイントがこのベース・アドレスの稼働ステータス値を継承します。

-methodがgetwsdlに設定されている場合、指定されたベース・アドレスの各エンドポイントがそれぞれのWSDLをフェッチします。

-methodがskipに設定されている場合、このベース・アドレスに対して稼働ステータス・チェックは実行されませんが、-eまたは-alternateUrlフラグも指定されていれば、このベース・アドレスのエンドポイントが個別にチェックされます。

-e

-endpointUrl

稼働ステータス・チェックを構成する1つ以上のエンドポイントURL。指定したURLのすべてのエンドポイントが同一に構成されます。

-method

--

稼働ステータス・チェックに使用するメソッド。次のいずれかを選択します。standard: 指定されたhost:portへのソケットをオープンおよびクローズします。
skip: 稼働ステータスをチェックしません。

getwsdl: エンドポイントのWSDLに対してHTTP GETを実行します。

geturl: 指定のURLに対してHTTP GETを実行します。

ping: -pingHostPortフラグで指定されたホストおよびポートに対してTCP pingを実行します。

詳細は、後述の説明を参照してください。

-alternateUrl

--

ベース・アドレスまたはエンドポイントURLのかわりに使用するURL。geturlメソッドを使用する場合、このフラグは必須です。

-endpointCreds

--

エンドポイントの代替URLをフェッチするときに使用する認証の資格証明(username:password)。その他の構成の場合には無視されます。

-pingHostPort

--

エンドポイントURLの実際のベース・アドレスのかわりにpingを送信するホストおよびポート。このフラグは、メソッドにpingを指定した場合にのみ必須です。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定に使用できる様々なオプションの詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

監視するエンドポイントに最も適したメソッドを選択してください。たとえば、WebLogic JAX_RPCまたはJAX-WSサービスの場合、生成されたWSDLのフェッチは、コンテナが稼働中で、かつサービスがデプロイ済で稼働中である場合に成功するため、稼働ステータス・チェックは、有効かつ無害なサンプル・メッセージを送信する手間をかけることなく、実際にサービスをコールするのと同等の役割を果たします。任意のhttpフェッチ(geturl)と比較した場合のgetwsdlメソッドの利点は、ベース・アドレス・レベルでこれを指定することで、エンドポイントごとにconfigureAlivenessCheckコマンドを実行しなくても、独自のwsdlをフェッチするようにそのベース・アドレスの各エンドポイントの稼働ステータス・チェックを構成した場合と同じ結果が得られることです。しかし、次のような短所もあります。

- 効率の損失が生じます(WSDLのサイズが大きくなり、多くのリソース・コストがかかるようになる可能性があります)。

- 別のサーバーから手動作成またはコピー(あるいはその両方)されたWSDLのコピーから登録されたエンドポイントには適していません(これが該当する場合は、エンドポイントではなくそのHTTPサーバーの稼働ステータスをチェックしていることがになるためです)。

- WSDLがスフィアにテキストとして保存されている、オブザーバにより検出されたエンドポイントには適していません(これが該当する場合は、スフィアの稼働ステータスをチェックしていることになるためです)。

例

次の例に、稼働ステータス・チェックを実行する、getwsdlメソッドが指定されたconfigureAlivenessCheckコマンドを示します。

btmcli configureAlivenessCheck -baseAddress http://jbujesPC:8080 -method getwsdl
-s http://localhost:8080/btmcentral/sphere/ -l admin:abracadabra

10.7 createOrUpdateGenre

createOrUpdateGenreコマンドを使用して、指定されたサービス・ジャンルまたはエンドポイント・ジャンルの定義をスフィアで作成または更新します。ジャンル・オブジェクトは、わかりやすい名前やアイコンといった、サービスおよびエンドポイント・タイプ情報を適切に表示するために必要な情報を提供します。

一般的に、このコマンドはオブザーバがオフサイクルでリリースされた場合に使用されます。そのような場合、新規ジャンルの認識方法およびそのタイプのサービスまたはエンドポイントを表示する方法を現行システムに指示するために使用するcreateOrUpdateGenreコマンドに関する明示的な説明が示されます。

コマンド構文

btmcli createOrUpdateGenre -n name -id id
-t service | endpoint [iconUrl iconUrl]
-overwrite
-sphereUrl -l username:password

名前

ロング名

説明

-n

-name

ユーザーに対して表示されるジャンルの名前(わかりやすい名前)。慣例では、ジャンルのIDとして使用される修飾名のローカル名とするのが一般的です(IDがQNameとして指定された場合)。
指定された値は、サービスおよびエンドポイントの「タイプ」フィールドに表示される文字列として使用されます。たとえば、WEB_SERVICE、JAXRPC、DATABASEです。

-id

--

ジャンルの一意の識別子。慣例では、urn:com.amberpoint.servicegenresというネームスペースを持つ修飾名として指定することが一般的です。この値は、サービスまたはエンドポイント(あるいはその両方)の検出時にオブザーバから返されるジャンル識別子と一致している必要があります。例: urn:com.amberpoint.servicegenres:JAXRPC

-t

-type

このジャンルがサービス・タイプとエンドポイント・タイプのどちらを表しているかを示します。

-iconUrl

--

管理コンソールでジャンルを示すために使用されるアイコンの場所をシステムに示すURL。
どのジャンルにも2つのアイコン・ファイルがあります。ファイル名はgreyTypeIcon.extおよびgreyTypeOperationIcon.extで、extの値はアイコン・ファイルのタイプ(gif、bmp、jpegまたはpng)を示します。Typeの値はEndpointまたはServiceのいずれかです。

- 接頭辞asc://を含むURLは、アイコンがbtmuiアプリケーションのviews/images/genre/urlPathディレクトリ内にあることを示します。

- その他のURLは、アイコン・ファイルのURLのベースとして直接使用されます。

-overwrite

--

同じIDの既存ジャンルを置き換えることができるかどうかを示すスイッチ。更新の実行時には、このスイッチを指定する必要があります。

-s

-sphereUrl

取得する設定データを持つサービスが登録されているスフィアのURL。http://hostname:port/btmcentral/sphere/
スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、createOrUpdateGenreコマンドを使用して、MyGenreというエンドポイント・タイプを作成する方法を示します。

btmcli createOrUpdateGenre -name MyGenre
-id urn:com.aberpoint.servicegenres:MyGenre
-s http://localhost:8080/btmcentral/sphre/
-l admin:abracadabra

10.8 createOrUpdatePolicy

createOrUpdatePolicyコマンドを使用して、指定されたポリシーをスフィアで直接作成または更新します。

ポリシーの作成または更新には、次の3つの手順が必要な場合があります。

1. createSettingsDocumentコマンドを使用してテンプレート設定ドキュメントを生成します。

2. 作成中のポリシーに必要な値を提供するように、生成されたドキュメントを編集します。

3. 手順2で作成した設定ドキュメントを指定して、createOrUpdatePolicyコマンドを使用してポリシーを作成します。

新規ポリシーを作成するために指定する必要があるのは、テンプレート名、タイプおよび名前のみです。ポリシーに設定が必要な場合は、設定ドキュメントも指定する必要があります。追加情報を指定して、ポリシーの初期状態を指定するためのソース・テンプレートをより正確に識別できますが、これは必須ではありません。

ポリシーを更新するには、名前、タイプ、-overwriteフラグおよび更新する要素の引数を指定する必要があります。指定しない値は変更されません。ポリシー名およびバージョンによりポリシーが識別されるため、このコマンドを使用してこれらを変更することはできません。かわりに、目的の名前またはバージョン(あるいはその両方)を指定して新規ポリシーを作成します。

コマンド構文

btmcli createOrUpdatePolicy [-templateName templateName]
[-t type][-subType subType] [-templateVersion version]
-n name [-V version] [-desc description]
[-settings settingsDocument]
[-criteria criterion1 [criterion2]...]
[-enable] | [-disable]
[-overwrite] [-f]
[-s sphereUrl] -l username:password

名前

ロング名

説明

-templateName

--

新規ポリシーのベースとなるテンプレートの名前。
更新の実行時は、このパラメータは無視されます。

-t

-type

新規ポリシーのポリシー・タイプ。
このパラメータは、指定されたポリシーがすでに存在するかどうかを判別するためにも使用されます。

-subType

--

新規ポリシーのポリシー・サブタイプ。
このパラメータは、指定されたポリシーがすでに存在するかどうかを判別するためにも使用されます。

-templateVersion

--

ポリシーを作成するときのベースとなるテンプレートのバージョン。
更新の実行時は、このパラメータは無視されます。

-n

-name

新規ポリシーの名前。
このパラメータは、指定されたポリシーがすでに存在するかどうかを判別するためにも使用されます。

-V

-version

新規ポリシーのバージョン。
このパラメータは、指定されたポリシーがすでに存在するかどうかを判別するためにも使用されます。

-desc

-description

ポリシーの説明。

-settings

-settingsDocument

createSettingsDocumentコマンドで作成される、ポリシーの設定ドキュメント。

-criteria

--

ポリシーの適用基準のリスト。各基準の形式は後述します。

-enable

--

ポリシーを有効とマークします。

-disable

--

ポリシーを無効とマークします。

-overwrite

--

ポリシーがすでに存在する場合、指定された情報でそのポリシーを更新する必要があることを示します。

-f

-force

ポリシーが内部的に更新不可とマークされている場合でも、ポリシーを更新します。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

適用基準

ポリシーを作成または変更するときに、どの監視対象オブジェクトにポリシーを適用できるかを判別するために使用する一連の基準を指定できます。各基準の形式は、次のとおりです。

monitoredObjectType [;query [,{UNION | EXCLUDE}]]+

基準の指定方法の詳細は、http://www.oracle.com/support/contact.htmlを参照するか、聴覚に障害のあるお客様は、http://www.oracle.com/accessibility/support.htmlをご利用ください。

例

次の例に、createOrUpdatePolicyコマンドを使用して、MyPolicyという既存ポリシーの施行を可能にする方法を使用します。

btmcli createOrUpdatePolicy -name MyPolicy -enable
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.9 createSettingsDocument

createSettingsDocumentコマンドを使用して、createOrUpdatePolicyコマンドへの入力として使用する設定ドキュメントを作成します。

設定ドキュメントはXMLファイルです。設定ドキュメントのソースには、ポリシー・テンプレートまたは既存ポリシーを指定できます。

- ポリシー・テンプレートを指定した場合、コマンドによって、そのポリシー・テンプレートのデフォルト設定ドキュメントが返されます。

- ポリシーを指定した場合、コマンドによって、現行のポリシー・インスタンスの設定を持つ設定ドキュメントが返されます。設定ドキュメントをcreateOrUpdatePolicyコマンドに発行する前に、設定ドキュメントの値を編集できます。

ポリシーまたはポリシー・テンプレートのタイプおよびサブタイプを判別するには、ナビゲータで適切なオブジェクトを選択します。各ポリシーまたはポリシー・テンプレートのタイプおよびサブタイプがサマリー・ペインに表示されます。

コマンド構文

btmcli createSettingsDocument -n name [-t type] [-subType subType[ [-V version]
-fromPolicy [-o outputFile]
-s sphereUrl -l username:password

名前

ロング名

説明

-n

-name

その設定ドキュメントを使用するテンプレートまたはポリシーの名前。

-t

-type

その設定ドキュメントを使用するポリシー・テンプレートまたはポリシーのタイプ。

-subType

--

その設定ドキュメントを使用するポリシー・テンプレートまたはポリシーのサブタイプ。

-V

-version

その設定ドキュメントを使用するポリシー・テンプレートまたはポリシーのバージョン。

-fromPolicy

--

テンプレートではなく、既存のポリシー・インスタンスを使用して設定ドキュメントを作成する必要があることを示します。

-o

-outputFile

設定ドキュメントが書き込まれるファイル。これを指定しない場合、設定ドキュメントは標準出力に送信されます。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、createSettingsDocumentコマンドを使用して、MySettingsDocという設定ドキュメントを作成する方法を示します。

btmcli createSettingsDocument -namemySecurePolicy -o mySettingsDoc
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.10 credStoreTool

credStoreToolコマンドを使用して、資格証明ストアから資格証明を作成、取得または削除します。このコマンドを使用すると、次の3種類の資格証明を作成できます。

- username:password形式に基づく資格証明。
この資格証明は、btmcliコマンドにアクセスするために使用します。ほぼすべてのコマンドでユーザー名とパスワードが必要です。

- 信頼できる発行者と秘密に基づく資格証明。
Business Transaction Managementコンポーネントでは、このタイプの資格証明を使用してコンポーネント間の信頼関係を確立します。

- バイナリ資格証明(システム・デフォルト暗号化鍵のAES鍵)。
AES暗号化鍵は、Business Transaction Managementコンポーネント間で送信される機密データを暗号化する場合、またはその機密データがデータベースまたはディスクに保存される場合に使用されます。

このコマンドを使用するには、その前に、『Business Transaction Managementインストレーション・ガイド』の説明に従ってOracle Java Platform Securityクラスをインストールして構成する必要があります。

credStoreToolコマンドの構文は、使用する資格証明のタイプによって異なります。後続の項では、資格証明の種類ごとに構文およびパラメータ情報を示します。

いずれの場合も、このコマンドを使用して、資格証明を作成したり、別のサーバーにコピーする必要がある場合に資格証明を取得したり、資格証明を削除することができます。

10.10.1 user:password資格証明の使用方法

このオプションは、コマンドライン自体またはスクリプトでユーザー名およびパスワードを指定するよりも安全です。この資格証明を使用してbtmcliコマンドにアクセスする方法の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

コマンド構文

btmcli credStoreTool -createCred credName [-credType up]
[credValue username:password]

btmcli credStoreTool -getCred credName [-credType up] [-showPwd]

btmcli credStoreTool -deleteCred credName [-credType up]

名前

説明

-createCred

作成する資格証明の名前を指定します。

-getCred

取得する資格証明の名前を指定します。

-deleteCred

削除する資格証明の名前を指定します。

-credType

作成、取得または削除する資格証明の種類。
デフォルトはupです。

-credValue

このオプションを指定しない場合、ユーザー名とパスワードの入力を求められます。入力したパスワードはアスタリスクで表示されます。

-showPwd

getCredオプションの場合に、ユーザー名とパスワードを表示するかどうかを確認します。

10.10.2 信頼できる発行者と秘密資格証明の使用方法

Business Transaction Managementコンポーネントでは、このタイプの資格証明を使用して信頼関係を確立します。コンポーネントはサービスに対するリクエストを受信すると、それを実行する前に、リクエストの送信元が信頼できるかどうかをチェックします。

コマンド構文

btmcli credStoreTool -createCred credName credType is [-credValue issuer:secret]

btmcli credStoreTool -getCred credName -credType is [-showSecret]

btmcli credStoreTool -deleteCred credName -cretType is

名前

説明

-createCred

作成する資格証明の名前を指定します。

-getCred

取得する資格証明の名前を指定します。

-deleteCred

削除する資格証明の名前を指定します。

-credType

作成、取得または削除する資格証明の種類。

-credValue

このオプションを指定しない場合、発行者と秘密の入力を求められます。入力した秘密はアスタリスクでマスクされます。

-showSecret

getCredオプションの場合に、発行者と秘密を表示するかどうかを確認します。

10.10.3 バイナリ資格証明の使用方法

AES暗号化鍵は、Business Transaction Managementコンポーネント間で送信される機密データを暗号化する場合、またはその機密データがデータベースまたはディスクに保存される場合に使用されます。

コマンド構文

btmcli credStoreTool -createCred credName
-credType bin {credValue Base64-encoded-bytes | -genKey AlgName:KeySize}

btmcli credStoreTool -getCred credName credType bin [-showSecret]

btmcli credStoreTool -deleteCred credName -credType bin

名前

説明

-createCred

作成する資格証明の名前を指定します。

-getCred

取得する資格証明の名前を指定します。

-deleteCred

削除する資格証明の名前を指定します。

-credType

作成、取得または削除する資格証明の種類。

-credValue

バイトのセットを指定します(Base64エンコード)。これらのバイトは、有効な暗号化鍵を表している場合と表していない場合があります。

-genKey

AlgNameは、JCE (Java Cryptographic Extension)用に予約されたアルゴリズム名を表します。現在はAESのみがサポートされています。
KeySizeは、生成する鍵のサイズです。許容される鍵のサイズはアルゴリズムごとに異なります。AESの場合は、(バイト数ではなく)ビット数を表す128、192および256です。128は、基礎となるすべてのプラットフォームの暗号実装でサポートされているため、これが推奨値です。

-showSecret

getCredオプションの場合に、Base64エンコード・バイト自体とともに、バイナリ資格証明のサイズ(バイト単位)を表示するかどうかを確認します。次に例を示します。
16 bytes long ... Base-64 = [qvw1wEOxprSeJf2TbtuK5w==]

このパラメータを指定しない場合、バイト数は表示されません。

10.11 deleteAll

deleteAllコマンドを使用して、すでに検出されているオブジェクトを、トランザクション、プロパティ、登録済サービス、デバイス、コンテナなどの関連アーティファクトとともに削除します。

これは、最初の検出構成によって検出されたオブジェクト数が多すぎたり、関連のないオブジェクトが検出された場合に役立ちます。このコマンドを使用すると、システムを再インストールしたり、監視対象エンティティおよび関連アーティファクトをすべて手動で削除しなくても最初からやりなおすことができます。

注意:
deleteAllコマンドを使用すると白紙の状態になるため、監視対象オブジェクトに関連する履歴データを含め、必要なデータが失われないよう慎重に使用する必要があります。BTMの使用開始時に、検出方式を微調整するために使用するのが最適です。本番環境では使用しないでください。

どのオブジェクトが削除されるかを確認するには、-previewオプションを指定してコマンドを実行します。-previewオプションを指定せずにもう一度コマンドを実行すると、それらのオブジェクトが実際に削除されます。

このコマンドの使用後、検出構成を調整して、希望の結果を生成するためにさらにトラフィックを実行できます。

コマンド構文

deleteAll [-f][-P]-s sphereUrl -l username:password

名前

ロング名

説明

-f

-force

既存のトランザクション定義をすべて強制的に削除します。定義を保持するには、deleteAllコマンドを使用する前にそれらをエクスポートし、検出構成の再定義後に再インポートする必要があります。詳細は、後述の説明を参照してください。

-P

-preview

コマンドを実行せずに、削除されるオブジェクトのリストを表示することによりコマンドの効果を表示します。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

説明

BTMの使用を開始する際、場合によっては、適切な検出構成が見つかるまで何回か試してみる必要があります。deleteAllコマンドを使用すると、簡単にやりなおすことができます。

検出結果が多すぎたり、関連性のない結果が得られることもよくあります。これは通常、SOAベースのアプリケーションやOSB環境の監視を有効にする、デフォルトのプローブ設定をそのまま使用している場合に起こります。

- SOAベースのアプリケーションは、相互接続された多数の内部EJBコンポーネントに依存しています。

- OSB WebLogicアプリケーション・サーバーは多数のサーブレットをホストしており、これらがEJBまたはその他のコンポーネントを呼び出します。

同様に、WEB_APPおよびEJBプローブもデフォルトで有効になっており、これにより、しばらくした後、予想を上回る結果が検出されます。

これらのコンポーネントをすべて表示した場合、情報が多すぎる可能性があります。関連性の高い情報のみに絞り込む必要があります。

また、他の要因によっても、監視結果がわかりにくくなる可能性があります。

- 間違った場所にオブザーバをインストールしている場合。関連性の低いサービスやエンドポイントが検出されます。

- BTMモニターの使用を最適化する方法は、BTMの動作を理解するまでは必ずしも明白ではありません。モニターを追加したり、モニターごとに異なるプローブを再割当てすることがあります。この変更の前後で検出されたオブジェクトは両方とも表示されるようになります。

- デプロイメントを更新した結果、サービスまたはエンドポイントの登録が重複しているように見えるようになります。

要約すると、システムを再インストールしたり、監視対象エンティティおよび関連アーティファクトをすべて手動で削除することなく、最初からやりなおす必要があります。この操作は、deleteAllコマンドを使用して実行できます。

deleteAllコマンドでは、次のものに関するデータが削除されます。

- 非システム・コンテナ

- ユーザー・サービスおよびサービス・インタフェース
ユーザー登録のエンドポイントおよび検出されたエンドポイントが両方削除されます。

- デバイス

- 依存性

- プロパティ

- トランザクション定義(-fオプションを使用した場合)

- オブザーバとそのプローブ(インストールされたビットではなく、スフィアでのその表現のみ)

- 前述の項目に関連して維持されているランタイム・データ
これには、測定および取得されたメッセージ・データが含まれます。

後で必要になる可能性があるトランザクション定義が失われないようにするために、deleteAllコマンドで、それらを強制的に削除するには-forceオプションを使用する必要があります。これらの定義を後で使用する場合は、トランザクションをエクスポートし、検出構成を再定義した後にそれらを再インポートする必要があります。手動の相関を可能にするプロパティを使用している場合、BTMでは、依存性を指定するためにそれらのプロパティを再作成します。

deleteAllコマンドでは、次のものに関するデータは削除されません。

- システムおよびユーザー・ポリシー
これらは、新しく検出および登録されたエンティティに再適用されます。ポリシーを作成し、これらのポリシーが新しく検出されたものには適用されない場合、それらのポリシーを削除する必要が生じます。

- コンシューマ

- スケジュール

- アラート

- システム構成

例

次の例に、deleteAllコマンドを使用して、すべての検出されたアーティファクトおよび関連するアーティファクトをシステムから削除する方法を示します。コマンドの後に出力例を示します。

btmcli deleteAll

Warning: This command will delete your discovered / registered items in BTM. Continue? (y/n) [n]: y
Deleted Services:
OrderService
ShippingService
bookmartClient
PurchasingDB
CreditService
WarehouseService

Deleted Containers:
jmeredit-lap:9200

Deleted Observer Probes:
Web Application
Servlet
Web Service
JAX-RPC
Database
JDBC
JMS Message Consumer
JMS

10.12 encryptPassword

encryptPasswordコマンドを使用して、Business Transaction Management暗号化エンジンを使用して指定したテキスト文字列を変換したり、暗号化されたパスワードを標準出力に書き込みます。

続けて、出力文字列をコピーして貼り付け、資格証明を必要とするコマンドに提供できます。

コマンド構文

btmcli encryptPassword -password aPlainTextPswd

名前

ロング名

説明

-password

--

Business Transaction Management暗号化エンジンを使用して暗号化するテキスト文字列。
同じテキスト文字列を暗号化するたびに生成される出力は、それぞれ一意の暗号文文字列になります。

例

btmcli encryptPasword -password "abracadabra"

10.13 exportBusinessObjects

exportBusinessObjectsコマンドは、ターゲット・スフィアから1つ以上の指定されたビジネス・オブジェクトをエクスポートします。このコマンドにより出力されるXMLドキュメントは、ビジネス・オブジェクトを別のターゲット・スフィアにインポートするために使用できます。

-queryフラグまたは-exportAllフラグを使用して、エクスポートするオブジェクトを指定できます。

コマンド構文

btmcli exportBusinessObjects [-exportAll] | [-query filterQuery ]
[-o outputFile ]
-s sphereUrl -l username:password

名前

ロング名

説明

-exportAll

--

該当するタイプのすべてのオブジェクトをエクスポートします。

-query

-filterQuery

filterQuery式で表される基準に一致するオブジェクトのみをエクスポートします。
フィルタ・ツールを使用して問合せを作成し、その問合せをコピーしてコマンドラインに貼り付けます。

-o

-outputfile

データが書き込まれるXMLファイルの名前。このフラグを省略すると、データは標準出力に書き込まれます。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、exportBusinessObjectコマンドを使用してMyConsumersにデータを出力する方法を示します。

btmcli exportBusinessObject -exportAll -o MyConsumers
-s http://localhost:8080/btmcentral/sphere/
-l admin:password

10.14 exportMessages

exportMessagesコマンドを使用して、ロギングが有効になっている期間のエンドポイントのメッセージをエクスポート(リクエストおよび応答)します。メッセージのエクスポートは、テストおよびデバッグで役立ちます。

オプションで、XMLファイルにメッセージをエクスポートできます。ファイルを指定しない場合、出力はstdoutに送信されます。

重要: このコマンドが動作するには、メッセージ・ロギングが有効になっている必要があります。メッセージ・ロギングの詳細は、5.4項「トランザクションの定義、変更および削除」を参照してください。

コマンド構文

btmcli exportMessages -name name | -e endpointUrl
[-bn bindingName]
-baseDate date -baseTime time -duration minutes
[-outputFile outputFile]
[-max numberOfMessages]
-sphereUrl sphereUrl -l username:password

名前

ロング名

説明

-n

-name

メッセージをエクスポートする対象となるエンドポイントのわかりやすい名前。後述の説明を参照してください。

-e

-endpointURL

エンドポイントのURL。これがWebサービスの場合は、エンドポイントにアクセスする実際のURLを指定できます。それ以外のタイプのコンポーネントの場合は、管理コンソールの「プロファイル」タブを確認して、エンドポイントのURLを特定してください。
後述の説明も参照してください。

-bn

-bindingName

エンドポイントのバインディング(たとえば、SOAP/HTTP)。このパラメータを使用して、複数のバインディングを持つエンドポイントURLを明確化します。

-baseDate

--

メッセージのエクスポート開始時のタイムスタンプで、yyyy-MM-dd形式の日付。

-baseTime

--

メッセージのエクスポート開始時のタイムスタンプで、hh:mm:ss形式の時刻。

-duration

--

ログ・メッセージがエクスポートされる期間を示す、起点時刻からの分数。指定された期間にエクスポートされたメッセージ数が-maxオプションで指定された値を超えた場合は、メッセージがエクスポートされる期間が短縮されることがあります。

-o

-outputFile

メッセージがエクスポートされるファイルのパス名。出力ファイルがすでに存在する場合は、コマンドが失敗します。
絶対パスを指定することをお薦めします。ファイル名のみを指定した場合、ホスト・アプリケーション・サーバーの起動元ディレクトリにファイルが作成されます。

重要: パスを指定した場合、コマンドが動作するのは、Business Transaction Managementをホストするプロセスに、指定されたディレクトリへの書込み権限がある場合のみです。

-max

--

エクスポートするメッセージの最大数。値を指定しない場合、指定された期間すべてのメッセージがエクスポートされます。

-s

-sphereURL

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

メッセージをエクスポートする対象のエンドポイントは、次の方法で指定できます。

- エンドポイントURLが1つのエンドポイントと一意に関連付けられている場合は、-eオプションを使用します。
-eオプションは、レプリケートされたサービスに属するエンドポイントを識別する場合にも役立ち、このようなケースでは、エンドポイント名は一意ではありませんが、エンドポイントURLは一意です。

- エンドポイントのわかりやすい名前を指定するには、-nオプションを使用します。指定された名前でエンドポイントを一意に識別できる場合は、これが優先されるオプションです。

例

次のコマンドは、MyShippingServiceサービスのメッセージをエクスポートします。

btmcli exportMessages -name MyShippingService
-baseDate 2010-3-15 -baseTime 12:15:30 -duration 10
-s http://localhost:8080/btmcentral/sphere/ -l admin:passme

10.15 exportPolicies

exportPoliciesコマンドを使用して、選択されたポリシーをstdoutまたは指定の出力ファイルのいずれかにエクスポートします。エクスポートするポリシーは、次のいずれかの方法で指定します。

- ポリシーの名前: タイプ、サブタイプまたはバージョン(あるいはそのすべて)を使用して、さらに細かく指定できます。

- ポリシーのタイプ: サブタイプまたはバージョン(あるいはその両方)を使用して、さらに細かく指定できます。
ポリシーのタイプおよびサブタイプを判断するには、ナビゲータで「ポリシー」を選択します。各ポリシーのタイプおよびサブタイプがサマリー・ペインに表示されます。

ポリシーをエクスポートしたら、importPoliciesコマンドを使用してそれらを別のスフィアにインポートできます。

すべてのファイルをエクスポートできるわけではありません。スフィア環境間で移行できないデータには、次の項目があります。

- トランザクション管理データベースで収集されたロギング・ポリシー・データ。
管理対象サービスにロギング・ポリシーを適用することにより、収集されてファイルまたはデータベース記憶域のいずれかに書き込まれた情報は移行できません。

- トランザクションで発生した例外的な状況のインスタンス・データ。
AMSのトランザクション管理コンポーネントにより収集された情報は移行できません。

コマンド構文

btmcli exportPolicies
[[-n PName] [-t PType] [-subType PSubType] [-v Version]|[-exportAll]]
[-o fileName]
-s sphereUrl -l username:password

名前

ロング名

説明

-n

-name

エクスポートするポリシーの名前。

-t

-type

エクスポートするポリシーのタイプ。

-subType

--

エクスポートするポリシーのサブタイプ。

-v

-version

エクスポートするポリシーのバージョン。

-exportAll

--

すべてのポリシーをエクスポートすることを指定します。

-o

-outputFile

エクスポートの結果を格納するファイルを指定します。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次のコマンドは、指定されたスフィアで認識されているすべてのポリシーをMyPoliciesというファイルにエクスポートします。

btmcli exportPolicies -exportAll -o C:\Home|MyPolicies
-s http://localhost:8080/btmcentral/sphere/
-l admin abracadabra

10.16 exportPolicyTemplates

exportPolicyTemplatesコマンドを使用して、選択されたポリシー・テンプレートをstdoutまたは指定の出力ファイルのいずれかにエクスポートします。エクスポートするポリシー・テンプレートは、次のいずれかの方法で指定します。

- ポリシー・テンプレートの名前: タイプ、サブタイプまたはバージョン(あるいはそのすべて)の情報を使用して、さらに細かく指定できます。

- ポリシー・テンプレートのタイプ: サブタイプまたはバージョン(あるいはその両方)を使用して、さらに細かく指定できます。
ポリシー・テンプレートのタイプおよびサブタイプを判断するには、ナビゲータで「ポリシー・テンプレート」を選択します。各ポリシー・テンプレートのタイプおよびサブタイプがサマリー・ペインに表示されます。

コマンド構文

btmcli exportPolicyTemplates
[[-n Name][-t Type] [-subType subType][-v TmplVersion]]| -exportAll
[-o fileName]
-s sphereUrl -l username:password

名前

ロング名

説明

-n

-name

エクスポートするポリシー・テンプレートの名前。

-t

-type

エクスポートするポリシー・テンプレートのタイプ。

-subType

--

エクスポートするポリシー・テンプレートのサブタイプ。

-v

-version

エクスポートするポリシー・テンプレートのバージョン。

-exportAll

--

すべてのポリシー・テンプレートをエクスポートすることを指定します。

-o

-outputFile

エクスポートしたデータを格納するファイルを指定します。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次のコマンドは、すべてのポリシー・テンプレートをMyPolicyTemplatesという出力ファイルにエクスポートします。

btmcli exportPolicyTemplates -exportAll -o C:\Home\MyPolicyTemplates
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.17 exportProfile

exportProfileコマンドを使用して、指定されたオブジェクトのプロファイル値をエクスポートします。生成されたプロファイル情報は、指定されたファイルまたはファイルが指定されない場合はstdoutに書き込まれます。オブジェクトのタイプを指定し、さらに名前またはIDを指定することで、エクスポートするオブジェクトを指定します。

importProfileコマンドを使用すると、生成されたXMLファイルを別のスフィアにインポートできます。

コマンド構文

btmcli exportProfile -t objectType
[-n name] [-v version] | [-id id]
[-o fileName]
-s sphereUrl -l username:password

名前

ロング名

説明

-n

-name

エクスポートするプロファイルが属するオブジェクトの名前。

-t

-type

エクスポートするプロファイルが属するオブジェクトのタイプ。タイプには、deployment、service、interface、endpoint、container、DEPLOYMENT、SERVICE、INTERFACE、ENDPOINTまたはCONTAINERのいずれかを指定できます。

-V

-version

エクスポートするプロファイルが属するサービス・オブジェクトのバージョン。

-id

--

エクスポートするプロファイル・データが属するオブジェクトのスフィアID。

-o

-outputFile

エクスポートの結果を格納するファイルを指定します。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次のコマンドは、すべてのコンテナのプロファイル情報をエクスポートします。

btmcli exportProfile -t CONTAINER -o C:\Home|myContainers
-s http://localhost:8080/btmcentral/sphere/ -l admin:pass

10.18 exportSchedules

exportSchedulesコマンドを使用して、ターゲット・スフィアからスケジュールをエクスポートします。スケジュールはファイルまたはstdoutに出力できます。

すべてのスケジュール、特定のスケジュールまたは特定のタイプのスケジュールを指定できます。

エクスポート後、importSchedulesコマンドを使用して別のスフィアにスケジュールをインポートできます。

コマンド構文

btmcli exportSchedules -n Name | -query filterQuery | -exportAll
[-o fileName]
-s sphereUrl sphereUrl -l username:password

名前

ロング名

説明

-n

-name

エクスポートするスケジュールの名前。

-query

-filterQuery

エクスポートする一連のスケジュールを指定するAQL問合せ。
フィルタ・ツールを使用して問合せを作成し、その問合せをコピーしてコマンドラインに貼り付けます。

-exportAll

--

すべてのスケジュールをエクスポートすることを指定します。

-o

-outputFile

エクスポートの結果を格納するファイルを指定します。このフラグを使用しない場合、出力はstdoutに送信されます。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次のコマンドは、指定されたスフィアで認識されているすべてのスケジュールをMySchedulesというファイルにエクスポートします。

btmcli exportSchedules -exportAll -o C:\Home\MySchedules
-s http://localhost/btmcentral/sphere/ -l admin:pass

10.19 exportTransactionDefns

exportTransactionDefnsコマンドを使用して、ターゲット・スフィアで認識されているトランザクション定義をエクスポートします。出力ファイルを指定しない場合、定義はstdoutに送信されます。

エクスポートした定義は、importTransactionDefnsコマンドを使用してインポートできます。

コマンド構文

btmcli exportTransactionDefns [-n Name] [-o fileName]
-s sphereUrl -l username:password

名前

ロング名

説明

-n

-name

エクスポートするトランザクションの名前。この値を指定しない場合、既存のトランザクション定義がすべてエクスポートされます。

-o

-outputFile

エクスポートの結果を格納するファイルを指定します。この値を指定しない場合、出力はstdoutに送信されます。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次のコマンドは、すべてのトランザクション定義をMyTransactionsというファイルにエクスポートします。

btmcli exportTransactionDefns -o C:\Home\MyTransactions
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.20 getSetupData

getSetupDataコマンドを使用して、システム・サービスの設定ファイルを標準出力に書き込みます。

出力をファイルにリダイレクトし、ファイルを変更してから、そのファイルをputSetupDataコマンドの入力として使用してサービス設定データを保存できます。

あるサービスから設定データを取得して、別のサービスに転送することもできます。このコマンドでは、ターゲット・サービスが初期構成されているかは確認されません。

このコマンドを使用してシステムをバックアップする方法の詳細は、12.4項「Business Transaction Managementのバックアップおよびリストア」を参照してください。

コマンド構文

btmcli getSetupData -e endpointUrl -s sphereUrl -l username:password

名前

ロング名

説明

-e

-endpointUrl

システム・サービスの場所(URL)。

-s

-sphereUrl

取得する設定データを持つサービスが登録されているスフィアのURL。http://hostname:port/btmcentral/sphere/
スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、getSetupDataコマンドを示します。

btmcli getSetupData -e http://localhost:8080/apcentral/policyManager
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.21 importBusinessObjects

importBusinessObjectsコマンドは、指定されたXMLファイルで記述されている、1つ以上の指定のビジネス・オブジェクトをターゲット・スフィアにインポートします。現在、定義されているビジネス・オブジェクトはコンシューマ・ビジネス・オブジェクトのみであり、これを使用して、コンシューマごとにトランザクション情報をセグメント化します。

このコマンドでは、デフォルトで、インポートされたオブジェクトより古い既存オブジェクトがすべて置き換えられます。このコマンドを使用して、異なる環境間でデータを移行したり、一連のコンシューマを環境に移入することができます。

インポートするデータは、-inputFile引数または標準入力を使用して指定します。インポートするオブジェクトは、事前にexportBusinessObjectsコマンドを使用してエクスポートされている必要があります。

このコマンドを使用して環境に一連のコンシューマを移入する場合、最も難しいのは有効な入力ファイルの作成です。入力ファイルに設定する適切な形式を推測せずに、これを実行する方法を次に示します。

1. 必要な場合は、カスタム属性を追加してビジネス・オブジェクトをカスタマイズします。

2. 管理コンソールを使用してコンシューマを作成します。

3. 出力ファイルの名前を指定して、exportBusinessObjectコマンドを実行します。手順2で作成したコンシューマに関するデータが、XMLファイルにエクスポートされます。

4. 出力XMLファイルを調べます。ファイルに示されている形式を使用して、ファイルを拡張してさらにコンシューマを追加します。
コンシューマの使用の詳細は、7.1項「コンシューマについて」を参照してください。

コマンド構文

btmcli importBusinessObjects [-i inputFile]
[-replace ALL | all | NEWER | newer | NONE | cleaned | CLEANED]
[-v] -s sphereUrl -l username:password

名前

ロング名

説明

-i

-inputFile

インポートするデータを含むファイルの名前。
入力ファイルには、インポートするビジネス・オブジェクトが1つ以上含まれている必要があります。

-replace

-replacementLevel

インポートしたオブジェクトがシステム内の既存オブジェクトに一致した場合の結果を決定します。
ALL: 既存オブジェクトをすべて置き換えます。

NEWER: インポートしたオブジェクトよりも古い既存オブジェクトを置き換えます。(デフォルト)

CLEANED: 既存のビジネス・オブジェクトをすべて削除してから、新規ビジネス・オブジェクトをインポートします。

NONE: 既存オブジェクトを置き換えません。

-v

-verbose

コマンド実行に関する詳細情報を表示します。

-s

-sphereUrl

スフィアのURL。http://hostname:port/btmcentral/sphere/
スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、importBusinessObjectコマンドを使用してMyConsumersというファイルからデータをインポートする方法を示します。

btmcli importBusinessObject -inputFile MyConsumers -replace ALL
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.22 importPolicies

importPoliciesコマンドを使用して、以前にエクスポートしたポリシーをインポートします。

インポートするポリシーは、エクスポートされたファイルから取得されるか(-inputFileパラメータ)、ファイルが指定されていない場合はstdinから取得されます。

すべてのファイルをインポートできるわけではありません。スフィア環境間で移行できないデータには、次が含まれます。

- トランザクション管理データベースで収集されたロギング・ポリシー・データ。
管理対象サービスにロギング・ポリシーを適用することにより、収集されてファイルまたはデータベース記憶域のいずれかに書き込まれた情報は移行できません。

- トランザクションで発生した例外的な状況のインスタンス・データ。
Business Transaction Managementのトランザクション管理コンポーネントにより収集された情報は移行できません。

このコマンドでは、デフォルトで、インポートされたポリシーより古い既存ポリシーがすべて置き換えられます。

コマンド構文

btmcli importPolicies [-i inputFile]
[-replace ALL | all | NEWER | newer | NONE | none]
[-v] -s sphereUrl -l username:password

名前

ロング名

説明

-i

-inputFile

インポートするデータを含むファイルの名前。

-replace

-replacementLevel

インポートしたポリシーがシステム内の既存ポリシーに一致した場合の結果を決定します。
ALL: 既存ポリシーをすべて置き換えます。

NEWER: インポートしたポリシーよりも古い既存ポリシーを置き換えます。(デフォルト)

NONE: 既存ポリシーを置き換えません。

-v

-verbose

コマンド実行に関する詳細情報を表示します。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、importPoliciesコマンドを使用してMyPoliciesというファイルからデータをインポートする方法を示します。

btmcli importPolicies -inputFile MyPolicies -replace ALL
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.23 importPolicyTemplates

importPolicyTemplatesコマンドを使用して、以前に作成したエクスポート・ファイルに含まれるポリシー・テンプレートをインポートします。インポートするポリシー・テンプレートは、-iパラメータで指定されたファイルから取得されるか、ファイルが指定されない場合はstdinから取得されます。

このコマンドでは、デフォルトで、インポートされたテンプレートより古い既存テンプレートがすべて置き換えられます。

コマンド構文

btmcli importPolicyTemplates [-i inputFile]
[-replace ALL | all | NEWER | newer | NONE | none]
[-v] -s sphereUrl -l username:password

名前

ロング名

説明

-i

-inputFile

インポートするデータを含むファイルの名前。

-replace

-replacementLevel

インポートしたポリシー・テンプレートがシステム内の既存ポリシー・テンプレートに一致した場合の結果を決定します。
ALL: 既存ポリシー・テンプレートをすべて置き換えます。

NEWER: インポートしたポリシー・テンプレートよりも古い既存ポリシーを置き換えます(デフォルト)。

NONE: 既存ポリシー・テンプレートを置き換えません。

-v

-verbose

コマンド実行に関する詳細情報を表示します。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、importPolicyTemplatesコマンドを使用してMyPolicyTemplatesからデータをインポートする方法を示します。

btmcli importPolicyTemplate -inputFile MyPolicyTemplates -replace NONE
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.24 importProfile

importProfileコマンドを使用して、以前のオブジェクト・プロファイルをシステムにインポートします。インポートするプロファイル・データは、指定した入力ファイルまたはファイルが指定されていない場合はstdinから取得されます。

プロファイルをインポートしても新規オブジェクトは作成されず、既存オブジェクトのプロファイル属性が更新されるのみです。たとえば、サービス・プロファイルをインポートしてもサービスが作成されたり、システムに登録されることはなく、(検出または手動の登録により)すでに登録されているサービスのプロファイルが更新されるのみです。

コマンド構文

btmcli importProfile [-i importFile] [-m EXACT | BEST_FIT}
-s sphereUrl -l username:password

名前

ロング名

説明

-i

-inputFile

インポートするプロファイル・データを含むファイルの名前。指定しない場合、コマンドはstdinからデータをインポートします。

--

-match

一連の関連オブジェクトのプロファイルをインポートするときに使用し、インポートされたプロファイルがシステムに現在存在するオブジェクトとどの程度正確に一致している必要があるかを指定します。可能な値は次のとおりです。

- EXACT: インポートしたプロファイルは、カーディナリティおよび構造の両方について、既存オブジェクトと完全に一致している必要があります。

- BEST_FIT: インポートしたプロファイルは、既存オブジェクトに対して可能なかぎり照合されます。カーディナリティまたは構造の不一致は無視されます。これはデフォルト値です。

-s

-sphereUrl

スフィアのURL。http://hostname:port/btmcentral/sphere/
スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、importProfileコマンドを使用してMyContainersからデータをインポートする方法を示します。

btmcli importProfile -inputFile MyContainers -match EXACT
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.25 importSchedules

importSchedulesコマンドを使用して、以前にエクスポートしたスケジュールをターゲット・スフィアにインポートします。

このコマンドでは、デフォルトで、インポートされたスケジュールより古い既存スケジュールがすべて置き換えられます。

コマンド構文

btmcli importPolicyTemplates [-i inputFile]
[-replace ALL | all | NEWER | newer | NONE | none]
[-v] -s sphereUrl -l username:password

名前

ロング名

説明

-i

-inputFile

インポートするデータを含むファイルの名前。これを指定しない場合、データはstdinからインポートされます。

-replace

-replacementLevel

インポートしたスケジュールがシステム内の既存スケジュールに一致した場合の結果を決定します。
ALL: 既存スケジュールをすべて置き換えます。

NEWER: インポートしたスケジュールよりも古い既存スケジュールを置き換えます。(デフォルト)

NONE: 既存スケジュールを置き換えません。

-v

-verbose

コマンド実行に関する詳細情報を表示します。

-s

-sphereUrl

スフィアのURL。http://hostname:port/btmcentral/sphere/
スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例では、MySchedulesというファイルからスケジュールをインポートし、すべての既存スケジュールを置き換えます。

btmcli importSchedules -inputFile MySchedules -replace ALL
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.26 importTransactionDefns

importTransactionDefnsコマンドを使用して、以前にエクスポートしたトランザクション定義を指定のスフィアにインポートします。

このコマンドでは、デフォルトで、インポートされた定義より古い既存定義がすべて置き換えられ、トランザクションを定義するために必要なプロパティが欠落していれば、それらが再作成されます。

通常、エラーが含まれるトランザクションはインポートできません。-importWithErrorsフラグを設定するとトランザクションをインポートすることはできますが、無効な状態になります。その後、コンソール・ツールを使用してエラーを修正できます。エラーは、トランザクションの「プロファイル」タブに表示されます。

トランザクションが1つ以上のプロパティに依存していることがあります(たとえば、これらのプロパティが相関に使用されている場合)。この場合、トランザクションがインポートされる前に削除されたプロパティがあれば、システムによって再作成されます。トランザクションに必要のないプロパティは、システムで再作成されません。-failOnMissingPropertyフラグを指定すると、トランザクションで必要なすべてのプロパティを再作成できない場合にインポートが失敗するようにできます。次に例を示します。

1. 操作AにプロパティXを作成し、このプロパティを使用してトランザクションの2つの操作を相関付けます。

2. 操作BにプロパティYを作成します。このプロパティはトランザクションには必要ありませんが、特定の値を表面化させるために役立つ場合があります。

3. トランザクションをエクスポートすると、トランザクション定義に影響するすべてのプロパティのコピーがシステムにより作成されます。

4. ここでプロパティXを削除します。

5. トランザクションを再インポートすると、トランザクション定義に必要なプロパティが欠落していることがシステムで認識されます。デフォルトでは、欠落しているプロパティが再作成されます。-failOnMissingPropertyフラグを指定している場合は、インポート操作が失敗します。

6. トランザクションはプロパティYには依存していないため、システムではそのコピーは作成しません。このプロパティはエクスポート/インポート・プロセス中に失われます。これはトランザクションのインポート後に再作成できます。または、exportProfileおよびimportProfileコマンドを使用して、そのような定義に関係のないプロパティがシステムにより自動的に再作成されるように指定できます。

コマンド構文

btmcli importTransactionDefns [-i inputFile]
[-replace ALL | all | NEWER | newer | NONE |none]
[-failOnMissingProperty]
[-importWithErrors]
-s sphereUrl -l username:password

名前

ロング名

説明

-i

-inputFile

インポートするデータを含むファイルの名前。

-replace

-replacementLevel

インポートしたトランザクション定義がシステム内の既存定義に一致した場合の結果を決定します。
ALL: 既存定義をすべて置き換えます。

NEWER: インポートした定義よりも古い既存定義を置き換えます。(デフォルト)

NONE: 既存定義を置き換えません。

--

-failOnMissingProperty

デフォルトでは、トランザクションが依存しているプロパティが欠落している場合、そのプロパティが再作成されます。プロパティが欠落している場合にインポートが失敗するようにするには、このフラグを指定します。

--

-importWithErrors

このコマンドで、インポートしたトランザクションにエラーがある場合でもこのトランザクションを保存する場合に指定します。
このフラグを設定すると、コンソールでエラーを修正できます。通常は、定義にエラーがあるとインポートが失敗します。このフラグを設定すると、インポートは成功しますが、インポートされたトランザクションは無効な状態になります。その後、コンソール・ツールを使用してエラーを表示および修正できます。エラーは、トランザクションの「プロファイル」タブに表示されます。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、importTransactionDefnsコマンドを使用してMyTxDefnsというファイルからデータをインポートする方法を示します。

btmcli importTransactionDefns -i MyTxDefns -replace NONE -failOnMissingProperty
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.27 listInstruments

listInstrumentsコマンドを使用して、システムのポリシー・テンプレートで定義されているインスツルメントおよびその属性名とセグメントをリストします。この情報をretrieveObjectDataコマンドの引数として使用できます。

コマンド構文

btmcli listInstruments -s sphereUrl -l username:password

名前

ロング名

説明

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

サンプル出力

次に、listInstrumentsコマンドのサンプル出力を示します。

Avg Response Time
Attribute Name: averageResponseTime
Description: The average amount of time a transaction requires to complete,
or a service/operation requires to respond.
Segmented By:
operation
containingManagedObjectId
clientAddress
clientName
businessObjectId
businessObjectKey
Faults
Attribute Name: faultCount
Description: The number of faults generated by a service or operation.
Segmented By:
operation
containingManagedObjectId
clientAddress
clientName
faultCode
businessObjectId
businessObjectKey

例

次の例に、listInstrumentsコマンドを示します。

btmcli listInstruments -s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.28 listNodeAliases

listNodeAliasesコマンドを使用して、既知のすべてのノードまたは指定されたノードの別名をリストします。

コマンド構文

btmcli listNodeAlias [ n nodeName]
-s sphereUrl -l username:password

名前

ロング名

説明

-n

-name

ネットワーク・ノードの正規名。通常は完全修飾ドメイン名です。たとえば、jbujes-myPC.edgility.comです。
このフラグを指定しない場合、既知のノードすべての別名が表示されます。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、listNodeAliasコマンドを示します。

btmcli listNodeAliases -n jbujesPC.edgility.com
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.29 mergeServices

mergeServicesコマンドを使用して、2つのサービスをマージ(つまり、重複を削除)します。このコマンドは、-Vフラグで指定したソース・バージョンを削除して、そのエンドポイントを-Tフラグで指定したターゲット・バージョンに移動します。2つのエンドポイントのマージが必要となるような検出の問題の詳細は、12.7項「検出問題の解決」を参照してください。

マージ後のターゲット・バージョンには、両方のバージョンのエンドポイントがすべて含まれます。ソース・バージョンに含まれているプロファイル属性またはメッセージ・プロパティで、マージ後のバージョンで保持する必要があるものは、ターゲット・バージョンで再作成する必要があります。

ソース・バージョンで保持されているすべての履歴データが、ターゲット・バージョンで保持されているデータにマージされます。いったんマージを完了すると、これら2つのサービス・バージョンについて集計された2つの別個のデータ・セットに戻すことはできません。

このコマンドで定義する変更をコミットする前に、コマンドの結果をプレビューできます。プレビュー後、実際に変更を実行するには、-Pオプションを指定せずにもう一度コマンドを実行する必要があります。

選択したエンドポイントをサービス・バージョン間で移動するには、moveEndpointsコマンドを使用します。

コマンド構文

btmcli mergeServices -n friendlyName | -qname qname
-V version
-T targetVersion [-P]
-s sphereUrl -l username:password

名前

ロング名

説明

-n

-name

バージョンをマージするサービスのわかりやすい名前。
2つのバージョンのわかりやすい名前が同じではない場合、-qnameフラグを使用してサービス名を指定する必要があります。

-qname

--

バージョンをマージするサービスの修飾名。
修飾名の形式はWSDLtargetNamespace:serviceNameです。たとえば、http://amberpoint.com/orderService:CreditServiceSOAPです。

-V

-version

指定されたターゲットにマージされるサービスのバージョン。
デフォルトの未指定バージョンを表すには、-文字列を使用します。

-T

-targetVersion

ソース・バージョンのマージ先となるターゲット・サービス・バージョン(-V)。マージ後、このバージョンには両方のバージョンのエンドポイントが含まれます。

-P

-preview

実際にマージを実行せずに、マージの結果をプレビューする場合にこのフラグを指定します。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、mergeServicesコマンドを示します。

btmcli mergeServices -f CreditService -X 1.5 -T 1.6
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.30 moveEndpoints

moveEndpointsコマンドを使用して、指定されたサービスのソース・バージョンからターゲット・バージョンに1つ以上のエンドポイントを移動します。

エンドポイントの識別方法に関係なく、特定のWSDL内の1つのサービスについて定義された一連のエンドポイント全体をまとめて移動することしかできません。

このコマンドで定義する変更をコミットする前に、コマンドの結果をプレビューできます。プレビュー後、実際に変更を実行するには、-Pオプションを指定せずにもう一度コマンドを実行する必要があります。

moveEndpointsコマンドでは、測定は移動されません。エンドポイントの測定はそのエンドポイントに関連付けられたままになり、エンドポイントが新しいサービスに移動されても測定には何も行われません。古いサービス・バージョンの測定には、移動されたエンドポイントから以前に集計されたデータが引き続き含まれます。ターゲット・サービス・バージョンの測定履歴は変更されず、エンドポイントの新しい測定はサービスのターゲット・バージョンに含められます。

このコマンドで、以前に定義されていないバージョンを-Tフラグで指定し、-forceフラグを使用することで、サービスを2つに分割できます。

サービス・バージョン間ですべてのエンドポイントをマージするには、mergeServicesコマンドを使用します。

このコマンドを使用して検出の問題を解決する方法の詳細は、12.7項「検出問題の解決」を参照してください。

コマンド構文

btmcli moveEndpoints -n friendlyName | -qname qname -w wsdlUrl | -e endpointUrl
-V version -T targetVersion [-P]
-s sphereUrl -l username:password

名前

ロング名

説明

-n

-name

移動するエンドポイントが属するサービスのわかりやすい名前。
2つのバージョンのわかりやすい名前が同じではない場合、qnameフラグを使用してサービス名を指定する必要があります。

-qname

--

移動するエンドポイントが属するサービスの修飾名。
修飾名の形式はWSDLtargetNamespace:serviceNameです。たとえば、http://amberpoint.com/orderService:CreditServiceSOAPです。

-w

-wsdlURL

移動するエンドポイントが属するサービスを定義するWSDLファイルのURL。

-e

-endpointUrl

サービスのソース・バージョンに含まれるエンドポイントのURL。
WSDLで、同じURLの複数のエンドポイントに異なるバインディングが定義されている場合、エンドポイントURLによって、複数のエンドポイントが識別されます。これは、1つのサービスに対し複数のエンドポイントを定義するWSDLで一般的に発生する状況です。

-V

-version

指定されたターゲットにマージされるサービスのバージョン。
デフォルトの未指定バージョンを表すには、-文字列を使用します。

-T

-targetVersion

ソース・バージョンのマージ先となるサービス・バージョン(-V)。マージ後、このバージョンには両方のバージョンのエンドポイントが含まれます。

-P

-preview

実際にエンドポイントを移動せずに、移動の結果をプレビューする場合に、このフラグを指定します。

-f

-force

指定されたターゲット・バージョンが存在しない場合に、新規サービス・バージョンを作成します。-newServiceNameフラグを使用すると、このサービスにソース・バージョンとは異なる名前を割り当てることができます。

-newServiceName

-fオプションを使用する場合、-newServiceNameフラグを使用して、作成されるターゲット・バージョンのわかりやすい名前を指定できます。ターゲット・バージョンがすでに存在する場合、このフラグは無視されます。

-s

-sphereUrl

スフィアのURL。http://hostname:port/btmcentral/sphere/
スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、moveEndpointsコマンドを示します。

btmcli moveEndpoints -n catalogService
-e http://test.myhost.com:7412/catalogMgmt/svcs/CatalogSvc
-V 1.5 -T 1.6
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.31 moveMeasurements

moveMeasurementsコマンドを使用して、スフィアから削除したサービスまたはエンドポイントについて収集される測定を、論理的に継続する他のエンドポイントまたはサービスに移動します。

注意: このコマンドを使用する場合は注意が必要です。システムでは、サービスやエンドポイントが実際に同じオブジェクトの別の繰返しかどうかは確認しません。マージ後、2つのオブジェクトの測定を分離することはできません。

スフィアで認識されているサービスの新しいバージョンをデプロイするときに、変更されたWSDLが登録または検出される場合、WSDLで定義されているサービスの修飾名が、そのサービスが最後に読み取られたときにWSDLで検出されたサービスの名前と一致している必要があります。一致しておらず、サービス名の変更オプション(サービス・バージョニング・ポリシー)の値が「以前のエンドポイントを置換え(測定結果をすべて失う)」である場合、Business Transaction Managementによって、以前にWSDLから読み取られたエンドポイントが削除され、現在WSDLに定義されているサービスに属する新規エンドポイントが作成されます。

WSDLで定義されているネームスペースまたはサービス名のみが変更された場合、新規エンドポイントは古いエンドポイントと同じに見えますが(同じURLとバインディング)、異なる一意のIDを持ちます。Business Transaction Managementでは、このIDを利用して測定を対応するオブジェクトと関連付けるため、IDが変更された場合は、古いエンドポイントについて収集された測定が孤立し、アクセス不可能な状態になります。更新後のWSDLで定義されているサービスおよびエンドポイントが論理的に同一の場合は、moveMeasurementsコマンドを使用して、そのサービスまたはエンドポイントの新規インカーネーションに測定を再度関連付ける必要があります。

古いエンドポイントおよびサービスはすでに削除されているため、測定の移動元である古いオブジェクトはその一意のIDで識別する必要があります。削除したサービスのIDは、次のようにスフィアのシステム・ログを確認することで判別できます。

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

2. サマリー・ペインで「AP_Sphere_Service」を選択します。

3. 「管理」メニューから「システム・サービス・ログを開く: AP_Sphere_Service」を選択します。

4. 「ログ・ビューア」が表示されるので、削除されたサービスを見つけて、その「交換ID」値を確認してください。

削除されたオブジェクトに関するメタデータはスフィアで認識されないため、このコマンドで実行できる検証には制限があります。ターゲットが見つからない場合や一意に指定されていない場合、このコマンドでは何の操作も実行されません。また、指定されたIDがスフィアから削除されていない現在のオブジェクトを指している場合、測定を移動しません。

このコマンドを使用して検出の問題を解決する方法の詳細は、12.7項「検出問題の解決」を参照してください。

コマンド構文

btmcli moveMeasurements -id id -n friendlyName | -qname qname [-V version]
[-e endpointUrl] [-bn bindingName]
-s sphereUrl -l username:password

名前

ロング名

説明

-id

--

測定を移動する、削除されたエンドポイントまたはサービスのUUID。
WSDLが変更されたためにシステムでサービスまたはエンドポイントが削除された場合、UUIDを含むシステム・アラートが送信されます。そうでない場合、(前述するように)スフィア・サービスのサービス・ログを確認してIDを取得する必要があります。

-n

-name

測定の移動先となるターゲット・サービスのわかりやすい名前。

-qName

測定の移動先となるターゲット・サービスの修飾名。

-V

-version

測定の移動先となるターゲット・サービスのバージョン。サービスのバージョンが複数ある場合にのみ必須です。

-e

-endpointUrl

測定の移動先となるターゲット・エンドポイントのURL。

-bn

-bindingName

ターゲット・エンドポイントのバインディング名(エンドポイントURLが一意でない場合にのみ必須です)。

-s

-sphereUrl

スフィアのURL。http://hostname:port/btmcentral/sphere/
スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、moveMeasurementsコマンドの使用方法を示します。

btmcli moveMeasurements -id 00EB2838-7E62-11DF-ABB5-27339B5EB390
-n MyCreditService
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

btmcli moveMeasurements -id CAEAF3FF-C5A7-11DF-80D5-2DF5BB94EBDE
-e http://text12.myhost.com:7012/bookmart/ofder/OrderService
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.32 putSetupData

putSetupDataコマンドを使用して、標準入力または指定の入力ファイルから設定ファイルを読み取って、指定されたシステム・サービスの設定データとして保存します。

このコマンドを使用してシステムをバックアップする方法の詳細は、12.4項「Business Transaction Managementのバックアップおよびリストア」を参照してください。

コマンド構文

btmcli putSetupData -e endpointUrl [-i inputFile]
-s sphereUrl -l username:password

名前

ロング名

説明

-e

-endpointUrl

システム・サービスのURL。

-i

-inputFile

入力の取得元となるファイルの名前。

-s

-sphereUrl

読み取るデータが属するサービスがインストールされているスフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、指定のエンドポイントで別のサービスの設定ファイルとして書き込まれるファイルを示します。

cat myFile | btmcli putSetupData -e myServiceEndpoint

btmcli putSetupData -e myServiceEndpoint -i myInputFile

10.33 registerDevice

registerDeviceコマンドを使用して、管理デバイスをスフィアに登録します。Business Transaction Managementでは、メッセージ・トラフィックを分析することでロード・バランシング・デバイスが存在することを推察できますが、デバイスを明示的に登録すると、デバイスのわかりやすい名前およびその他の情報を表示できるようになり、デバイスの管理インタフェースが存在する場合はアクセスできるようになります。

現在、このコマンドについて、サポートされているデバイス・タイプはハードウェアおよびソフトウェア・ロード・バランサのみで、完全にサポートされているロード・バランサはF5 BigIPのみです。

ほとんどの場合、Business Transaction Managementでは、メッセージ・トラフィックを監視し、メッセージ・ヘッダーから宛先情報を読み取って、ルーティング・エントリ・ポイントを自動的に検出してモデル化します。ただし、監視対象メッセージのHTTPホスト・ヘッダーに元の受信者(ロード・バランサ)に関する情報が含まれない場合は、ルーティング・エントリ・ポイントを手動でロード・バランサに割り当てる必要があります。また、ターゲット・エントリ・ポイントを追加してメッセージのルーティング先を示す必要もあります。これを実行するには、Business Transaction Managementの管理コンソールを使用する必要があります。詳細は、12.6項「ロード・バランサの設定」(ロード・バランサの設定)を参照してください。

複数のデバイスを登録する場合は、setDefaultLoadBalancerコマンドを使用してデフォルト・デバイスを設定できます。(新しく検出されたルーティング・エントリ・ポイントはすべて、F5ロード・バランサに属していないかぎり、デフォルト・デバイスの一部としてモデル化されます。)

デバイスを登録解除するには、管理コンソールを使用する必要があります。

コマンド構文

btmcli registerDevice -baseAddress baseAddress -fn friendlyName
-vendor vendor
[-administratorUI administratorUI]
[-phaseInLifecycle DEBRECATED | deprecated
| DEVELOPMENT | development |PRODUCTION | production
| STAGING | staging |TEST | test]
-deviceLogin login:password
-s sphereUrl -l login:password

名前

ロング名

説明

--

-baseAddress

https://myf5:443/など、ロード・バランサのURLのベース・アドレス。

-fn

-friendlyName

ロード・バランサのわかりやすい名前。この名前は、Business Transaction Managementの管理コンソールに表示されます。

--

-vendor

F5 BigIPデバイスを登録する場合は、「F5」と指定します(大文字と小文字が区別されます)。この値に設定すると、vendorフラグが使用できるようになります。
その他のタイプのロード・バランサの場合、このフラグは必須ですが、説明のみを目的として使用されます。任意の値(「F5」を除く)を指定できます。指定した値は、管理コンソールに表示されます。

--

-administratorUI

F5以外のデバイスの場合、ロード・バランサのHTML管理コンソールのURL。管理コンソールではこのURLを使用して、ロード・バランサのコンソールへのリンクを表示します。
F5デバイスの場合、URLは自動的に取得されるため、このフラグは不要です。

--

-phaseInLifecycle

デバイス・コンテナと、その内部に作成されるすべてのエンドポイントのライフサイクル・フェーズを指定します。有効な値は、deprecated、development、production、stagingおよびtestです。これらは大文字/小文字が区別されません。

--

-deviceLogin

このフラグはF5デバイスでは必須ですが、その他のタイプのロード・バランサでは無視されます。
F5ロード・バランサのログイン資格証明の形式は、login:passwordです。Guestのユーザー・ロールで十分な権限が与えられます。

このアカウントの権限が限定されている場合、Business Transaction Managementによってデバイスで管理されるオブジェクトおよびポリシーが検出されますが、Business Transaction Managementを使用してそれらを変更できないことがあります。

CLIコマンドencryptPasswordを使用してパスワードを暗号化できます。たとえば、次に示す例のようにします。

btmcli encryptPassword -password "myPassword"

-s

-sphereUrl

スフィアにAP_SPHERE_URL環境変数を設定している場合を除き、必須です。
次に示す例のように、デバイスを登録するスフィアのURLを指定します。

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

ホスト名およびポート番号を適切な値で置き換えます。このURLの末尾は必ずbtmcentral/sphere/にします。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、registerDeviceコマンドを使用してF5ロード・バランサを登録する方法を示します。

btmcli registerDevice -baseAddress https://myF5:443
-fn MyF5LoadBalancer
-vendor F5
-phaseInLifecycle development
-deviceLogin my_F5_username:my_F5_password
-s http://mySphereHost:1771/btmcentral/sphere/
-l admin:abracadabra

10.34 registerExternalContainer

registerExternalContainerコマンドを使用して、(監視対象コンテナに含まれない) 1つ以上のエントリ・ポイントのエンドポイントを、個別の外部コンテナにグループ化します。これは手動で登録されたエンドポイントでのみ必要です。コンソールでは、そのようなエンドポイントは「未割当てのエンドポイント」ノードの下に表示されます。

コンテナ間でエンドポイントを個別に移動できるコマンドは存在しないため、このコマンドを使用して、指定したベース・アドレスで始まるすべてのエンドポイントを移動する必要があります。

デフォルトでは、手動で登録されたエンドポイントはシステム・コンテナに割り当てられます。registerExternalContainerコマンドを使用すると、1つのグループとして扱い、調査するエンドポイントの外部コンテナを作成できます。たとえば、このコンテナを使用して、手動で登録されたエンドポイントの2つ以上のベース・アドレスが、同じアプリケーション・サーバー内にあるという事実をモデル化できます。

物理コンテナまたはデバイスからベース・アドレスを使用することはできませんが、-fフラグを指定すると、別の外部コンテナからベース・アドレスを使用できます。つまり、検出されたエンドポイントを外部コンテナにグループ化することはできません。

このコマンドのオプション・フラグを使用すると、コンテナのプロファイル情報に表示される情報を指定できます。この情報を更新するには、別のオプション値を指定して、このコマンドをもう一度実行します。

既存のコンテナを更新するときに、ベース・アドレス・リストの最初のエントリが変更されると、コンテナのプライマリ・ベース・アドレスも変更されます。以前コンテナに属していたベース・アドレスを省略すると、コンテナからそれらのアドレスが除外され、システム・コンテナに戻されます。

このコマンドは、このコンテナ内にエンドポイントを持つサービスの登録前でも登録後でも実行できます。

コマンド構文

btmcli registerExternalContainer -baseAddress baseAddress1 [[baseAddress2]...]
[-fn friendlyName] [-vendor vendor]
[-containerInfo containerInfo]
[-ofName osName] [-osVersion osVersion]
[-administratorUI administratorUI]
[-phaseInLifecycle DEBRECATED | deprecated
| DEVELOPMENT | development
|PRODUCTION | production
| STAGING | staging |TEST | test]
[-caseInsensitive] [-f]
-s sphereUrl -l username:password

名前

ロング名

説明

--

-baseAddress

コンテナに関連付けるエンドポイントの既知のベース・アドレス。複数指定した場合、最初のアドレスがプライマリ・ベース・アドレスとみなされます。

-fn

-friendlyName

新しいコンテナのわかりやすい名前。デフォルトでは、プライマリ・ベース・アドレスのhost:portです。

--

-vendor

コンテナのアプリケーション・サーバー・ソフトウェアのベンダー(IBM、Oracle、Microsoftなど)。

--

-containerInfo

名前/バージョン形式で示される、コンテナのアプリケーション・サーバー・ソフトウェアの名前およびバージョン。たとえば、WebLogic Server/10.3です。

--

-osName

コンテナが実行されているオペレーティング・システムの名前。たとえば、WindowsやLinuxです。

--

-osVersion

コンテナが実行されているオペレーティング・システムのバージョン。例: 2003、4.3。

--

-administratorUI

コンテナの管理UIにアクセスするために使用できるURL。

--

-phaseInLifecycle

コンテナのライフサイクル・フェーズを指定します。

--

-caseInsensitive

設定した場合、このコンテナ内のURLが大/小文字の区別なしで比較されます。

-f

-force

現在別の外部コンテナに属しているベース・アドレスを、再度関連付けるかどうかを指定します。

-s

-sphereUrl

コンテナを登録するスフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例では、指定されたベース・アドレスを持つエンドポイントを含める外部コンテナを登録します。

btmcli registerExternalContainer
-baseAddress http://my_host:1234/ http://my_host/4567/
-s http://my_host:1234/btmcentral/sphere/
-l admin:abracadabra

10.35 registerMonitor

registerMonitorコマンドを使用して、モニター・エージェントをスフィアに登録します。

Business Transaction Managementの一元的サービスをインストールして構成すると、追加のアプリケーション・サーバーに1つ以上のモニター・ノードをデプロイして、監視対象メッセージを処理できるようになります。追加するモニターごとに、reigsterMonitorコマンドを実行する必要があります。

Business Transaction Managementモニターをホストしているノードで別名を使用している場合は、addNodeAliasコマンドを実行して別名をスフィアに登録できます。

コマンド構文

btmcli registerMonitor -e endpointUrl [-fn friendlyName]
-s sphereUrl -l username:password

名前

ロング名

説明

-e

-endpointUrl

スフィアに登録するモニターのURLを指定します。次に例を示します。
http://localhost:8080/btmmonitor/agent/agent

ホスト名およびポート番号を適切な値で置き換えます。このURLの末尾は必ずbtmmonitor/agent/agentにします。

-fn

-friendlyName

登録するモニター・エージェントのエンドポイントのわかりやすい名前。

-s

-sphereUrl

必須。コンテナを登録するスフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

btmcli registerMonitor -e http://localhost:8080/btmmonitor/agent/agent
-s sphereUrl http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.36 removeBaseAddressAlias

removeBaseAddressAliasコマンドを使用して、指定のベース・アドレスを持つエントリ・ポイントの指定された別名を削除します。

別名は、このエントリ・ポイントのみに対してローカルに定義されている必要があります。ネットワーク・ノード・レベルで定義されている別名は、removeNodeAliasコマンドを使用して削除する必要があります。

removeBaseAddressAliasコマンドを使用すると、間違った別名や古い別名をシステムから削除できます。補完的なaddBaseAddressAliasコマンドにより生成された重複アーティファクトの削除は元に戻されませんが、ベース・アドレスに関する新しい検出項目および古い別名が、再び個別のエンティティとして扱われるようになります。

このコマンドを使用して検出の問題を解決する方法の詳細は、12.7項「検出問題の解決」を参照してください。

コマンド構文

btmcli removeBaseAddressAlias -baseAddress address -alias address
-s sphereUrl -l username:password

名前

ロング名

説明

--

-baseAddress

スフィアにある既存のエントリ・ポイントのベース・アドレス。scheme://host:port/という形式を使用します。

-alias

--

前述のエントリ・ポイントの別名として削除するベース・アドレス。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境を設定している場合、このフラグは不要です。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、removeBaseAddressAliasコマンドを示します。

btmcli -removeBaseAddressAlias http://jbujes:8080 -alias http://1.2.3.4:8080
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.37 removeDuplicateEndpoint

removeDuplicateEndpointコマンドを使用して、指定した重複エンドポイントを削除します。

このコマンドは通常、パスは同じだが、システムで認識されなかったDNS別名が原因で異なるホスト名を持つ2つのエンドポイントをシステムが検出した場合に使用します。このコマンドを実行すると、これ以降の検出によって重複エンドポイントが再作成されないように、欠落している別名も追加されます。

重複するエンドポイントのベース・アドレスのみが異なっている場合、それら両方のベース・アドレスで見つかるその他のエンドポイントも重複とみなされます。さらに、重複するエンドポイントのサービス記述子(WSDL)もモデルから削除されます。重複するエントリ・ポイントの下にある、実際には重複ではないWSDLおよびエンドポイントは削除されず、残りのエントリ・ポイント下に移動されます。

指定されたエンドポイントURLが依存性を検出済のエンドポイントを参照し、重複するURLが検出または手動で登録されたエンドポイントを参照している場合、コマンドは無効になります。重複するエンドポイントは維持され、エンドポイントURLのベース・アドレスが別名として扱われます。

このコマンドで定義する変更をコミットする前に、コマンドの結果をプレビューできます。プレビュー後、実際に変更を実行するには、-Pオプションを指定せずにもう一度コマンドを実行する必要があります。

このコマンドを使用して検出の問題を解決する方法の詳細は、12.7項「検出問題の解決」を参照してください。

コマンド構文

btmcli removeDuplicateEndpoint -e endpointUrl -d duplicateUrl [-P]
-s sphereUrl -l username:password

名前

ロング名

説明

-e

-endpointUrl

維持するエンドポイントのURL。

-d

-duplicateUrl

重複として削除するエンドポイントのURL。

-P

-preview

実際にエンドポイントを移動することなく、移動の結果をプレビューします。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

重複を削除する別の方法

次のような状況では、モデルの整合性が損なわれたり、実際には重複していない情報が破棄されないようにするために、removeDuplicateEndpointコマンドでは指定された変更を実行しません。

- エンドポイントが、同じサービスの別のサービスまたは別のバージョンに属している場合。

- エンドポイントにより異なるインタフェースが実装される場合。

- エンドポイントが異なるデプロイメントに存在する場合。

- 重複するエンドポイントのWSDLが、残りのエンドポイントについてはWSDLにより参照されていないサービスまたはエンドポイントを参照している場合(つまり、WSDLが重複とはみなされない場合)。

このような場合、次の手順の実行が必要になることあります。

1. unregisterコマンドを使用して、removeDuplicateEndpointコマンドでは削除できないサービス・エンドポイントの登録を解除します。

2. addNodeAliasまたはaddBaseAddressAliasコマンドを使用して別名を追加し、システムでエンドポイントの重複を認識できるようにします。

例

次の例に、removeDuplicateEndpointコマンドを示します。

btmcli removeDuplicateEndpoint
-e http://jbujes.edge.com:7001/bookmart/credit/CreditService
-d http://jbujes.delphi.com:7001/bookmart/credit/CreditService -P
-s http://localhost:8080/btmcentral/sphere/
-l admin:password

10.38 removeNode

removeNodeコマンドを使用して、指定したノードに関する情報をスフィア・データベースから削除します。ノードを削除すると、そのノードに関するすべての情報が別名を含めて削除されます。

ノードの削除は、様々なマシンの別名が混在しているために、ノードをプルーニングするかシステムを再インストールするかという選択に直面している場合を除いて、通常必要ない操作です。ほとんどの場合(誤ったホスト・ファイルを修正する場合や、別のマシンを指すようにDNS別名を変更する場合)、実行する必要があるのは、あるノードから別名を削除して、それを別のノードに追加しなおすことのみです。

コマンド構文

btmcli removeNode -n nodeName -alias aliasName
-s sphereUrl -l username:password

名前

ロング名

説明

-n

-name

ネットワーク・ノードの正規名。通常は完全修飾ドメイン名です。たとえば、jbujes-myPC.edgility.comです。

-f

-force

ノードがまだコンテナまたはエントリ・ポイントにより参照されている場合でも、強制的にノードを削除します。
このノードを削除する前に別のネットワーク・ノードにノードの別名を割り当てた場合、コンテナ自体が別のノードに関連付けられるようにすることができます。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、removeNodeコマンドを示します。

btmcli removeNode -n jbujes.edge.com
-s http://localhost:8080/btmcentral/sphere/
-l username:password

10.39 removeNodeAlias

removeNodeAliasコマンドを使用して、別名情報をスフィア・データベースから削除します。

このコマンドを使用して検出の問題を解決する方法の詳細は、12.7項「検出問題の解決」を参照してください。

コマンド構文

btmcli removeNodeAlias -n nodeName -alias aliasName
-s sphereUrl -l username:password

名前

ロング名

説明

-n

-name

ネットワーク・ノードの正規名。通常は完全修飾ドメイン名です。たとえば、jbujes-myPC.edgility.comです。

-alias

-alias

ネットワーク・ノードの別名。これには、ドメイン名または静的IPアドレスを指定できます。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、removeNodeAliasコマンドを示します。

btmcli removeNodeAlias -n jbujes.edge.com -alias Athena
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.40 removePathAlias

removePathAliasコマンドを使用して、指定したWSDLまたはエンドポイントにアクセスするために使用できる代替URLパスを表す別名を削除します。これ以降の登録や検出では、2つのパスが別々のものとして扱われます。

ホスト名の別名についてはremoveNodeAlias、WSDLのURLのオーソリティにおける他の別名についてはremoveBaseAddressAliasも参照してください。

removePathAliasコマンドを使用すると、古い別名をシステムから削除できます。たとえば、HTTPリダイレクトによってサービス記述子に追加された別名が後から無効にされた場合(WSDLのURL AがURL Bにリダイレクトされたが、現在2つのURLは異なるWSDLを表している場合)、このコマンドによって別名が削除され、WSDL Aを個別に登録できるようになります。

このコマンドを使用して検出の問題を解決する方法の詳細は、12.7項「検出問題の解決」を参照してください。

コマンド構文

ap removePathAlias -w wsdlUrl| -e endpointUrl -alias pathAlias
-s sphereUrl -l username:password

名前

ロング名

説明

-w

-wsdlUrl

別名を削除する完全URLまたはWSDL (サービス記述子)。

-e

-endpointUrl

別名を削除するエンドポイントの完全URL。複数のエンドポイントが一致する場合、それらすべてのエンドポイントから別名が削除されます。

-alias

--

サービス記述子またはエンドポイントから削除する代替パス。これは、/で始まるURLのパス部分のみです。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、暗号化されたパスワードを使用するremovePathAliasコマンドを示します。

btmcli removePathAlias -e http://jbujes:7001/credit/CreditService
-alias /bookmart/amex/CreditSrevice
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.41 removePolicy

removePolicyコマンドを使用して、適用されているポリシーをBusiness Transaction Managementシステムから完全に削除します。

コマンド構文

btmcli removePolicy -name PlcyName [-type PlcyType] [-subType PlcySubType]
[-version PlcyVersion] [-wait true|false] [-f]
-s sphereUrl -l username:password

ポリシーのタイプおよびサブタイプを判断するには、ナビゲータで「ポリシー」を選択します。各ポリシーのタイプおよびサブタイプが、メイン・ペインに表示されます。

名前

ロング名

説明

-n

-name

削除するポリシーの名前。この名前が一意の場合、追加のタイプまたはバージョン情報を指定する必要はありません。

-t

-type

削除するポリシーのポリシー・タイプ。ポリシー名が一意でない場合はこのフラグを使用します。

-subType

--

削除するポリシーのポリシー・サブタイプ。
名前とタイプの組合せが一意でない場合は、ポリシー・サブタイプを指定します。

-V

-version

削除するポリシーに関連付けられているバージョン。
名前、タイプおよびサブタイプのトリプルが一意でない場合は、バージョン番号を指定します。バージョン番号は、一意のポリシーを作成するために、ポリシー名に自動的に付加されます。

-wait

--

TRUE: ポリシーが削除されるまで、別のスクリプトの実行を待機します。
デフォルト値は、FALSEです。

-f

-force

ポリシーが内部的に削除不可とマークされている場合でも、ポリシーを削除します。

-s

-sphereUrl

ポリシーが適用されるスフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例では、myLoggingPolicyというポリシーをスフィアから削除し、ポリシーが削除されるまで他のコマンドの実行を待機します。

btmcli removePolicy -name myLoggingPolicy -wait true
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.42 removePolicyTemplate

removePolicyTemplateコマンドは、指定されたポリシー・テンプレートをシステムから削除します。

コマンド構文

btmcli removePolicy -name PolTemplName [-type Type] [-subType SubType]
[-version PolicyVersion] [-f]
-s sphereUrl -l username:password

ポリシー・テンプレートのタイプおよびサブタイプを判断するには、ナビゲータで「ポリシー・テンプレート」を選択します。各ポリシーのタイプおよびサブタイプが、メイン・ペインに表示されます。

名前

ロング名

説明

-name

--

削除するポリシー・テンプレートの名前。この名前が一意の場合、追加のタイプまたはバージョン情報を指定する必要はありません。

-type

--

削除するポリシー・テンプレートのポリシー・タイプ。ポリシー名が一意でない場合はこのフラグを使用します。

-subType

--

削除するポリシー・テンプレートのポリシー・サブタイプ。
名前とタイプの組合せが一意でない場合は、ポリシー・サブタイプを指定します。

-version

--

削除するポリシーに関連付けられているバージョン。
名前、タイプおよびサブタイプのトリプルが一意でない場合は、バージョン番号を指定します。バージョン番号は、一意のポリシーを作成するために、ポリシー名に自動的に付加されます。

-f

-force

ポリシー・テンプレートが内部的に削除不可とマークされている場合でも、ポリシー・テンプレートを削除します。

-s

-sphereUrl

ポリシーが適用されるスフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例では、myPolicyTemplateというポリシー・テンプレートをスフィアから削除します。

btmcli removePolicyTemplate -name myPolicyTemplate
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.43 renameEndpoint

renameEndpintコマンドを使用して、スフィアでの指定されたエンドポイントのわかりやすい名前を変更します。

同じURLにある複数のエンドポイントに、それぞれのWSDL定義で同じ名前が指定されている場合、それらに一意のわかりやすい名前を指定すると、それ以降のコマンドおよびコマンド出力でそれらのエンドポイントを区別しやすくなります。エンドポイントURLおよび新規のわかりやすい名前を指定する必要があります。その他すべてのパラメータはオプションであり、対象のエンドポイントを、同じURLを持つ他のエンドポイントと区別できるようにするためにのみ使用します。

このコマンドを使用して検出の問題を解決する方法の詳細は、12.7項「検出問題の解決」を参照してください。

コマンド構文

btmcli renameEndpoint -e endpointUrl -fn friendlyName [-bn bindingName]
[-w wsdlUrl] [-n name] [-service serviceName]
[-qname qname] [-V version] [-interfaceQName interfaceQName]
-s sphereUrl -l username:password

名前

ロング名

説明

-e

--

WebサービスのエンドポイントURL。

-bn

-bindingName

エンドポイントのバインディング。複数のバインディングを持つエンドポイントURLを明確化するために使用します。例: SOAPおよびHTTP

-w

-wsdlUrl

WSDLファイルのURL。

-n

-name

名前を変更するエンドポイントの既存のわかりやすい名前。

-service

--

名前が変更されたエンドポイントが属するサービスのわかりやすい名前。

-qname

--

名前が変更されたエンドポイントが属するサービスの修飾名。

-V

-version

名前が変更されたエンドポイントが属するサービスのバージョン。必要に応じて、-serviceまたは-qnameフラグとともに使用します。
デフォルトの未指定バージョンを表すには、-文字列を使用します。

--

-interfaceQName

名前が変更されたエンドポイントが実装するインタフェースの修飾名。

-fn

-friendlyName

名前を変更するエンドポイントの新規のわかりやすい名前。

-s

-sphereUrl

スフィアのURL。http://hostname:port/btmcentral/sphere/
スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、renameEndpointコマンドを使用して、CreditServiceという名前をMyCreditServiceに変更する方法を示します。

btmcli renameEndpoint -e http://jbujes:7001/bookmart/credit/CreditService
-fn MyCreditService
-s http://localhost:8080/btmcentral/sphere
-l admin:abracadabra

10.44 resetSphereUrl

resetSphereUrlコマンドを使用して、このスフィアに現在登録されているコンテナ・サービスのスフィアURLが、現在のスフィアURLに一致していることを確認します。このコマンドを使用する必要があるのは、スフィアのベース・アドレスが変わったときです。

コマンド構文

btmcli resetSphereUrl -s sphereUrl -l username:password

名前

ロング名

説明

-s

-sphereUrl

スフィアのURL。
http://hostname:port/apcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、resetSphereUrlコマンドを示します。

btmcli resetSphereUrl -s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.45 retrieveObjectData

retrieveObjectDataコマンドは、1つ以上のオブジェクトのプロファイルおよび測定データを取得します。このコマンドの出力ファイルは、次の方法で使用できます。

- レポート作成ツールへの入力。

Business Transaction ManagementにはOracle BI Publisherテンプレートが用意されており、これをコマンドの出力ファイルとともに使用して、書式設定されたレポートを生成できます。これらのテンプレートの使用の詳細は、第9章「レポートの作成」を参照してください。

- setBaseLinesコマンドへの入力。

この場合、retrieveObjectDataの出力ファイルをsetBaselinesへの入力ファイルとして使用して、オブジェクト・セットのパフォーマンス・ベースライン値を設定します。ベースラインを設定すると、ベースラインSLAポリシーを作成できるようになります(出力ファイルを使用してベースラインを設定する場合、retrieveObjectDataコマンドの属性は設定しないでください)。

コマンド構文

btmcli retrieveObjectdata -t type1 [[type2] ...] [-query filterQuery]
[-attributeNames attrName1 [attrName2] ... instrName1 [instrName2] ...]
[-segments segment1 [segment2] ...]
[-inTheLast inTheLast] | [-startTime startTime] [-endTime endTime]
[-intervalSize intervalSize]
[-format XML|CSV|SQL]
[-o outputFile]
[-metadata drop|create|none] [-tableName tableName]
-s sphereUrl -l username:password

listInstrumentsコマンドを使用して、retrieveObjectDataコマンドに引数として渡す必要がある属性、セグメントおよびインスツルメントに関する情報を取得できます。属性のリストおよびセグメントのリストを指定すると、コマンド・パーサーによって、各セグメントが、属性リスト内のそのセグメントを持つすべてのインスツルメントに適用されます。

時間値を指定しない場合は、単一セグメントで最後の時間のデータが取得されます。

名前

ロング名

説明

-t

-type

取得するデータが属するオブジェクト・ツリーを指定します。
少なくともルート・オブジェクト・タイプを指定する必要があり、それによって取得されるオブジェクトが(問合せとともに)決定されます。

これに加えて、任意の数の子タイプも指定できます。これらのツリーには、カスタム・データ・エクスプローラで検出されたものも反映されます。タイプ・ツリーの例は、service endpoint operationまたはobserver probe endpointです。

-query

-filterQuery

取得するオブジェクトを、問合せフィルタで定義されたセットに限定します。
問合せは、ツリーのルート・オブジェクト・タイプに適用する必要があります。指定された問合せに一致するオブジェクトのみが、サブツリーの関連オブジェクトとともに結果セットで返されます。

フィルタ・ツールを使用してAQL問合せを作成し、それらの問合せをコピーしてコマンドラインに貼り付けます。

--

-attributeNames

この引数を使用して、次の例のように、各オブジェクトで取得する属性およびインスツルメント値を指定します。
-attributeNames friendlyName averageResponseTime

この例では、friendlyNameが属性、averageResponseTimeがインスツルメントです。複数の属性名(スペースで区切る)に続けて、複数のインスツルメント名(スペースで区切る)を指定できます。

属性名は、列チューザで使用可能な任意の属性を参照できます。属性は、次の例に示すように、オブジェクト・タイプの後に2つのコロン(::)を付けたもので修飾できます。

Endpoint::friendlyName

修飾属性名を指定した場合、指定されたオブジェクト・タイプのみについて属性値が取得されます(この例では、エンドポイントのわかりやすい名前のみです)。未修飾属性名を指定した場合、属性値は、type引数で示されているすべてのオブジェクト・タイプのうち、その属性を持つものについて取得されます(たとえば、エンドポイント、サービスおよび操作)。よく使用される属性名およびオブジェクト・タイプの完全なリストは、10.1.6項「属性名」を参照してください

インスツルメント名の完全なリストを表示するには、listInstrumentsコマンドを実行してください。

-segments

--

指定された測定属性(インスツルメント)のデータを取得するときに使用するセグメントを指定します。これにより、指定された時間範囲に記録された名前付きセグメントの値ごとに、データの内訳が示されます。

-inTheLast

--

現在時刻から、指定した時間だけ過去にさかのぼった時間範囲を指定します。
値は、数値の後に単位を付けて指定します(sまたはSは秒、mまたはMは分、hまたはHは時間、dまたはDは日) (たとえば、1Hは1時間です)。

-startTime

--

測定属性(インスツルメント)が指定されている場合に、その値を生成する時間範囲の開始時刻を指定します。endTimeを指定しない場合、範囲の終了は現在時刻になります。
現在のデフォルト日付書式が使用されます(たとえば、2010-08-03 15:00:00です)。

-endTime

--

測定属性(インスツルメント)が指定されている場合に、その値を取得する時間範囲の終了時刻を指定します。
現在のデフォルト日付書式が使用されます(たとえば、2010-08-03 18:00:00です)。

--

-intervalSize

指定した時間範囲を分割する間隔サイズを指定します。
間隔サイズは、数値の後に単位を付けて指定します(sまたはSは秒、mまたはMは分、hまたはHは時間、dまたはDは日) (たとえば、1Hは1時間です)。間隔サイズは、指定された時間範囲の長さ以下である必要があります。

このオプションの引数を指定しない場合は時間範囲全体が使用され、1つの間隔のみが返されます。

注意: 出力ファイルをsetBaselinesコマンドの入力として使用する場合は、この属性を設定しないでください。setBaselinesコマンドでは、各オブジェクトのインスツルメント・タイプ当たり1つの値しか受け入れません。この属性を省略することで、必ず各オブジェクトのインスツルメント・タイプ当たり1つの値のみが出力されるようになります。

-format

--

出力ファイルの形式を指定します。有効な値は、XML、CSVおよびSQLです。XMLがデフォルトの形式です。

-o

-outputFile

出力ファイルの名前。

-metadata

--

SQLメタデータ・コマンドを作成するかどうかを指定します。
有効な値は、表を削除して作成する場合にはdrop、表の作成のみの場合にはcreateです。

-tablename

--

SQL出力に使用されるSQL表名を指定し、指定しない場合は名前が生成されます。

-s

-sphereUrl

スフィアのURL。たとえば、http://hostname:port/btmcentral/sphere/です。
スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例1: コンテナのデータの取得。

btmcli retrieveObjectData
-t container
-s http://myHost:7003/btmcentral/sphere/
-l my_sphere_username:my_sphere_password
- my_containers_output.xml

例2: レポートのための各サービスの平均レスポンス時間の取得(-intervalSizeが指定されていることに注意してください)。

btmcli retrieveObjectData
-t service
-s http://my_host:7003/btmcentral/sphere/
-l my_sphere_username:my_sphere_password
-attributeNames firendlyName averageResponseTime
-inTheLast 24h
-intervalSize 1h
-format xml
-o my_avg_response_time_output_for_reporting.xml

例3: 各サービス、エンドポイントおよび操作のベースラインの設定における平均レスポンス時間の取得(-intervalSizeが指定されていないことに注意してください)。

btmcli retrieveObjectdata
-t service endpoint operation
-s http://my_host:7003/btmcentral/sphere/
-l my_sphere_username:my_sphere_password
-attributeNames friendlyName averageResponseTime
-inTheLast 24h
-o my_avg_response_time_output_for_baselines.xml

10.46 sendEventNotification

sendEventNotificationコマンドを使用して、通知サービスを使用してイベント通知を作成および送信します。通知の処理方法は、現在アクティブなサブスクリプションによって決定されます。

次のいずれかの状況が発生した場合、システムにより自動的にアラートが生成されます。

- SLA施行ポリシーによって、失敗アラート、警告アラートまたはコンプライアンス・アラートが発行された場合。

- 条件定義によって、トランザクション監視サービスから条件アラートが発行された場合。

- システム・サービスによってスローされた例外が原因で、システムからシステム・アラートが発行された場合。

これらの場合に加えて、管理者が、メンテナンスやアップグレードのためにシステムを停止する必要があることをユーザーに通知したり、なんらかの管理操作により、レポート作成に使用されたデータが再生成されることをユーザーに通知するためのアラートを発行する必要がある場合があります。このような通知を可能にするために、sendEventNotificationコマンドが用意されています(sendToNotifierコマンドを使用してイベント通知を送信することもできますが、作業量が大きく増えます)。

コマンド構文

btmcli sendEventNotification -source source -n name
-topic topic [-subtopic subtopic]
-severity SEVERE | WARNING | INFO | CONFIG | FAILURE | SUCCESS
-message message
[-attributes name1:value1 [[name2:value2] ...]]
-s sphereUrl -l username:password

名前

ロング名

説明

-source

--

通知が生成された場所を示します。指定可能なソースには、ASLM、ExMおよびSystemが含まれます。任意の値を指定できます。

-n

-name

イベント通知に関連付けられる名前。これは、イベントが何に関するものであるかの情報を示す必要があります。

-topic

--

イベント通知のトピック。類似のイベント通知の分類に使用します。

-subtopic

--

イベント通知のサブトピック。イベント通知の分類に使用します。

--

-severity

通知の原因となった状況の重要性を示します。

-message

--

イベント通知の意味とユーザー・アクションの必要性に関するテキスト説明。

--

-attributes

イベント通知に添付され、通知を受信するどのユーザーでも使用できるようになっているname:valueペアのリスト。これらの属性は通常、通知に関係するオブジェクトを参照します。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、sendEventNotificationコマンドを使用して、システムのバックアップが間もなく行われることを現在のサブスクライバに通知する方法を示します。

btmcli sendEventNotification -source System -n BackupWarning
-topic SysNotifications -severity WARNING
-message "System backup in 10 minutes. Please save your work."
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.47 sendToNotifier

sendToNotifierコマンドを使用して、電子メールおよびWebサービスのサブスクリプションを管理できます。

sendToNotifierコマンドは、(XML入力ファイルで指定される)コマンドを処理のために通知サービスに送信します。電子メール・サブスクリプションの作成、既存のサブスクリプションのリスト、サブスクリプションの削除などを実行できます。このコマンドは、通知サービスによって返されるレスポンス・ドキュメントを返します。追加のコマンドを発行するには、別のコマンドを含む入力ファイルを指定して、sendToNotifierをもう一度コールする必要があります。

sendToNotifierのコマンド構文はかなり単純ですが、入力コマンド・ドキュメントの作成は複雑になる場合があります。

Business Transaction Managementでは現在、コマンドライン・インタフェースを介した電子メールおよびWebサービスのサブスクリプションのみをサポートしています。

この項の最後に説明するコマンド・ドキュメントには、次のいずれかのタスクを実行するxmlメッセージ(コマンド)を含めることができます。

- 電子メール・サブスクリプションの作成

- Webサービスで通知操作をコールするためのサブスクリプションの作成

- 既存のサブスクリプションのリスト

- 通知サービスからのサブスクリプションの削除

コマンド構文

btmcli sendToNotifier -i inputFile [-o outputFile]
-s sphereUrl -l username:password

名前

ロング名

説明

-i

-inputFile

通知サービスに送信するコマンドを含むXMLファイル。ファイルごとに1つのコマンドを含めることができます。

-o

-outputFile

通知サービスからのレスポンスを保持するファイル。指定しない場合、レスポンスはstdoutに送信されます。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

10.47.1 電子メール通知の設定

sendToNotifierの使用は、電子メール通知を設定する際の1つのステップです。全体的な手順には次のステップも含まれます。

1. ナビゲータから「システム・サービス」を選択し、「サマリー」領域に示されているサービスから「AP_Notifier_Service」を選択します。

2. 使用するメール・ホストおよび電子メール送信者を指定するように(「管理」メニューで)設定データを編集します。

3. sendToNotifierコマンドを使用して、SLAアラート、条件アラートなどへのサブスクリプションを登録します(入力コマンド・ドキュメントに、必要なアラートを指定するコマンドを含めます)。たとえば、次のドキュメントは条件アラートに対するサブスクリプションを登録します。

<ap:registerSubscription
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<ap:subscription name="All Exception Alerts" enabled="true" userID="testID">
<ap:deliveryMechanism>
<ap:sendEmail format="long" style="html">
<ap:from>BTM.TEST@oracle.com</ap:from>
<ap:recipient type="TO">your.name@yourdomain.com</ap:recipient>
</ap:sendEmail>
</ap:deliveryMechanism>
<ap:notificationFilters>
<ap:source>
<ap:value>ExM</ap:value>
<ap:operation>in</ap:operation>
</ap:source>
</ap:notificationFilters>
</ap:subscription>
</ap:registerSubscription>

入力コマンド・ドキュメントについては、10.47.3項「通知サービス・コマンド・ドキュメント」で説明します。

4. 対象オブジェクトのSLAまたは条件アラートを定義します。

10.47.2 電子メール通知の管理

sendToNotifierを使用して、サブスクリプションをリストおよび削除することもできます。この方法を示すサンプル・コマンド・ドキュメントを次に示します。

サブスクリプションをリストするには

<ap:getSubscription xmlns:ap="http://namespace.amberpoint.com/amf"/>

サブスクリプションを取り消すには

<ap:cancelSubscription xmlns:ap="http://namespace.amberpoint.com/amf">
<ap:subscription name="All Exception Alerts" userID="testID"/>
<ap:subscription name="All SLA Alerts" userID="testID"/>
<ap:subscription name="All System Alerts" userID="testID"/>
</ap:cancelSubscription>

例

次の例に、sendToNotifierコマンドを示します。

btmcli sendToNotifier -i MyNotifierCommand -o MyNotifierReponse
-s http://localhost:8080/btmcentral/sphere -l admin:abracadabra

10.47.3 通知サービス・コマンド・ドキュメント

通知サービス・コマンド(xmlメッセージ)は、sendToNotifierコマンドへの入力であるコマンド・ドキュメントに含めることができます。通知サービス・コマンドについては次の各項で説明しますが、これらを使用して、次の操作を実行できます。

- 電子メール・サブスクリプションの作成

- Webサービス・サブスクリプションの作成

- サブスクリプションのリスト

- サブスクリプションの削除

- 通知対象の取得

- テンプレートの取得

各ドキュメントに含めることができるコマンドは1つのみです。複数のコマンドを実行するには、コマンドごとにドキュメントを作成し、各ドキュメントに対してsendToNotifierコマンドを呼び出す必要があります。

10.47.3.1 通知サービス・コマンド

次の各項では、通知サービス・ドキュメントに含めることができるコマンドについて説明します。

電子メール・サブスクリプションの作成

このコマンドでは、次のバリエーションがサポートされます。

- 特定のタイプ(たとえば、システム・アラート、SLAアラート、条件アラート)のすべてのアラートに対するサブスクリプションの作成

- 特定のオブジェクト(たとえば、トランザクション、サービス、エンドポイント、操作、コンシューマ、システム・サービス)に関するすべてのアラートに対するサブスクリプションの作成

- 特定の重大度(たとえば、失敗および警告。ただしコンプライアンスおよび情報アラートは除く)のすべてのアラートに対するサブスクリプションの作成

- 特定のポリシーにより生成されたすべてのアラート(たとえば、ベースラインSLAポリシーにより生成されたすべてのアラート)に対するサブスクリプションの作成

- 特定の条件により生成されたすべてのアラート(たとえば、FaultMonitoring条件に対するすべての条件アラート)に対するサブスクリプションの作成

次のサンプル・コマンドに加えて、アラート・タイプを指定するために使用するメタデータについても理解している必要があります。これについては次の項で説明します。

<ap:registerSubscription xmlns:ap="http://namespace.amberpoint.com/amf"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<ap:subscription name="All SLA Alerts" enabled="true" userID="testID">
<ap:deliveryMechanism>
<ap:sendEmail format="short" style="text">
<ap:from>BTM.TEST@oracle.com</ap:from>
<ap:recipient type="TO">your.email@oracle.com</ap:recipient>
</ap:sendEmail>
</ap:deliveryMechanism>
<ap:notificationFilters>
<ap:source>
<ap:value>ASLM</ap:value>
<ap:operation>in</ap:operation>
</ap:source>
</ap:notificationFilters>
</ap:subscription>
</ap:registerSubscription>

次に、コメント付きの詳細な例を示します。

<ap:registerSubscription xmlns:ap="http://namespace.amberpoint.com/amf"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<ap:subscription name="Warning and Failure SLA Alerts" enabled="true"
userID="testID">
<ap:deliveryMechanism>
<ap:sendEmail format="long" style="html">
<ap:from>BTM.TEST@oracle.com</ap:from>
<ap:recipient type="TO">your.name@oracle.com</ap:recipient>
</ap:sendEmail>
</ap:deliveryMechanism>
<ap:notificationFilters>
<ap:source>
<ap:value>ASLM</ap:value><!-- subcribe to SLA alerts -->
<ap:operation>in</ap:operation>
</ap:source>
<ap:severity>
<ap:value>WARNING</ap:value> <!-- subcribe to WARNING and FAILURE alerts -->
<ap:value>FAILURE</ap:value>
<ap:operation>in</ap:operation>
</ap:severity>
</ap:notificationFilters>
</ap:subscription>
<ap:subscription name="Exception Alert transaction OrderService_submit"
enabled="true" userID="testID">
<ap:deliveryMechanism>
<ap:sendEmail format="short" style="text">
<ap:from>BTM.TEST@oracle.com</ap:from>
<ap:recipient type="TO">your.name@oracle.com</ap:recipient>
</ap:sendEmail>
</ap:deliveryMechanism>
<ap:notificationFilters>
<ap:event>
<ap:value>Exception Detected</ap:value> <!-- subscribe to Exception alert
event-->
<ap:operation>in</ap:operation>
</ap:event>
<ap:info>
<ap:name>correlationName</ap:name> <!-- subcribe to tx by friendly name-->
<ap:value>OrderService_submit</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
</ap:notificationFilters>
</ap:subscription>
</ap:registerSubscription>

Webサービス・サブスクリプションの作成

このコマンドでは、次のバリエーションがサポートされます。

- 特定のタイプ(たとえば、システム・アラート、SLAアラート、条件アラート)のすべてのアラートに対するサブスクリプションの作成

- 特定のオブジェクト(たとえば、トランザクション、サービス、エンドポイント、操作、コンシューマ、システム・サービス)に関するすべてのアラートに対するサブスクリプションの作成

- 特定の重大度(たとえば、失敗および警告。ただしコンプライアンスおよび情報アラートは除く)のすべてのアラートに対するサブスクリプションの作成

- 特定のポリシーにより生成されたすべてのアラート(たとえば、ベースラインSLAポリシーにより生成されたすべてのアラート)に対するサブスクリプションの作成

- 特定の条件により生成されたすべてのアラート(たとえば、FaultMonitoring条件に対するすべての条件アラート)に対するサブスクリプションの作成

<ap:registerSubscription xmlns:ap="http://namespace.amberpoint.com/amf"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<ap:subscription name="Dispatch" enabled="true" userID="ABC">
<ap:deliveryMechanism>
<ap:callWebService>
<ap:httpEndPoint>
<ap:uri>http://10.148.118.72:8080/eProxy/svc/NotifPort_Proxy</ap:uri>
<!-- this is my test webService, replace with your own.-->
<ap:soapAction>ReplaceWithRealSoapActionForDotNetService</ap:soapAction>
</ap:httpEndPoint>
</ap:callWebService>
</ap:deliveryMechanism>
<ap:notificationFilters>
<ap:source>
<ap:value>ASLM</ap:value>
<ap:value>ExM</ap:value>
<ap:value>System</ap:value>
<ap:operation>in</ap:operation>
</ap:source>
</ap:notificationFilters>
</ap:subscription>
</ap:registerSubscription>

サブスクリプションの取得

このコマンドでは、次のバリエーションがサポートされます。

- すべての電子メール・サブスクリプションのリスト

- すべてのWebサービス・サブスクリプションのリスト

- 特定の電子メール・アドレスに対するすべてのサブスクリプションのリスト

- 特定のWebサービスに対するすべてのWebサービス・サブスクリプションのリスト

- 特定のオブジェクト(トランザクション、サービス、エンドポイント、操作、システム・サービス、コンシューマ)に対するすべてのサブスクリプションのリスト

これらのアクションの例を次に示します。

すべてのサブスクリプションの取得

<ap:getSubscription xmlns:ap="http://namespace.amberpoint.com/amf"/>

サブスクリプション名によるサブスクリプションの取得

<ap:getSubscription xmlns:ap="http://namespace.amberpoint.com/amf">
<ap:subscription name="Dispatch"/>
</ap:getSubscription>

ユーザー名によるサブスクリプションの取得

<ap:getSubscription xmlns:ap="http://namespace.amberpoint.com/amf">
<ap:subscription userID="mary"/>
</ap:getSubscription>

サブスクリプションの取消

このコマンドでは、次のバリエーションがサポートされます。

- 特定の電子メール・アドレスに対するすべてのサブスクリプションの削除

- 特定のWebサービスに対するすべてのWebサービス・サブスクリプションの削除

- 特定のオブジェクト(たとえば、トランザクション、サービス、エンドポイント、操作、システム・サービス、コンシューマ)に関するすべてのサブスクリプションの削除

次に例を示します。

<ap:cancelSubscription xmlns:ap="http://namespace.amberpoint.com/amf">
<ap:subscription name="Dispatch" userID="mary"/> </ap:cancelSubscription>

形式情報の取得

このコマンドは、ロングHTMLやショート・テキストといった使用可能な形式を返します。コマンドのサンプル出力を次に示します。

<ap:getFormatInformationResponse xmlns:ap="http://namespace.amberpoint.com/amf"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<ap:for value="Email" xmlns:ap= "http://namespace.amberpoint.com/amf">
<ap:format value="long"xmlns:ap="http://namespace.amberpoint.com/amf"/>
<ap:format value="short" xmlns:ap="http://namespace.amberpoint.com/amf"/>
<ap:style value="html" xmlns:ap="http://namespace.amberpoint.com/amf"/>
<ap:style value="text" xmlns:ap="http://namespace.amberpoint.com/amf"/>
</ap:for>
</ap:getFormatInformationResponse

通知対象の取得

次のようなコマンドを使用します。

<ap:getNotificationInterest xmlns:ap="http://namespace.amberpoint.com/amf"/>

テンプレートの取得

次のようなコマンドを使用します。

<ap:getTemplate/>

10.47.3.2 アラート・タイプのメタデータ

SLA、例外およびシステム・アラートのメタデータを理解している必要があります。この情報は、特定のタイプの情報に対するサブスクリプションを適切に書式設定するために使用します。次の表に、メタデータ情報を示します。

SLAアラートのメタデータ

次の表に、SLAアラートのメタデータを示します。

メタデータ

使用可能な値

サンプル・サブスクリプション

(ヘッダー) source

ASLM

<ap:notificationFilters>
<ap:source>
<ap:value>ASLM</ap:value>
<ap:operation>in</ap:operation>
</ap:source>
</ap:notificationFilters>

(ヘッダー) event

enforcement_condition

<ap:notificationFilters>
<ap:event>
<ap:value>enforcement_condition</ap:value>
<ap:operation>in</ap:operation>
</ap:event>
</ap:notificationFilters>

(ヘッダー) severity

WARNING
FAILURE

SUCCESS

INFO

<ap:notificationFilters>
<ap:severity>
<ap:value>WARNING,FAILURE</ap:value>
<ap:operation>in</ap:operation>
</ap:severity>
</ap:notificationFilters>

(ヘッダー) templateSet

ASLM-Template

<ap:notificationFilters>
<ap:templateSet>
<ap:value>ASLM-Template</ap:value>
<ap:operation>in</ap:operation>
</ap:templateSet>
</ap:notificationFilters>

(info) com.amberpoint.notification.enforcementValue

(アラートをトリガーしたSLA施行の値)

<ap:notificationFilters>
<ap:info>
<ap:name>com.amberpoint.notification.
instrumentName</ap:name>
<ap:value>85</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

(info) com.amberpoint.notification.instrument
名前

(インスツルメントの修飾名)

表の後に示す注意を参照。

(info) com.amberpoint.notification.objectType

Service、Endpoint、Transaction

<ap:notificationFilters>
<ap:info>
<ap:name>com.amberpoint.notification.
objectType</ap:name>
<ap:value>Service</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

(info) com.amberpoint.notification.objectId

(SLAポリシーが適用されるオブジェクトのUUID)

<ap:notificationFilters>
<ap:info>
<ap:name>com.amberpoint.notification.
objectId</ap:name>
<ap:value>uuid:DA936829-98FF-11DF-828B-
A3EAF532919E</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

(info) com.amberpoint.notification.policyId

(SLAポリシーのUUID)

<ap:notificationFilters>
<ap:info>
<ap:name>com.amberpoint.notification.
policyId</ap:name>
<ap:value>uuid:896FCF93-9900-11DF-8753-
57E6CFA43E9B</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

(info) com.amberpoint.notification.senderId

(AP_Enforcer_ServiceのUUID)

<ap:notificationFilters>
<ap:info>
<ap:name>com.amberpoint.notification.
senderId</ap:name>
<ap:value>uuid:896FCF93-9900-11DF-8753-
57E6CFA43E9B</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

(info) com.amberpoint.notification.senderUrl

(AP_Enforcer_Serviceの場所)

<ap:notificationFilters>
<ap:info>
<ap:name>com.amberpoint.notification.
senderUrl</ap:name>
<ap:value>http://localhost:8080/
btmperformance/endorcer</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

(info) com.amberpoint.notification.transaction
Id

トランザクションのUUID (SLAがトランザクションに適用されている場合のみ)

<ap:notificationFilters>
<ap:info>
<ap:name>com.amberpoint.notification.
transactionId</ap:name>
<ap:value>uuid:896FCF93-9900-11DF-8753
-57E6CFA43E9B</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

(info) endpointId

(AP_Enforcer_Serviceシステム・エンドポイントのUUID)

<ap:notificationFilters>
<ap:info>
<ap:name>com.amberpoint.notification.
endpointId</ap:name>
<ap:value>uuid:896FCF93-9900-11DF-8753-
57E6CFA43E9B</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

(info) serviceID

(AP_Enforcer_ServiceのUUID)

<ap:notificationFilters>
<ap:info>
<ap:name>com.amberpoint.notification.
serviceId</ap:name>
<ap:value>uuid:896FCF93-9900-11DF-8753-
57E6CFA43E9B</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

(info) com.amberpoint.notification.instrumentNameのサンプル・サブスクリプションを次に示します。

<ap:notificationFilters>
<ap:info>
<ap:name>com.amberpoint.notification.instrumentName</ap:name>
<ap:value>http://schemas.amberpoint.com/instruments/transactions/
types:startedTransactionCount</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

条件アラートのメタデータ

次の表に、条件アラートのメタデータを示します。

メタデータ

使用可能な値

サンプル・サブスクリプション

(ヘッダー) source

ExM

<ap:notificationFilters>
<ap:source>
<ap:value>ExM</ap:value>
<ap:operation>in</ap:operation>
</ap:source>
</ap:notificationFilters>

(ヘッダー) event

Exception Detected

<ap:notificationFilters>
<ap:event>
<ap:value>Exception Detected</ap:value>
<ap:operation>in</ap:operation>
</ap:event>
</ap:notificationFilters>

(ヘッダー) severity

FAILURE、
WARNING、

INFO

<ap:notificationFilters>
<ap:severity>
<ap:value>WARNING</ap:value>
<ap:operation>in</ap:operation>
</ap:severity>
</ap:notificationFilters>

(ヘッダー) templateSet

Exm-Template

<ap:notificationFilters>
<ap:templateSet>
<ap:value>Exm-Template</ap:value>
<ap:operation>in</ap:operation>
</ap:templateSet>
</ap:notificationFilters>

(info) com.amberpoint.notification.objectType

Transaction

<ap:notificationFilters>
<ap:info>
<ap:name>com.amberpoint.notification.objectType</ap:name>
<ap:value>Transaction</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

(info) com.amberpoint.notification.objectId

(トランザクションのUUID)

<ap:notificationFilters>
<ap:info>
<ap:name>com.amberpoint.notification.objectId</ap:name>
<ap:value>uuid:896FCF93-9900-11DF-8753-57E6CFA43E9B
</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

(info) com.amberpoint.notification.transactionId

(トランザクションのUUID)

<ap:notificationFilters>
<ap:info>
<ap:name>com.amberpoint.notification.transactionId</ap:name>
<ap:value>uuid:896FCF93-9900-11DF-8753-57E6CFA43E9B
</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

(info) correlationName

(関数のわかりやすい名前)

<ap:notificationFilters>
<ap:info>
<ap:name>correlationName</ap:name>
<ap:value>testTransaction1</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

(info) detectionTime

(解読可能なタイムスタンプ。例: Thu Jul 22 12:25:49 PDT 2010)

<ap:notificationFilters>
<ap:info>
<ap:name>detectionTime</ap:name>
<ap:value>Thu Jul 22 12:25:49 PDT 2010</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

(info) exceptionPriority

failure、warning、informational

<ap:notificationFilters>
<ap:info>
<ap:name>exceptionPriority</ap:name>
<ap:value>warning</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

(info) exceptionTemplate

(条件のわかりやすい名前)

<ap:notificationFilters>
<ap:info>
<ap:name>exceptionTemplate</ap:name>
<ap:value>condition2</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

(info) exceptionType

(トランザクション名+条件名またはサービス名+条件名)

<ap:notificationFilters>
<ap:info>
<ap:name>exceptionType</ap:name>
<ap:value>testTransaction1+condition2</ap:value>
<ap:operation>in</ap:operation>
</ap:info> <ap:notificationFilters>

(info) exceptionsURL

(例外インスタンスのUIページに戻るリンクのURL)

<ap:notificationFilters>
<ap:info>
<ap:name>exceptionsURL</ap:name>
<ap:value>http://localhost:8080/btmui</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

(info) instanceID

(例外インスタンスのUUID)

<ap:notificationFilters>
<ap:info>
<ap:name>instanceId</ap:name>
<ap:value>uuid:896FCF93-9900-11DF-8753-57E6CFA43E9B
</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

システム・アラートのメタデータ

次の表に、システム・アラートのメタデータを示します。

メタデータ

使用可能な値

サンプル・サブスクリプション

(ヘッダー) source

System

<ap:notificationFilters>
<ap:source>
<ap:value>System</ap:value>
<ap:operation>in</ap:operation>
</ap:source>
</ap:notificationFilters>

(ヘッダー) event

business_object_creation

<ap:notificationFilters>
<ap:event>
<ap:value>business_object_creation</ap:value>
<ap:operation>in</ap:operation>
</ap:event>
</ap:notificationFilters>

(ヘッダー) severity

INFO

<ap:notificationFilters>
<ap:severity>
<ap:value>INFO</ap:value>
<ap:operation>in</ap:operation>
</ap:severity>
</ap:notificationFilters>

(ヘッダー) templateSet

System-Template

<ap:notificationFilters>
<ap:templateSet>
<ap:value>System-Template</ap:value>
<ap:operation>in</ap:operation>
</ap:templateSet>
</ap:notificationFilters>

(info) com.amberpoint.notification.senderId

(このアラートを送信するサービスのUUID。)

<ap:notificationFilters>
<ap:info>
<ap:name>com.amberpoint.notification.senderId</ap:name>
<ap:value>uuid:896FCF93-9900-11DF-8753-57E6CFA43E9B</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

(info) com.amberpoint.notification.senderUrl

(このアラートを送信するサービスの場所。)

<ap:notificationFilters>
<ap:info>
<ap:name>com.amberpoint.notification.senderUrl</ap:name>
<ap:value>http://localhost:8080/btmperformance/endorcer
</ap:value>
<ap:operation>in</ap:operation>
</ap:info>
<ap:notificationFilters>

10.48 setBaselines

setBaselinesコマンドは、指定されたオブジェクトのベースラインを設定します。ベースラインを設定すると、ベースラインSLAポリシーを作成できるようになります

retrieveObjectDataコマンドを使用して、履歴パフォーマンス・データを取得してファイルに出力でき、このファイルをsetBaselinesコマンドへの入力として使用できます。入力ファイルを手動で作成する場合は、retrieveObjectDataコマンドの出力と同じ形式を使用してください。

このコマンドを使用して、指定したオブジェクトまたはすべての管理対象オブジェクトの既存のベースラインを削除することもできます。

コマンド構文

btmcli setBaselines -i inputFile [-delete] [-all]
-s sphereUrl -l username:password

名前

ロング名

説明

-i

--

サービス、サービス操作、エンドポイント、エンドポイント操作およびトランザクションのベースライン値を示すXMLドキュメント。ベースライン・サービス・レベル合意に使用できるベースライン値(SLAは、履歴から導出されたパフォーマンスしきい値に基づきます)。

-delete

--

新しいベースラインを設定する前に、参照されている管理対象オブジェクトの既存のベースラインをすべて削除します。

-all

--

-deleteオプションと組み合せて使用し、すべての管理対象オブジェクトの既存ベースラインをすべて削除します。この場合、入力ファイルは不要です。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、setBaselinesコマンドを示します。

btmcli setBaselines -i MyBookmartBaselines -delete
-s http://mySphereHost:1771/btmcentral/sphere/
-l my_btm_admin_username:my_btmadmin_password

10.49 setDefaultLoadBalancer

setDefaultLoadBalancerコマンドを使用して、監視対象メッセージ・トラフィックから検出されたルーティング・エントリ・ポイントのモデル化に使用するデフォルト・デバイスを設定します。

既知のロード・バランサが1つのみの単純な環境では、そのデバイスが自動的にデフォルトとして使用されます。追加のデバイスを登録した場合は、このコマンドを使用して、ルーティング・エントリ・ポイントのモデリングにどのデバイスを使用するかを設定します。

ロード・バランサおよびそのデフォルトの設定方法の詳細は、12.6項「ロード・バランサの設定」を参照してください。

コマンド構文

btmcli setDefaultLoadBalancer -baseAddress baseAddress | -fn friendlyName
-s sphereURL -l username:password

名前

ロング名

説明

--

-baseAddress

ロード・バランサのURLのベース・アドレス。たとえば、https://myf5:443/です。

-fn

--

スフィアでのロード・バランサのわかりやすい名前。この名前は、ナビゲータから「デバイス」を選択したときにサマリー・ペインに表示されます。これは、ロード・バランサの登録時にユーザーが割り当てた名前です。

-s

-sphereUrl

必須。コンテナを登録するスフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例では、デフォルトのルーティング・デバイスを指定します。

btmcli setDefaultLoadBalancer -baseAddress https://myF5:443/
-s http://localhost:8080/btmcentral/sphere -l admin:abracadabra

10.50 showService

showServiceコマンドを使用して、サービスのわかりやすい名前、修飾名または任意のエンドポイントのURLで指定したサービスの構造を示します。サービスの1つのバージョンを指定したり(-version)、より詳細な情報を表示するように指定することもできます(-verbose)。

非詳細出力には、バージョン番号、サービスの修飾名、わかりやすい名前、バインディング、管理対象および完全URLが含まれます。

コマンド構文

btmcli showService -n friendlyName  | -qname qname| -e endpointUrl
| -wwsdlUrl
[-V version] [-v]
-s sphereUrl -l username:password

名前

ロング名

説明

-n

-name

情報を検索する対象となるサービスのわかりやすい名前。この名前は、-versionフラグを使用して修飾できます。そうしない場合、このわかりやすい名前を持つすべてのサービスに関する情報が表示されます。

-qname

--

情報を検索する対象となるサービスの修飾名。修飾名の形式はWSDLtargetNamespace:serviceNameです。たとえば、http://amberpoint.com/orderService:CreditServiceSOAPです。

-e

-endpointUrl

サービスの任意のエンドポイントのURL。この場所にあるエンドポイントが複数のサービスで定義されている場合、それらすべてのサービスに関する情報が表示されます。

-w

-wsdlUrl

1つ以上のサービス・エンドポイントを定義するWSDLファイルのURL。

-V

-version

情報を表示するサービスのバージョン。
デフォルトの未指定バージョンを表すには、-文字列を使用します。

-v

-verbose

各エンドポイントの追加情報を表示します。

-s

-sphereUrl

スフィアのURL。http://hostname:port/btmcentral/sphere/
スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

次に、サンプル・コマンドの出力を示します。

btmcli showService -n OrderService

OrderService (Version -)
QName: http://amberpoint.com/orderService:OrderService

Name: OrderServiceSOAP  Binding: SOAP/HTTP   Managed by: Monitored by Observer
http://islam.us.oracle.com:7412/bookmart/order/OrderSerrvice

btmcli showService -qname http://schemas.amberpoint.com/sphere:SphereService

AP_Sphere_Service (Version 7.0.0.0-ExM-Hegemony)
QName: http://schemas.amberpoint.com/sphere:SphereService

Name: AP_Sphere_Service_SOAP Binding: SOAP/HTTP
Managed by: AmberPoint AP_Core_Service
http://islam.us.oracle.com:8080/btmcentral/sphere/

例

次の例では、showServiceコマンドを使用して、指定されたwsdlで定義されるサービスの情報を表示します。

btmcli showService
-w http://jbujes-desk.edgility.com:7001/bookmart/credit/CreditService?wsdl
-s http://localhost:8080/btmcentral/sphere -l admin:abracadabra

10.51 unmonitorEndpoint

unmonitorEndpointコマンドを使用して、指定されたエンドポイントが登録されているモニター・エージェントによる、そのエンドポイントの監視を停止するために使用します。

監視が停止すると、パフォーマンス測定は記録されず、メッセージはログに記録されず、トランザクションはトレースされません。

監視を再度有効にするには、monitorEndpointコマンドを使用します。

コマンド構文

btmcli unmonitorEndpoint -n name | -e endpointUrl1 [[endpointUrl2] ...]
-s sphereUrl -l username:password

名前

ロング名

説明

-n

-name

監視を停止するエンドポイントのわかりやすい名前。

-e

-endpointUrl

監視を停止するエンドポイントのエンドポイントURLのリスト。
これがWebサービスの場合は、エンドポイントにアクセスする実際のURLを指定できます。それ以外のタイプのコンポーネントの場合は、管理コンソールの「プロファイル」タブを確認して、エンドポイントのURLを特定してください。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例に、unmonitorEndpointコマンドを使用してMyEndpointの監視を停止する方法を示します。

btmcli unmonitorEndpoint -n MyEndpoint
-s http://localhost:8080/btmcentral/sphere/
-l Admin:abracadabra

10.52 unregister

unregisterコマンドを使用して、サービス、WSDLまたはエンドポイントをスフィアから登録解除します。

- -wまたは-nオプションを使用して登録解除したサービスごとに、登録解除された項目に関する情報が次の形式で出力されます。
WSDL_URL:serviceFriendlyName

- -eおよび-interfaceQNameオプションを使用して登録解除したエンドポイントごとに、登録解除された項目に関する情報が次の形式で出力されます。
endpointUrl:endpointBinding

登録解除する項目がスフィアに登録されていない場合、このコマンドでは出力が生成されません。

特定のエンドポイントを登録解除するには、そのエンドポイントが属するサービスを-nまたは-qnameフラグを使用して指定し、登録解除するエンドポイントをendpointUrlおよび-interfaceQNameフラグを使用して指定します。一般的にこのオプションは、依存性検出済エンドポイントが正しく作成されなかった場合に役立ちます。-interfaceQNameフラグを指定しない場合、依存性検出済エンドポイントのみが登録解除されます。

サービス名またはWSDL URLを指定して、1つのWSDLファイルのエンドポイントで構成される重複サービスを登録解除する場合も、同じ動作になります。複数のWSDLファイルのエンドポイントで構成される重複サービスを登録解除する場合は、サービスの指定方法によって異なる動作になります。

- サービスがわかりやすい名前または修飾名で指定されている場合、サービス全体が登録解除されます。

- WSDLが-wsdlUrlフラグにより指定されている場合、そのWSDLのエンドポイントのみが登録解除されます。その他のWSDLから検出されたエンドポイントは影響を受けません。

サービスまたはエンドポイントを登録解除すると、その履歴にアクセスできなくなります。サービスまたはエンドポイントを再登録して、その履歴にアクセスする可能性がある場合は、そのUUIDを保存する必要があります(「プロファイル」タブに示されています)。

コマンド構文

btmcli unregister -n serviceName | -qname qualifiedName | -w wsdlUrl1
[[wsdlUrl2...]
[-V version] [-e endpointUrl] [-interfaceQName interfaceQName] [-f]
-s sphereUrl -l username:password

名前

ロング名

説明

-n

-name

スフィアから削除するサービスのわかりやすい名前。
名前が一意でない場合は、-V (version)フラグを使用して修飾する必要があります。

-qname

--

スフィアから削除するサービスの修飾名(WSDL targetNamespaceにサービス名を追加したもの)。
このオプションは、異なる修飾名を持つ複数のサービスに、同じわかりやすい名前がスフィアで割り当てられている場合に役立ちます。

名前が一意でない場合は、-V (version)フラグを使用して修飾する必要があります。

-w

-wsdlUrl

登録解除するサービスを持つWDSLファイルのURL。
このコマンドでは、-wまたは-nフラグのいずれか1つを指定する必要があります。

-V

-version

登録解除するサービスのバージョン。-qnameまたは-nameオプションとあわせて使用する必要があります。
デフォルトの未指定バージョンを表すには、-文字列を使用します。

-e

--

特定のエンドポイントのURL。この場合、対応するWSDLは登録解除されません。

-interfaceQName

登録解除する特定のエンドポイントのインタフェースの修飾名。

-f

-force

サービスのエンドポイントが監視されていても、そのサービスを登録解除します。監視は、サービスを登録解除する前に停止されます。

-s

-sphereUrl

WSDLがインストールされているスフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例では、指定されたwsdl内のサービスを登録解除します。

btmcli unregister -w http://myProductionBox:28006/OrderService.wsdl
-s http://mydomain.com/btmcentral/sphere/ -l Admin:abracadabra

10.53 unregisterContainer

unregisterContainerコマンドを使用して、以前Business Transaction Managementに登録したコンテナを登録解除します。このコマンドは、コンテナが完全にオフラインになった後に使用してください。このコマンドを使用してコンテナを登録解除した方が、コンテナに含まれる各エンドポイントを登録解除するよりも短時間で完了します。

物理コンテナは、システムが停止状態とマークするまで十分に長い時間オフラインにしてから登録解除してください。

このコマンドによって、コンテナ内のすべてのシステム・サービス、サービス記述子およびエンドポイントも登録解除されます。コンテナ内のすべての監視対象エンドポイントは監視されなくなり、これらのエンドポイントの測定は削除されます。

コマンド構文

btmcli unregisterContainer -baseAddress baseAddress | -fn friendlyName
-s sphereURL -l username:password

名前

ロング名

説明

-i

-baseAddress

スフィアにある既存のエントリ・ポイントのベース・アドレス。
ベース・アドレスの形式: scheme://host:port/

-fn

-friendlyName

登録解除するコンテナのわかりやすい名前。わかりやすい名前が一意でない場合、かわりにbaseAddressオプションを使用する必要があります。

-s

-sphereUrl

必須。登録解除するコンテナ内に存在するスフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次のコマンドは、MyAppsというわかりやすい名前を持つコンテナを登録解除します。

btmcli
btmcli unregisterContainer -fn MyApps
-s http://localhost:8080/btmcentral/sphere/
-l admin:abracadabra

10.54 unregisterMonitor

unregisterMonitorコマンドを使用して、指定したモニターをスフィアから登録解除します。

このコマンドは、モニターが完全にオフラインになっているときにのみ使用してください。モニターは、システムが停止状態とマークするまで十分に長い時間オフラインにしてから登録解除してください。

モニター・エージェントを登録解除すると、次のような影響があります。

- そのモニターに関連付けられているすべての監視対象エンドポイントの監視が停止されます。

- 監視が停止されたエンドポイントの測定が失われます。このコマンドは、モニターが完全にオフラインになっているときにのみ使用してください。

コマンド構文

btmcli unregisterMonitor -baseAddress address  | -fn friendlyName
- s sphereUrl -l username:password

名前

ロング名

説明

--

-baseAddress

スフィア内のモニターのベース・アドレス。次に例を示します。
http://localhost:8080/btmmonitor/agent/agent

-fn

-friendlyName

登録解除するモニター・エージェントのわかりやすい名前。
わかりやすい名前が一意でない場合、かわりに-baseAddressオプションを使用する必要があります。

-s

-sphereUrl

WSDLがインストールされているスフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

例

次の例では、指定されたベース・アドレスを持つモニターを登録解除します。

btmcli unregisterMonitor -base address
http://localhost:8080/btmmonitor/agent/agent
-s http://mydomain.com/btmcentral/sphere/ -l admin:abracadabra

10.55 updateProfileData

updateProfileDataコマンドを使用して、指定されたオブジェクト・セットのプロファイル属性データを更新使用します。このコマンドは既存オブジェクトのみを更新し、指定されたオブジェクトを見つけることができない場合はエラーを返します。

このコマンドは、次に示す特定の2つの状況で役立ちます。

- オブジェクトのコレクションを、属性値の共通セットで更新する必要がある場合。たとえば、一連のサービスのアプリケーション・グループを同じ値に設定する場合です。

- オブジェクトのコレクションの属性値を、それぞれ別の値に設定する必要がある場合。たとえば、外部データ・ソースから取得したデータをインポートする場合です。

詳細は、後述の説明を参照してください。

コマンド構文

btmcli updateProfileData -t type [-query filterQuery]
[-val name1:val1 [[name2:val2]...]]] | [-profileData profileData]
-s sphereUrl -l username:password

名前

ロング名

説明

-t

-type

更新するオブジェクトのタイプ。

-query

-filterQuery

問合せに一致するオブジェクト・セットを選択します。
フィルタ・ツールを使用してAQL問合せを作成し、それらの問合せをコピーしてコマンドラインに貼り付けます。

-val

-attributeValues

選択したオブジェクトを更新するために使用するname:valueペアのリスト。リスト内の各エントリは、属性の名前と値を示します。
この引数を指定する場合は、-query引数も指定する必要があります。

よく使用される属性名およびオブジェクト・タイプの完全なリストは、「属性名」の項を参照してください。

--

-profileData

更新するプロファイル・データを含むファイルの名前を指定します。このファイルには、指定したフラグに応じて、2つの形式のうちのいずれかを設定できます。
-query引数を指定した場合、ファイルはJavaプロパティ・ファイルで、各エントリは属性名とそれに対応する値です。

-query引数を指定しない場合、このファイルはcsv形式のテキスト・ファイルで、最初の行に更新する属性を指定し、それ以降の行にオブジェクト・インスタンスの値を指定します。更新されるオブジェクトを識別するために、キー属性を含める必要があります(オブジェクトIDまたはそのタイプのナチュラル・キーを構成する属性)。

-s

-sphereUrl

スフィアのURL。
http://hostname:port/btmcentral/sphere/

スフィアにAP_SPHERE_URL環境変数を設定している場合、このフラグは必要ありません。

-l

-userLogin

スフィアに関連付けられているユーザー名とパスワード。形式はusername:passwordです。この資格証明セットは、btmadminロールのユーザーに属している必要があります。
ログイン資格証明の設定の詳細は、10.1.3項「CLIコマンドにアクセスする場合のセキュリティ・オプション」を参照してください。

encryptPasswordコマンドを使用してパスワードを暗号化できます。

説明

このコマンドは、基本的に次の3つの形式で使用します。

- オブジェクト・セットについて、1つ以上の属性を同じ値に更新する場合は、次の形式を使用します。
updateProfileData -t myType -query myQuery -val attr1=valueattr2=value ...

または次の形式を使用します。

updateProfileData -t myType -query myQuery -profileData javaPropFile

- 各オブジェクトの属性値がそれぞれ異なるオブジェクト・セットをバルク更新する場合(外部データベースから更新する場合など)は、次の形式を使用します。

updateProfileData -t myType -profileData CSVFile_with_1_row_per_Object_to_update

例

次の例に、updateProfileコマンドを示します。

btmcli updateProfileData -t endpoint -profileData MyJavaPropertyFile
-s http://localhost:8080/btmcentral/sphere/ -l Admin:abracadabra

11 ユーティリティ

この章では、Business Transaction Managementユーティリティについて説明します。ユーティリティを使用して、データベースへの接続と管理、システム・サービス・デプロイメント・ログ・ファイルの管理、およびBusiness Transaction Management製品に関する情報の表示を行います。この章では、次の項目について説明します。

- コマンドライン・ユーティリティについて

- datastoreUtilユーティリティ

- logMergerユーティリティ

- showProductInfoユーティリティ

11.1 コマンドライン・ユーティリティについて

Business Transaction Managementには、コマンドラインから特定のタスクを実行できる一連のコマンドライン・ユーティリティが含まれています。

Javaプラットフォームの場合、ユーティリティは[install_dir]/toolsに配置されています。

Windowsプラットフォームの場合、ユーティリティはBusiness Transaction ManagementにバンドルされているJREを使用します。

UNIX系システムでは、次のいずれかを実行して、使用するJREを指定する必要があります。

- JAVA_HOME環境変数を設定し、次のディレクトリを削除します。
BTM_install_dir/server/jre directory

- BTM_install_dir/server/jreを有効なJREディレクトリへのリンクで置き換えます。

次の表に、Business Transaction Managementユーティリティを示します。

名前

説明

datastoreUtil

データベースに接続できます。接続後に、次の処理を行うことができます。

- 接続したデータベース内に指定されたスキーマ定義のDDLを生成します。

- 接続したデータベース内の指定されたスキーマのステータスを確認します。

- 接続したデータベース内に指定されたスキーマを作成します。

- 接続したデータベース内の指定されたスキーマをアップグレードします。

- 接続したデータベースから指定されたスキーマ全体を削除します。

- 後でデータベースに簡単に再接続するためのデータベース接続情報をファイルに保存します。

- データベース・インスタンスの所有者を表示します(サービス名およびUUID)。

- 現在の所有者のナレッジを削除して、データベース・インスタンスの所有権をリセットします。

- データベース検索モードを開始します(データを検索および表示するコマンド)。

logMerger

Business Transaction Managementシステム・サービス・デプロイメント・ログ・ファイル(logdir)をマージして、分析またはアーカイブを統合します。

showProductInfo

Business Transaction Management製品に関する情報を出力します。

11.2 datastoreUtilユーティリティ

datastoreUtilユーティリティの最も一般的な用途は、Business Transaction Management製品のインストールの支援です。datastoreUtilユーティリティを使用してスフィアのデータベース・ユーザーの適切なデータベース表、パフォーマンス・データベースおよびトランザクション・データベースを事前に作成しない場合は、構成時に、これらが自動的に作成されます。

generateSchemaコマンドを使用すると、対象のデータベース環境のDDLを作成できます。generateSchemaコマンドの出力は、Business Transaction Management製品に必要な表およびビューを作成する入力(適切なデータベース・ユーティリティを使用)として使用できます。

datastoreUtilユーティリティを使用してデータベースに接続します。接続後に、次の処理を行うことができます。

- 接続したデータベース内に指定されたスキーマ定義のDDLを生成します。

- 接続したデータベース内の指定されたスキーマのステータスを確認します。

- 接続したデータベース内に指定されたスキーマを作成します。

- 接続したデータベース内の指定されたスキーマをアップグレードします。

- 接続したデータベースから指定されたスキーマ全体を削除します。

- 後でデータベースに簡単に再接続するためのデータベース接続情報をファイルに保存します。

- データベース・インスタンスの所有者を表示します(サービス名およびUUID)。

- 現在の所有者のナレッジを削除して、データベース・インスタンスの所有権をリセットします。

- 接続したデータベースの定義を、SQL dml文を含むテキスト・ファイルに特定のデータベース形式でダンプします。

- データベース検索モードを開始します(データを検索および表示するコマンド)。

datastoreUtilユーティリティの起動

datastoreUtilユーティリティを起動するには、ツール・ディレクトリにナビゲートし、コマンドラインから次のいずれかを使用します。

- Windows: datastoreUtil.bat

- Unix: datastoreUtil.sh

ユーティリティの開始後に、次の項で説明するコマンドをコールできます。複数の引数があるコマンドの場合は、説明されている順序で引数をコールする必要があります。

exitコマンドを使用して、ユーティリティを終了します。

11.2.1 コマンド

datastoreUtilのコマンドは、次のとおりです。

コマンド

コマンド

コマンド

help

generateSchema

checkOwner

connect

createSchema

resetOwner

saveConnection

checkSchema

dumpDataBase

close

upgradeSchema

--

exit

dropSchema

--

helpコマンド

次の構文を使用して、ヘルプを取得します。

help | help command

helpコマンドを使用して、すべてのコマンドのヘルプを表示するか、またはコマンド名を入力して単一コマンドのヘルプを表示します。

connectコマンド

ユーザー指定の接続情報を使用して、データベースに接続します。

connect databaseType|filename

databaseType: oracleを指定します。これが唯一サポートされている値です。

filename: saveConnectionコマンドで指定されているファイルの名前

connectコマンドを使用して、データベース接続情報を入力し、データベースに接続します。接続するデータベースに関する次の情報が必要となります。

- ドライバ名

- ユーザー名

- パスワード

- URL接続文字列

接続後に、saveConnectionコマンドを発行して接続情報をファイルに保存できます。同じデータベースに次回接続する場合は、connectコマンドにファイル名を指定できます。データベース・タイプを指定すると、ユーティリティによって対応するデフォルト・ドライバが自動的に選択されます。

closeコマンド

以前にconnectコマンドを使用してオープンした接続をクローズします。このコマンドはパラメータを取りません。

generateSchemaコマンド

指定されたスキーマ定義のDDLを生成します。このコマンドをコールするためにデータベースに接続する必要はありません。

このコマンドのかわりに、generateを使用することもできます。

generateSchema  schemaType databaseType
[[directory] targetSchema] -partition|-nopartition

generate schemaType databaseType [[directory]
targetSchema] -partition|-nopartition

schemaType: 次のいずれか1つのスキーマ・タイプ。

- sphere: スフィア・データベースのスキーマ(sphereDBユーザー)

- exm: トランザクション・データベースのスキーマ(transactionDBユーザー)

- performance: パフォーマンス・データベースのスキーマ(measurementDBユーザー)

- monitorgroup: モニター・グループのスキーマ

- msglog: システム・メッセージ・ログのスキーマ

databaseType: サポートされているデータベース・タイプの1つ。

- oracle

directory: DDLファイルを生成する場所(デフォルトではローカル・ディレクトリ)

targetSchema: sphereDB、transactionDB、measurementDBなど、特定のユーザーの生成済スキーマをターゲットに指定します。

たとえば、データベースに対する高レベルの管理権限を持っており、より低レベルの権限を持つユーザー用のスキーマを作成するとします。次の例のような構文を使用します。

generateSchema sphere oracle \temp sphereUser

-partition | -nopartition

このフラグは、指定したschemaTypeがperformanceまたはmonitorgroupの場合に必要です。指定したschemaTypeがその他の値である場合、このフラグは必要なく、使用した場合は無視されます。

Oracle Enterprise Editionを使用している場合は、-partitionフラグを指定して、Oracleのパーティション化機能を利用できるperformanceまたはmonitorgroupスキーマを作成できます。この機能を利用しない場合や、ご使用のOracleエディションでパーティション化機能が提供されていない場合は、-nopartitionを指定する必要があります(performanceまたはmonitorgroupスキーマを作成している場合)。

checkSchemaコマンド

接続したデータベース内の指定されたスキーマのステータスを確認します。

次の構文図に示すように、このコマンドのかわりに、checkを使用することもできます。

checkSchema schemaType

check schemaType

schemaType: 次のいずれか1つのスキーマ・タイプ。

- sphere: スフィア・データベースのスキーマ(sphereDBユーザー)

- exm: トランザクション・データベースのスキーマ(transactionDBユーザー)

- performance: パフォーマンス・データベースのスキーマ(measurementDBユーザー)

- monitorgroup: モニター・グループのスキーマ

- msglog: システム・メッセージ・ログのスキーマ

checkSchemaコマンドを使用して、接続したデータベース内に指定されたスキーマ・タイプを確認します。connectコマンドが正常に実行されてから、checkSchemaコマンドを実行する必要があります。checkSchemaコマンドにより、データベースでのスキーマのステータスが表示されます。データベース・スキーマのステータスが最新ではない場合、このコマンドにより、見つかった差異およびデータベース・スキーマのアップグレードのために適用する必要があるDDLが表示されます。

このコマンドではデータベース・スキーマは変更されません。このコマンドライン・ユーティリティからデータベース・スキーマを自動的にアップグレードする場合は、upgradeSchemaコマンドを使用します。

createSchemaコマンド

接続したデータベース内に指定されたスキーマを作成します。connectコマンドが正常に実行されてから、createSchemaコマンドを実行する必要があります。

このコマンドのかわりに、createを使用することもできます。

createSchema schemaType -partition | -nopartition

create schemaType -partition | -nopartition

schemaType: 次のいずれか1つのスキーマ・タイプ。

- 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スキーマを作成している場合)。

createSchemaコマンドの前またはこのコマンドのかわりに、checkSchemaおよびupgradeSchemaコマンドを使用することもできます。

upgradeSchemaコマンド

接続したデータベース内の指定されたスキーマをアップグレードします。

このコマンドのかわりに、upgradeを使用することもできます。

upgradeSchema schemaType

upgrade schemaType

schemaType: 次のいずれか1つのスキーマ・タイプ。

- sphere: スフィア・データベースのスキーマ(sphereDBユーザー)

- exm: トランザクション・データベースのスキーマ(transactionDBユーザー)

- performance: パフォーマンス・データベースのスキーマ(measurementDBユーザー)

- monitorgroup: モニター・グループのスキーマ

- msglog: システム・メッセージ・ログのスキーマ

upgradeSchemaコマンドを使用して、接続したデータベースの指定されたスキーマをアップグレードします。connectコマンドが正常に実行されてから、upgradeSchemaコマンドを実行する必要があります。upgradeSchemaコマンドによって、欠落している表、列または索引がデータベースに追加されます。

upgradeSchemaコマンドを実行する前に、checkSchemaコマンドを実行できます。

upgradeSchemaコマンドでは、欠落している要素が追加されるのみです。要素が削除されることはありません。upgradeSchemaコマンドはロールバックできません。

dropSchemaコマンド

接続したデータベースから指定されたスキーマ全体を削除します。

このコマンドのかわりに、dropを使用することもできます。

dropSchema schemaType

drop schemaType

schemaType: 次のいずれか1つのスキーマ・タイプ。

- sphere: スフィア・データベースのスキーマ(sphereDBユーザー)

- exm: トランザクション・データベースのスキーマ(transactionDBユーザー)

- performance: パフォーマンス・データベースのスキーマ(measurementDBユーザー)

- monitorgroup: モニター・グループのスキーマ

- msglog: システム・メッセージ・ログのスキーマ

dropSchemaコマンドを使用して、接続したデータベースからスキーマ全体を削除します。connectコマンドが正常に実行されてから、dropSchemaコマンドを実行する必要があります。

警告: dropSchemaコマンドでは、すべての表および表に格納されているすべてのデータが削除されます。接続したデータベースの未保存のデータの中に保存したいデータがある場合は、このコマンドを実行する前にデータをエクスポートまたは保存します。dropSchemaコマンドはロールバックできません。

saveConnectionコマンド

データベース接続情報をファイルに保存します。

このコマンドのかわりに、saveを使用することもできます。

saveConnection filename

save filename

filename: ユーザー、パスワード、URLおよびドライバの値を保存するファイルの名前。

saveConnectionコマンドを使用して、ユーザー、パスワード、URLおよびドライバの値をファイルに保存します。

データベースへの接続後に、saveConnectionコマンドを発行して、接続情報をファイルに保存できます。connectコマンドでファイル名を指定すると、後で同じデータベースに再接続できます。未使用ファイルは、接続情報が含まれているため必ず削除してください。

checkOwnerコマンド

データベース・インスタンスの所有者を表示します(サービス名およびUUID)。

このコマンドのかわりに、ownerを使用することもできます。

checkOwner

owner

データベースへの接続後に、checkOwnerコマンドを発行して、データベース・インスタンスを所有するサービスのUUIDと名前を表示できます。特定のデータベース・インスタンスに接続できるのは、サービス所有者のみです。所有権をリセットするには、resetOwnerコマンドを使用します。

resetOwnerコマンド

現在の所有者のナレッジを削除して、データベース・インスタンスの所有権をリセットします。

このコマンドのかわりに、resetを使用することもできます。

resetOwner

reset

resetOwnerコマンドを使用して、特定のデータベースに関連付けられているサービス所有権情報を削除します。connectコマンドが正常に実行されてから、resetOwnerコマンドを実行する必要があります。リセット後に、データベースにアクセスする次のサービスがデータベース・インスタンスの所有権を取得します。

dumpDatabase

特定のデータベースのコンテンツを、SQL dml文を含むテキスト・ファイルに特定のデータベース形式でエクスポートします。

このコマンドのかわりに、dumpを使用することもできます。

このコマンドを発行するには、接続するためのコマンドが正常に実行されている必要があります。

dumpDatabase schemaType databaseType [directory]

dump schemaType databaseType [directory]

dumpDatabaseコマンドを使用して、指定されたスキーマに含まれているデータを、別のデータベースへのインポートに使用できるSQL dml文を含むテキスト・ファイルにエクスポートします。データベース・タイプを指定すると、テキスト・ファイルがそのデータベース・タイプでサポートされているSQL文に書式設定されます。

注意: データベースにclobフィールドが含まれている場合、clobフィールドは生成後のテキスト・ファイルで4000文字に切り捨てられてます。

schemaType: 次のいずれか1つのスキーマ・タイプ。

- sphere: スフィア・データベースのスキーマ(sphereDBユーザー)

- exm: トランザクション・データベースのスキーマ(transactionDBユーザー)

- performance: パフォーマンス・データベースのスキーマ(measurementDBユーザー)

- monitorgroup: モニター・グループのスキーマ

- msglog: システム・メッセージ・ログのスキーマ

databaseType: サポートされているデータベース・タイプの1つ。

- oracle

directory: SQLファイルが生成される場所。デフォルトの場所はローカル・ディレクトリです。

exitコマンド

次のコマンドを使用して、datastoreUtilユーティリティを終了します。

exit

11.3 logMergerユーティリティ

logMergerユーティリティを使用して、Business Transaction Managementシステム・サービス・ログ・ファイル(logdir)を分析またはアーカイブ用にマージします。-configフラグを使用して、指定されたログ・マージャ構成ファイルからユーティリティ・オプションをロードできます。コマンドライン・オプションは、構成ファイルで定義されているオプションをオーバーライドします。

ログ・マージャ構成ファイルについては、logMergerユーティリティの後に説明します。

コマンド構文

logMerger -config config_file_name |-dir directory|-url url
[-username username -password password]
[-output output_file_name] [-overwrite true|false]
[-format format_pattern]
[[-from start_time -to end_time]|[-last number_of_hours]]
[-loggerName logger_name] [-loggerLevel level|level+]
[-className class_name] [-methodName method_name]
[-userName user_name] [-V]

名前

説明

-config

指定された構成ファイルからオプションをロードします。コマンドライン・オプションは、構成ファイルで定義されているオプションをオーバーライドします。logMerger構成ファイルの例は、11.3.1項「logMerger構成ファイル」を参照してください。

-dir

マージするBusiness Transaction Managementのlogdirディレクトリを含むディレクトリ。logMergerユーティリティは、指定されたディレクトリのすべてのサブディレクトリでlogdirディレクトリを検索します。複数の-dirディレクトリ・オプションを指定できます。各ディレクトリは個別のエントリである必要があります。

-url

logdirをマージする実行中のBusiness Transaction ManagementのURL。サービスへのアクセスに必要なユーザー資格証明が含まれます。logMergerユーティリティは、-usernameおよび-passwordオプションで指定されているBusiness Transaction Managementのユーザー資格証明を使用して、このURLのサービスと通信します。複数の-urlサービスURLオプションを指定できますが、すべてのサービスのユーザー名およびパスワード資格証明が同じである必要があります。各URLは個別のエントリである必要があります。
注意: 各サービスにアクセスするために異なるユーザー名およびパスワード資格証明を必要とする複数のサービスURLのロギングをマージする場合は、logMerger構成ファイルを使用する必要があります。

-username

urlオプションに関連付けられているBusiness Transaction Managementサービスにアクセスするためのユーザー名資格証明。
注意: -usernameフラグは、次に説明する-userNameフラグとは異なります。これら2つのフラグ名では大/小文字が区別されます。

-password

urlオプションに関連付けられているBusiness Transaction Managementサービスにアクセスするためのパスワード資格証明。

-output

マージ結果を保存する場所を指定します。出力ファイルがすでに存在する場合、-overwriteオプションの値がtrueである場合を除き、logMergerユーティリティは上書きなしで終了します。
出力オプションが指定されていない場合、結果の出力ファイルは、logMergerユーティリティのコール元であるディレクトリに書き込まれます。デフォルト値はlogmerger_<date>_<time>.logです。

-overwrite

既存の出力ファイルを上書きするには、trueを指定します。デフォルトはfalseです。

-format

マージ結果の各ログ・エントリの出力書式を指定します。可能な書式トークンには、ログ・エントリ・プロパティが含まれます。

- time

- methodName

- loggerName

- loggerLevel

- className

- userName

さらに4つの特殊なトークンがあります。

- message: 実際のログ・メッセージ

- logName: 各ログ・ファイルのlogHeader要素にあるlogName属性であるログ識別子

- eol: テキストを区切る行末文字

- tab: テキストを区切るタブ文字

各書式トークンは、プラス記号(+)で区切られます。

各ログ・エントリの出力後には、常に行末文字があります。

デフォルトの書式パターンは、time+logName+eol+loggerLevel+messageです。

-from

start_timeより後のタイムスタンプを使用してログ・エントリをマージします。
このオプションが指定されていない場合は、-lastオプションが指定されている場合を除き、開始時間制限がありません。

時間書式MM/dd/yy HH:mm:ssを使用します。たとえば、「10/05/06 00:00:01」とします。

-to

end_timeより前のタイムスタンプを使用してログ・エントリをマージします。
このオプションが指定されていない場合は、終了時間制限がありません。

時間書式MM/dd/yy HH:mm:ssを使用します。たとえば、「10/05/06 17:21:57」とします。

-last

過去数時間のログ・エントリをマージします。
-fromまたは-toが指定されている場合、このオプションは無視されます。

-loggerName

logger_nameが指定されたロガーによって生成されたログ・エントリのみをマージします。

-loggerLevel

levelのみが指定されている場合は、指定されたロガー・レベルを持つログ・エントリをマージします。
level+が指定されている場合は、指定されたレベル以上のレベルを持つログ・エントリをマージします。

次のloggerLevel属性の値は、レベルの高いものから順にリストされています。

SEVERE

WARNING

INFO

CONFIG

FINE

FINER

FINEST

-className

class_nameで指定されたクラスによって生成されたログ・エントリのみをマージします。

-methodName

method_nameで指定されたメソッドによって生成されたログ・エントリのみをマージします。

-userName

user_nameで指定されたユーザーによって生成されたログ・エントリのみをマージします。
注意: -userNameフラグは、前出の-urlフラグのサブフラグとして説明されている-usernameとは異なります。これら2つのフラグ名では大/小文字が区別されます。

-V

ユーティリティのバージョン情報を表示して終了します。

例

1. 次の例では、サーバーの\BTM_INSTALL_DIR\btmstorageディレクトリ(およびその下のすべてのサブディレクトリ)でログ・エントリを収集して、出力ファイルBTMLoggingOutputTo10_05_06に送信します。上書きオプションがtrueに設定され、loggerLevelがINFO以上(WARNING、SEVERE)のすべてのエントリが複数の書式オプションと2.5日の日付/時間範囲を使用して収集されます。

logMerger -dir "C:\BTM_INSTALL_DIR\btmstorage"
-output BTMloggingOutputTo10_05_06 -overwrite true
-loggerLevel INFO+ -format time+loggerName+userName+message+eol
-from "10/03/06 00:00:01" -to "10/05/06 12:00:00"

2. 次の例では、ローカル・マシンのディレクトリ\BTM_INSTALL_DIR\btmstorage\btmuiおよびBTM_INSTALL_DIR\btmstorage\btmtransactionでログ・エントリが収集され、エントリが出力ファイルBTMuiNtransactionLoggingOutLast24に送信されます。上書きオプションがtrueに設定され、loggerLevelがINFOのすべてのエントリが複数の書式オプションを使用して収集されます。ユーティリティによって、過去24時間に発生した、名前がSalesOpsManagerのユーザーのアクションによって生成されたすべてのロギング・エントリが収集されます。

logMerger -dir "C:\BTM_INSTALL_DIR\btmstorage\btmui"
-dir "C:\BTM_INSTALL_DIR\btmstorage\btmtransaction"
-output BTMuiNtransactionLoggingOutLast24 -overwrite true
-loggerLevel INFO -format time+userName+messgae
-userName SalesOpsManager -last 24

3. 次の例では、3つのURLからログ・エントリが収集されます。
http://remoteServer1:8080/btmcentral/sphere http://remoteServer1:8080/btmcentral/sphere http://remoteServer1:8080/btmcentral/sphere

これらのサービスURLにアクセスするためのユーザーおよびパスワード資格証明は同じです(同じでない場合は、構成ファイルを使用する必要があります)。ログ・エントリが出力ファイルremoteServiceOutputFrom10_13_06に送信され、loggerLevelがINFO以上(WARNING、SEVERE)のすべてのエントリが複数の書式オプションおよび2006年10月13日の深夜0時0分1秒からの日付範囲を使用して収集されます。

logMerger -url "http://remoteServer1:8080/btmcentral/sphere"
-url "http://remoteServer2:8080/btmcentral/container"
-url "http://remoteServer1:8080/btmcentral/agent"
-username BTMAdminUser -password BTMAdminUserPwd
-output remoteServiceOutputFrom10_13_06
-loggerLevel INFO+ -format time+message+eol -from "00:00:01 10/13/06"

4. 次の例では、ユーザー定義のLogMerger構成ファイルmyLogMergerConfigFile.xml内の設定が使用されます。logMergerを頻繁に使用して同じタイプの情報を収集する場合に、このオプションを使用します。コマンドラインにオプションを追加して、構成ファイルに定義されているオプションを上書きできます。

logMerger -config myLogMergerConfigFile.xml

11.3.1 logMerger構成ファイル

次のテキストには、サンプルのログ・マージャ構成ファイルの書式設定とコンテンツが含まれています。ファイルに指定されているオプションはコマンドライン・オプションによって上書きされます。

構成ファイルを介してリモート・サービスURLにアクセスするためのパスワードを暗号化する場合は、encryptPasswordコマンドを使用できます。

次の項で説明する構成ファイルに定義されている属性は、次で囲まれています。

<ap:logmerger xmlns:ap="http://namespace.amberpoint.com/amf" debug="false">
.
.
.
</ap:logmerger>

ソース属性の例と説明

<ap:sources>
<ap:source dir="C:/Program Files/AmberPoint/SOAManagementSystem/
server/amberpoint"/>
<ap:source url="http://remoteServerHost1:7001/apcentral/sphere"
username="SMSUser1" password="SMSUserPwd1"/>
<ap:source url="http://remoteServerHost2:7001/apcontainer/container"
username="SMSUser2" password="SMSUserPwd2"/>
<ap:source url="http://remoteServerHost3:7001/eProxy/agent/agent"
username="SMSUser3" password="SMSUserPwd3"/>
<ap:source url="http://remoteServerHost1:8080/apcentral/sphere"
username="ALSMUser1" password="ALSMUserPwd1"/>
</ap:sources>

複数のソースdirエントリを指定できます。各ソース・ディレクトリは個別のエントリである必要があります。

dir: マージするBusiness Transaction Managementのlogdirディレクトリを含むディレクトリ。logMergerユーティリティは、指定されたディレクトリのすべてのサブディレクトリでlogdirディレクトリを検索します。

複数のソースURLエントリを指定できます。各ソースURLは個別のエントリである必要があります。

url: 実行中のBusiness Transaction ManagementサービスのURL。このユーティリティは、-usernameおよび-passwordオプションで指定されているユーザー資格証明を使用して、このURLのサービスと通信します。

username: Business Transaction Managementサービスにアクセスするためのユーザー名

password: Business Transaction Managementサービスにアクセスするためのパスワード

フィルタ属性の例と説明

<ap:filter
from="10/02/06 09:00:00"
to="10/02/06 11:59:00"
last="24"
loggerName="com.amberpoint.services.lifecycle.initialize"
loggerLevel="INFO+"
className="com.amberpoint.util.soa.services.urservice.UrServiceImpl"
methodName="createServices"
userName="BTMdministrator"

フィルタ属性は、完全一致のすべての属性が含まれているメッセージのログ履歴を問い合せる場合に使用されます。

たとえば、フィルタ属性last="24" loggerLevel="INFO"は過去24時間にログに記録されたINFOメッセージをマージします。

フィルタ・オプションが指定されていない場合は、すべてのログ・メッセージが含まれます。

from: タイムスタンプがfromより後のログ・エントリが含まれます。この属性が指定されていない場合は、lastオプションが指定されている場合を除き、開始時間制限がありません。

時間書式MM/dd/yy HH:mm:ssを使用します。たとえば、「from="12/25/05 10:34:25"」とします。

to: タイムスタンプがtoより前のログ・エントリが含まれます。この属性が指定されていない場合は、終了時間制限がありません。

時間書式MM/dd/yy HH:mm:ssを使用します。たとえば、「to="12/25/05 10:34:25"」とします。

last: ログ・エントリの最後の時間数が含まれます。fromまたはtoが指定されている場合、この属性は無視されます。

loggerName: 指定されたロガー属性によって生成されるログ・エントリのみが含まれます。

loggerLevel: この属性はlevelまたはlevel+の2つの書式の値を受け入れます。

levelが指定されている場合は、指定されたロガー・レベルを持つログ・エントリのみが含まれます。

level+が指定されている場合は、指定されたレベル以上のレベルを持つログ・エントリが含まれます。

次のloggerLevel属性の値は、レベルの高いものから順にリストされています。

SEVERE

WARNING

INFO

CONFIG

FINE

FINER

FINEST

className: 指定されたクラスによって生成されたログ・エントリのみが含まれます。

methodName: 指定されたメソッドによって生成されたログ・エントリのみが含まれます。

userName: 指定されたユーザーによって生成されたログ・エントリのみが含まれます。

-->

出力ファイルの例と説明

<
<ap:output file="c:\temp\testmerger.log" overwrite="true"
format="time+logName+loggerName+eol+loggerLevel+message"/>

file: マージされたログ・ファイルが保存される場所。

出力ファイルがすでに存在する場合、overwrite属性の値がtrueである場合を除き、LogMergerユーティリティは処理を停止します。

file属性が指定されていない場合は、マージ済ログ・ファイルが新しいファイルlogmerger_<date>_<time>.logに保存されます。

overwrite: file属性で指定されたファイルがすでに存在する場合に、ユーティリティがそのファイルを上書きできるようにします。overwriteのデフォルト値はfalseです。

format: マージ結果の各ログ・エントリの出力書式を定義します。

可能な書式トークンには、すべてのログ・エントリ・プロパティが含まれます(ログ・ファイルのlogEntryノードの属性)。

値が指定されたログ・エントリ・プロパティの例を次に示します。

<logEntry
entryId="1127753975442:0"
time="Mon Sep 26 09:59:35 PDT 2005"
entryType="1"
dataSize="102"
loggerName="com.amberpoint.agent.backplane.servlet.ServletDriver"
loggerLevel="INFO"
methodName="findOldStorageDirectory"
className="com.amberpoint.agent.backplane.servlet.ServletDriver">

さらに4つの特殊なトークンがあります。

- message: 実際のログ・メッセージ

- logName: <logHeader>に格納されているログ・ファイルの名前。logHeaderを使用して、ログ・メッセージを生成するサービスが識別されます。

- eol: テキストを区切る行末文字

- tab: テキストを区切るタブ文字

各書式トークンは、プラス記号(+)で区切る必要があります。

LogMergerユーティリティでは、各ログ・エントリが出力ファイルに書き込まれた後に行末文字が挿入されます。

11.4 showProductInfoユーティリティ

showProductInfoユーティリティを使用して、各マシンにインストールしたBusiness Transaction Managementリリースに関する情報を収集します。また、サポート・リクエストの送信時には、この情報を確認してレポートする必要があります。

showProductInfoユーティリティでは、インストール済製品に関する次の情報がレポートされます。

- インストール済製品に関連付けられているリリース番号、ビルド番号およびビルド日付

- インストール済製品のアンインストーラの場所

- Business Transaction ManagementサポートのURL

- 製品ドキュメントのURL

- Business Transaction Management WebサイトのURL

12 Business Transaction Managementの管理

この章では、Business Transaction Managementの管理に役立つ情報を提供します。この章の内容は次のとおりです。

- オブザーバ

- 永続的データ

- Business Transaction Managementシステムのセキュリティ

- Business Transaction Managementのバックアップおよびリストア

- データの移行

- ロード・バランサの設定

- 検出問題の解決

- 管理に関するその他のトピック

12.1 オブザーバ

この項では、Business Transaction Managementオブザーバの管理に役立つ情報を提供します。この項の内容は次のとおりです。

- オブザーバについて

- オブザーバおよびモニターの構成

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

12.1.1 オブザーバについて

オブザーバは、監視対象のビジネス・アプリケーションのアプリケーション・サーバーにインストールするBusiness Transaction Managementコンポーネントです。オブザーバは、ビジネス・アプリケーションのコンポーネント間のメッセージおよびコールを監視します。

オブザーバには、プローブと呼ばれる1つ以上のサブコンポーネントが含まれています。各プローブにより、特定のタイプのビジネス・コンポーネントを監視する機能がオブザーバに提供されます。このため、オブザーバの監視機能はオブザーバに含まれているプローブのコレクションによって異なります。

次の表に、Business Transaction Managementに用意されているオブザーバのタイプ、各オブザーバ内に含まれているプローブおよび各プローブによってオブザーバに提供される監視機能を示します。

表12-1 使用可能なオブザーバ、オブザーバに含まれているプローブおよびオブザーバが監視するコンポーネントのタイプ

オブザーバ

プローブ

監視対象のコンポーネント

JavaEE

EJB

Enterprise JavaBean (EJB)

-

JAVA

Java (ローカルJavaメソッド・コールを監視します)

-

JAXRPC

JAX-RPC (JAX-RPC APIを使用するJMSトラフィックの監視が含まれています)

-

JAX-RS

JAX-RS (RESTfulアプリケーションを監視します。JSR 339を参照)

-

JAXWS

JAX-WS (JAX-WS APIを使用するJMSトラフィックの監視が含まれています)

-

JDBC

JDBC (Javaデータベース・コールを監視します)

-

JMS

JMS (JMS APIを使用するトラフィックを監視します)

-

RMI

Remote Method Invocation(RMI)

-

WEB_APP

Javaサーブレット・アプリケーション

OSB

OSB

Oracle Service Busプロキシ・サービスおよびビジネス・サービス

Oracle SOA Suite

SOA_ADAPTER

Oracle SOA Suite Adapter (このプローブは、Oracle Service Bus 10g用のオブザーバでのみ提供されます)

-

SOA_BIZRULE

Oracle SOA Suite Business Rule

-

SOA_B2B

SOA B2B (企業間)

-

SOA_BPEL

Oracle SOA Suite Business Process Execution Language (BPEL)

-

SOA_BPMN

Oracle SOA Suite Business Process Modelling Notation (BPMN)

-

SOA_CALLBACK

非同期コールのコールバック・リクエスト

-

SOA_DIRECT

SOAコンポジット間およびSOAとOSB間の直接バインディング・コール

-

SOA_EDN

Oracle SOA Suite Event Delivery Network

-

SOA_JCA

AQ、データベース、ファイル、FTP、JMS、MQ Series、ソケット、Oracle ApplicationsなどのJCAアダプタ

-

SOA_MEDIATOR

Oracle SOA Suite Mediator

-

SOA_REST

Oracle SOA Suite REST

-

SOA_SPRING

Oracle SOA Suite Spring Bean

-

SOA_WORKFLOW

Oracle SOAヒューマン・ワークフロー・コンポーネントおよび通知

-

SOA_WS

Oracle SOA Suite Webサービス(ヒューマン・ワークフローWebサービスなど)

-

SOA_WSA

Oracle SOA Suite Webサービス・アダプタ

-

WEB_APP

Javaサーブレット・アプリケーション

Oracle Fusion Applications (ADF-UI、ADF-BCおよびSOAデプロイメントをサポートしています)

ESS

Oracle Enterprise Scheduling Service

-

JavaEEオブザーバにあるすべてのプローブ(JDBCプローブを除く)

JavaEEオブザーバのエントリを参照

-

SOA Suiteオブザーバにあるすべてのプローブ

SOA Suiteオブザーバのエントリを参照

ユニバーサル

JavaEE、OSB、Oracle SOA SuiteおよびOracle Fusion Applicationsオブザーバにあるすべてのプローブ

JavaEE、OSB、Oracle SOA SuiteおよびOracle Fusion Applicationsオブザーバのエントリを参照

WCF

WCF

Microsoft WCFサービス

Oracle Enterprise Gateway (OEG)

OEG

OEG Webサービス・プロキシが前にあるWebサービス

注意:
Business Transaction Managementでの検出と監視が可能なサービスおよびコンポーネントのタイプの完全かつ最新のリストは、Business Transaction Management動作保証マトリックスを参照してください。このドキュメントは、http://support.oracle.comで「BTM動作保証」を検索すると参照できます。

単一のオブザーバ・インストールでは、適切なプローブが含まれているかぎり、アプリケーション・サーバーで実行中の任意の数のコンポーネントを監視できます。

オブザーバは、モニターと呼ばれる別のBusiness Transaction Managementコンポーネント経由でBusiness Transaction Managementスフィアと通信します。モニターのジョブの1つは、構成をいくつかのオブザーバに配布することです。オブザーバは起動すると、モニターと通信し、構成を取得します。オブザーバは、構成の更新がないか定期的にモニターをポーリングします。

オブザーバ構成は、オブザーバ通信ポリシーから生成されます。デフォルトでは、事前構成済オブザーバ通信ポリシーがすべてのモニターに適用されます(このデフォルト・ポリシーの名前は「オブザーバ通信ポリシー - デフォルト」です)。このポリシーは、ポリシーの適用先のモニターを構成する他、それらのモニターにオブザーバ構成を提供します。オブザーバ構成は、デフォルトでは関連するすべてのオブザーバに分散されます。このデフォルト・ポリシーを編集したり、独自のポリシーを適用することができます。

オブザーバは実行されると、スループット、フォルト・カウント、レスポンス時間などビジネス・アプリケーションのメッセージやコール・フローの様々な側面を測定します(測定の完全なリストは、第6章「インスツルメントについて」を参照してください)。オブザーバは、次の図に示すように、分析およびデータベースへの最終的な保管のためにこれらの測定をモニターに定期的に送信します。

図12-1 プローブを表示するデプロイ済オブザーバの例

このように構成された場合、オブザーバはメッセージ・ロギングおよびさらなる分析という目的で様々なタイプのメッセージおよびコールを標準化されたXML形式のメッセージに変換します。オブザーバは、これらのメッセージをモニターに転送します。これらのメッセージはコピーであり、元のメッセージ/コールは変更されることもリダイレクトされることもありません。

オブザーバはビジネス・コンポーネントのアプリケーション・サーバーにインストールされ、クライアントはオブザーバがインストールされる前と同じように引き続きビジネス・コンポーネントにアクセスします。任意の数のモニター、およびモニターごとに任意の数の関連付けられたオブザーバをインストールできますが、Business Transaction Managementセントラル・サーバーまたはモニターをホストするアプリケーション・サーバーにオブザーバがインストールされることはありません。

Business Transaction Managementシステム全体の概要は、1.3項「アーキテクチャの概要」を参照してください。モニターのレプリケートによる監視システムのスケール・アップについては、『Business Transaction Managementインストレーション・ガイド』を参照してください。

12.1.2 オブザーバおよびモニターの構成

オブザーバ通信ポリシーにより、オブザーバと1つのモニターまたはモニター・グループ間の通信が設定されます。デフォルトでは、このポリシーは次のようにモニターとオブザーバの両方を構成します。

- オブザーバとモニター間の通信チャネルを設定します。

- オブザーバのランタイム設定を構成します。

リリース12.1.0.4より前では、任意の1つのモニターに単一のオブザーバ通信ポリシーのみを適用できました。つまり、同じモニターに関連付けられたすべてのオブザーバは同じ構成を受信していました。オブザーバ構成の柔軟性を高めるため、リリース12.1.0.4では単一のモニターに複数のオブザーバ通信ポリシーを適用し、これらの各ポリシーをそれぞれ異なるオブザーバまたはオブザーバ・セットでターゲットにすることができるようになりました。このようなシナリオでは、1つのポリシーのみをモニターの構成に使用するポリシーとして指定し、残りのすべてのポリシーをオブザーバの構成にのみ使用するポリシーとして指定します。モニターを構成するポリシーは、必要に応じてオブザーバの構成にも使用できます。このトピックの詳細は、12.1.2.7項「オブザーバのターゲット」を参照してください。

デフォルトでは、事前構成済のオブザーバ通信ポリシーが、システムに登録されたすべてのモニターに適用されます。このデフォルト・ポリシーは、すべての関連付けられたオブザーバをターゲットにするように事前構成されています。必要に応じて、このデフォルト・ポリシーを編集したり、新しいポリシーを作成することができます。

デフォルトのオブザーバ通信ポリシー・インスタンスを編集するには:

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

2. サマリー領域の「オブザーバ通信ポリシー - デフォルト」(以前のリリースではこのポリシーの名前は「デフォルト・オブザーバ通信ポリシー」)を選択します。

3. 「変更」→「定義の編集: オブザーバ通信ポリシー - デフォルト」を選択します。

オブザーバ通信ポリシーの新しいインスタンスを作成するには:

「管理」→「システム・ポリシーの作成」→「オブザーバ通信」を選択します。

12.1.2.1 一般的なタスク

次に、このポリシーを使用して実行できる一般的な構成タスクを示します。

- プローブのアクティブ化および非アクティブ化

- プローブの追加

- オブザーバとモニター間の通信チャネルの設定

- 監視メッセージ・フローでのSSLの構成

- オブザーバ認証の構成

- オブザーバのターゲット

- Real User Experience Insightからのドリルダウンの有効化/無効化

- WEB_APPプローブ用のリクエストの監視および操作のモデル化

- 12.1.2.11項の「詳細設定フィールドのリファレンス」の表では、次のタスクおよびその他の詳細タスクに関連する情報を確認できます。

- 監視対象メッセージおよびオブザーバ・エラーのロギング(「オブザーバのトラブルシューティング」のエントリを参照)

- オブザーバでのメッセージ・サイズおよびキュー動作の調整(「オブザーバ・メッセージ」のエントリを参照)

- モニターでのメッセージ・サイズおよびキュー動作の調整(「モニターのメッセージ・キュー」のエントリを参照)

- SOA、OSB、JMSおよびローカルEJBコンポーネントをモデル化する方法の制御(「モデル構成」のエントリを参照)

- 関連するJDBCコールの監視を集約して単一の監視メッセージとしてモニターに送信するJDBCサマリー・モードの有効化(「JDBCサマリー」のエントリを参照)

12.1.2.2 プローブのアクティブ化および非アクティブ化

オブザーバには、ビジネス・アプリケーションを構成する様々なタイプのコンポーネントを監視するための多様なプローブが含まれています。このポリシーを使用して、システムにインストールされているプローブを個別にアクティブ化または非アクティブ化できます(任意の特定のプローブは、システムにインストールされているオブザーバ内に含まれている場合、インストール済とみなされます)。デフォルトでは、JAVAおよびRMIを除いて、新規に作成したポリシー内のすべてのプローブがアクティブ化されます。

注意:
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 Suiteプローブはグループとして非アクティブ化(またはアクティブ化)する必要があります(SOA Suiteプローブは、SOA_ADAPTER、SOA_B2B、SOA_BIZRULE、SOA_BPEL、SOA_BPMN、SOA_CALLBACK、SOA_EDN、SOA_JCA、SOA_MEDIATOR、SOA_REST、SOA_SPRING、SOA_WSおよびSOA_WSAです)。

ポリシーの「アクティブ・プローブ」セクションには、プローブのタイプごとに「検出の有効化」チェック・ボックスおよび「検出時に監視」チェック・ボックスがあります。

「検出の有効化」チェック・ボックスは、関連付けられたコンポーネント・タイプの検出メカニズムをアクティブ化する場合に選択します。そのタイプのコンポーネントは、次回メッセージまたはコールを受信したときに検出されて管理コンソールに表示されます。

コンポーネント・タイプの「検出時に監視」チェック・ボックスは、そのタイプのコンポーネントの監視を検出時にただちに開始する場合に選択します。

注意:
検出を有効にするものの監視は実施せず、後でポリシーを編集し監視を有効にする場合、以前に検出されたコンポーネントの監視は開始されません。監視を有効にした後で検出されたコンポーネントのみの監視が開始されます。以前に検出されたコンポーネントの監視の有効化については、12.8.4項「エンドポイントの監視の開始および停止」を参照してください。

12.1.2.3 プローブの追加

Business Transaction Managementのアップグレード後、監視用に新しいタイプのプローブが使用可能になる場合があります。ただし、アップグレード処理により、このような新しいプローブは既存のオブザーバ通信ポリシーに自動的には追加されません。既存のポリシーで新しいプローブを使用するには、次のように手動でポリシーに追加する必要があります。

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

2. サマリー領域でポリシーを選択します。

3. 「変更」→「定義の編集: My_Policy」を選択します。My_Policyはポリシーの名前です。

4. 「アクティブ・プローブ」セクションの最下部にスクロールし、「プローブを追加」をクリックします。
これでカーソルが空のテキスト・フィールドに挿入されます。

5. カーソルがすでに空のテキスト・フィールドに挿入された状態で、テキスト・フィールド内をクリックします。
すべてのプローブ・タイプの名前が含まれているドロップ・リストが開きます。

6. 追加するプローブ・タイプを選択します。

7. 必要に応じて「検出の有効化」チェック・ボックスおよび「検出時に監視」チェック・ボックスの設定を編集します(これらのフィールドについては、12.1.2.2項「プローブのアクティブ化および非アクティブ化」を参照してください)。

8. 「適用」をクリックします。

12.1.2.4 オブザーバとモニター間の通信チャネルの設定

デフォルトのオブザーバ通信ポリシーは、オブザーバとモニター間の直接通信を設定します。直接通信により、複数のシングルトン・モニターを使用して、各モニターで複数のオブザーバから監視を収集できます。

オブザーバとレプリケート対象モニターのグループとの間にロード・バランサを配置してモニターをレプリケートする場合は、次に示すように、「通信チャネル」セクションの次の各フィールドの値を設定する必要があります。

フィールド名

値

通信パス

オブザーバがロード・バランサを介してモニター・グループと通信する場合は、「ルーターからモニター・グループへ」を選択します。この選択により、ポリシーの次の各フィールドが表示されます。

ルーターのIPアドレス

監視メッセージを受信するロード・バランサのIPアドレスを指定します。

ルーターのポート番号

ロード・バランサが監視メッセージを受信するポート番号を指定します。
注意: また、ルーターにこのポートを構成する必要があります。

モニターのポート番号

転送された監視メッセージをモニターが受信するポート番号を指定します。

このトピックの詳細は、『Business Transaction Managementインストレーション・ガイド』を参照してください。

12.1.2.5 監視メッセージ・フローでのSSLの構成

デフォルトのオブザーバ通信ポリシーは、オブザーバからモニターへの監視メッセージの送信に使用されるセキュア・ソケット接続を設定します。この接続に非セキュア・ソケットを使用する場合は、ポリシーの「SSLの有効化」チェック・ボックスを無効にします。

SSLが有効である場合、モニターはオブザーバに対して自己認証する必要があります。デフォルトでは、SSL接続は組込みの事前構成済セキュリティ・ストアを使用します。独自のセキュリティ・ストアを使用する場合は、「デフォルト・ストアの使用」チェック・ボックスを無効にし、次の表の情報を使用して追加フィールドに値を入力します。

注意:
.NETベースのオブザーバを使用中の場合、SSL接続を使用するにはオブザーバをホストするマシンに証明書をデプロイする必要があります。デフォルト・ストアを使用中の場合は、オブザーバ・インストール・ディレクトリのnanoagent\config\ssl\server.cerにある事前構成済証明書を使用します。事前構成済証明書のデプロイの詳細は、『Business Transaction Managementインストレーション・ガイド』を参照してください。

フィールド名(太字はセクション名)

説明

プロトコル

表示されている場合は必須です。SSLプロトコルを選択します。選択肢は「TLSv1」、「SSLv3」または「いずれか」です。SSLv3は、.NETオブザーバではサポートされていません。このフィールドは、モニターとオブザーバの両方を構成します。

デフォルト・ストアの使用

このチェック・ボックスはデフォルトで有効になっています。
組込みの事前構成済セキュリティ・ストアを使用する場合は、このチェック・ボックスを有効のままにしてください。この場合、Javaベースのオブザーバのみを使用している場合は作業完了です。.NETベースのオブザーバを使用している場合は、そのオブザーバをホストするマシンに事前構成済証明書をデプロイする必要があります。事前構成済証明書は、オブザーバ・インストール・ディレクトリのnanoagent\config\ssl\server.cerで確認できます。事前構成済証明書のデプロイの詳細は、『Business Transaction Managementインストレーション・ガイド』を参照してください。

このチェック・ボックスを無効にすると、追加フィールドが表示され、独自のセキュリティ・ストアを指定できます。

モニター

---------- これはセクション・ラベルです ---------
次の5つのフィールドは、モニターのキー・ストアに関連しています。次のすべてのフィールドは、「デフォルト・ストアの使用」チェック・ボックスが無効になっている場合にのみ表示されます。

キー・ストアの場所

表示されている場合は必須です。モニターのSSLキー・ストアの場所を指定します。この場所は、キー・ストア・ファイルがモニターに対してローカルである場合には絶対パスとして指定でき、ファイルがHTTP GETでアクセス可能である場合にはHTTP(S) URLとして指定できます。
新しいポリシーを開いたときの初期値はAP-MONITOR-SSL:DefaultKeyStore.ksです。この値は、btmmonitor.warデプロイメントのWEB-INF/ssl/DefaultKeyStore.ksにある組込みの事前構成済キー・ストアを指します。

キー・ストア・パスワード

表示されている場合は必須です。SSLキー・ストアにアクセスするためのパスワードを指定します。

キー・ストア・タイプ

表示されている場合は必須です。使用するモニターのJCE (Java Cryptographic Extensions)キー・ストアのタイプを指定します。たとえば、JKS、JCEKS、PKCS12です。初期値はJKSです。

キー名

表示されている場合は必須です。証明書および秘密鍵を指定します。CN=valueやUID=valueなどの形式で鍵の別名または証明書属性を入力できます。

キー・パスワード

表示されている場合は必須です。証明書および秘密鍵にアクセスするためのパスワードを指定します。指定しない場合は、キー・ストアのパスワードが使用されます。

トラスト・ストアをJavaオブザーバへ自動ディスパッチ

このチェック・ボックスが有効である場合、モニターはトラスト・ストアをシリアライズしてすべての関連付けられたJavaオブザーバに自動的に送信します。このオプションは.NETオブザーバでは無視されます。このチェック・ボックスはデフォルトでは無効になっています。

自動ディスパッチJavaトラスト・ストア

---------- これはセクション・ラベルです ---------
次の3つのフィールドは自動ディスパッチ・トラスト・ストアに関連しており、「トラスト・ストアをJavaオブザーバへ自動ディスパッチ」チェック・ボックスが有効である場合にのみ表示されます。

トラスト・ストアの場所

表示されている場合は必須です。
モニターがJavaオブザーバにディスパッチするSSLトラスト・ストアの場所を指定します。この場所は、トラスト・ストア・ファイルがモニターに対してローカルである場合には絶対パスとして指定でき、ファイルがHTTP GETでアクセス可能である場合にはHTTP(S) URLとして指定できます。

新しいポリシーを開いたときの初期値はAP-MONITOR-SSL:DefaultTrustStore.ksです。この値は、btmmonitor.warデプロイメントのWEB-INF/ssl/DefaultTrustStore.ksにある組込みの事前構成済トラスト・ストアを指します。

トラスト・ストア・パスワード

表示されている場合は必須です。モニターがJavaオブザーバにディスパッチするSSLトラスト・ストアにアクセスするためのパスワードを指定します。

トラスト・ストア・タイプ

表示されている場合は必須です。モニターがJavaオブザーバにディスパッチするJCE (Java Cryptographic Extensions)トラスト・ストアのタイプを指定します。たとえば、JKS、JCEKS、PKCS12です。初期値はJKSです。

Javaオブザーバ

---------- これはセクション・ラベルです ---------
次の3つのフィールドは、手動でインストールしたトラスト・ストアに関連しており、「トラスト・ストアをJavaオブザーバへ自動ディスパッチ」チェック・ボックスが無効である場合にのみ表示されます。

トラスト・ストアの場所

表示されている場合は必須です。
Java実行環境にデプロイされたオブザーバによって使用されるSSLトラスト・ストアの場所を指定します。この場所は、トラスト・ストア・ファイルがオブザーバに対してローカルである場合には絶対パスとして指定でき、ファイルがHTTP GETでアクセス可能である場合にはHTTP(S) URLとして指定できます。

新しいポリシーを開いたときの初期値はAP-OBSERVER-SSL:DefaultTrustStore.ksです。この値は、オブザーバ・インストール・ディレクトリのnanoagent\config\ssl\DefaultTrustStore.ksにある組込みの事前構成済トラスト・ストアを指します。

トラスト・ストア・パスワード

表示されている場合は必須です。SSLトラスト・ストアにアクセスするためのパスワードを指定します。

トラスト・ストア・タイプ

表示されている場合は必須です。モニターがJavaオブザーバにディスパッチするJCE (Java Cryptographic Extensions)トラスト・ストアのタイプを指定します。たとえば、JKS、JCEKS、PKCS12です。初期値はJKSです。

12.1.2.6 オブザーバ認証の構成

デフォルトのオブザーバ通信ポリシーにより、オブザーバは接続を確立するたびにモニターに対して自己認証する必要があります。この設定は、「オブザーバ認証」フィールドを介して調整できます。このフィールドを「なし」に設定すると、オブザーバ認証をオフにできます。

また、このフィールドを「メッセージ認証の使用」に設定して、メッセージをモニターに送信するたびにオブザーバに自己認証を求めることもできます。ただし、メッセージ認証の使用により、パフォーマンスが大幅に低下する場合があります。この設定は必要な場合にのみ使用してください。たとえば、ロード・バランサが(接続単位ではなく)メッセージ単位のバランシング用に構成されているモニター・グループにオブザーバがメッセージを送信する場合は接続認証を使用できません。この場合、このフィールドを「なし」または「メッセージ認証の使用」に設定する必要があります。

注意:
「オブザーバ認証」フィールドは、「SSLの有効化」フィールドが有効である場合にのみ表示されます。「SSLの有効化」フィールドを無効にすると、SSL接続だけでなくオブザーバ認証も無効になります。

12.1.2.7 オブザーバのターゲット

リリース12.1.0.4が備える新機能により、オブザーバをさらに柔軟に構成できます。以前のリリースでは、任意の1つのモニターに単一のオブザーバ通信ポリシーのみを適用できました。モニターはこのポリシーから単一のオブザーバ構成を生成して、関連付けられたすべてのオブザーバに配布しました(オブザーバにモニターの場所を提供して、インストール時にオブザーバをモニターに関連付けます)。

リリース12.1.0.4から、単一のモニターに複数のオブザーバ通信ポリシーを適用し、これらの各ポリシーをそれぞれ異なるオブザーバまたはオブザーバ・セットでターゲットにすることができます(ターゲットにするオブザーバはモニターに関連付ける必要があります)。次に、オブザーバをターゲットにする手順を説明します。

注意:
これらの手順の順序は、オブザーバのターゲットにかかわる概念の理解を助けることを目的としています。ただし、タスクを実際に実行するときは、1つのポリシーですべての手順を完了してから次のポリシーに移ることが最も効率的です。

1. 「オブザーバのみ対象の構成の生成」チェック・ボックスを無効にしたままにして、モニターの構成を生成するためのソースとして1つのポリシーを指定します(このポリシーをモニター・ポリシーと呼びます)。
モニター・ポリシーにより、モニター構成と1つのオブザーバ構成が生成されます。

2. オブザーバを構成するために必要な数の追加ポリシーをモニターに適用します(これらのポリシーをオブザーバ・ポリシーと呼びます)。

1. 「オブザーバのみ対象の構成の生成」チェック・ボックスを有効にして、オブザーバ構成のみを生成するためのソースとして各オブザーバ・ポリシーを指定します。

2. 各オブザーバ・ポリシーの「通信チャネル」セクションにある他のすべてのフィールドの値がモニター・ポリシーの値に一致することを確認します。

3. 特定のオブザーバでオブザーバ・ポリシーをターゲットにします。

1. 「構成ラベル」フィールドや「オブザーバのベース・アドレス」フィールドを使用して、どのオブザーバをオブザーバ構成のターゲットにするかを指定します(これらのフィールドおよび関連するフィールドの詳細は、12.1.2.7.1項「オブザーバ構成ラベル」および12.1.2.7.5項「オブザーバのターゲットに関するフィールドのリファレンス」を参照してください)。

2. あるオブザーバ・ポリシーに指定されているラベルおよびアドレスが、同じモニターに適用されるそれ以外のポリシーに指定されていないことを確認します(詳細は、12.1.2.7.2項「オブザーバ通信ポリシーの拒否」を参照してください)。

3. オプション - ターゲットのすべてのオブザーバがBusiness Transaction Managementに認識されるようにするには、「アドレスの検証」チェック・ボックスを有効にします。
不明なオブザーバをターゲットにし、このフィールドを有効にした場合、ポリシーは拒否されます。現時点ではまだ不明であるものの後で判明するオブザーバをターゲットにする場合は、このフィールドを無効にしてください。

4. オプション - (ポリシーを複数のモニターに適用する場合は、このチェック・ボックスを有効にしないでください。)ターゲットのすべてのオブザーバがポリシーの適用先のモニターに関連付けられるようにするには、「モニターに施行」フィールドを有効にします。

4. オプション - あるポリシーをターゲットにしないままにすると、そのポリシーは適用先のモニターに関連付けられたすべてのオブザーバに対するデフォルトのオブザーバ構成として機能します。
ターゲットでないポリシーは、別のポリシーによって特にターゲットにされていないオブザーバのデフォルトの構成として機能します。たとえば、モニター・ポリシーをターゲットにしないままにして、デフォルトのオブザーバ構成として使用できます。2つ目のターゲットでないポリシーを作成しようとすると、その2つ目のポリシーは拒否されます(ポリシーの拒否については、12.1.2.7.2項「オブザーバ通信ポリシーの拒否」を参照してください)。

注意:
様々なポリシーを使用して様々なモニター(またはモニターのグループ)を構成する場合は、それぞれに異なるデフォルトのオブザーバ構成を定義できます。

以前のリリースと同じく、必要に応じて単一のポリシーを使用して複数のモニターおよび関連するすべてのオブザーバを構成できます(つまり、特定のオブザーバをターゲットにする必要はありません)。このようなシナリオでは、特定のオブザーバのターゲットではないモニター・ポリシーを使用します。このポリシーは、デフォルトのオブザーバ・ポリシーを生成します。また、特定のオブザーバがターゲットではないため、モニターに関連付けられたすべてのオブザーバがこのデフォルト構成を受信します。

12.1.2.7.1 オブザーバ構成ラベル

オブザーバ構成ラベルは、オブザーバ・セットを概念的に識別する簡単なテキスト文字列です(たとえば、CONFIG_LABEL_MY_OBSERVERS)。オブザーバがデプロイされているアプリケーション・サーバーのラベルまたは絶対アドレス(たとえば、http://my_host.com:7011)を指定して、オブザーバをターゲットにします。単一のポリシーで任意の数のラベルやアドレスを指定し、任意の数のオブザーバをターゲットにできます。

ラベルを使用すると、構成目的で物理的ではなく論理的にオブザーバをグループ化できます。ラベルの適用は、順不同で実行できる2つのステップからなる手順です。

- オブザーバをホストするアプリケーション・サーバーで、ap.nano.config.labelという名前でシステム・プロパティを作成し、その値をラベル文字列に設定します(その方法の詳細は、『Business Transaction Managementインストレーション・ガイド』を参照してください)。

- オブザーバの構成に使用するオブザーバ通信ポリシーの「構成ラベル」フィールドをap.nano.config.labelと同じ値に設定します。

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

オブザーバのターゲットに関連して、誤ってオブザーバ通信ポリシーが拒否される可能性が多々あります。次のいずれのシナリオでも、ポリシーが拒否されます。

- ターゲットでない複数のポリシー(デフォルトのオブザーバ構成)を同じモニターに適用しようとしました。

- 同じモニターに適用される2つの異なるポリシーに同じオブザーバ構成ラベルを指定しようとしました。

- 同じモニターに適用される2つの異なるポリシーに同じオブザーバ・ベース・アドレスを指定しようとしました。

ラベルは、ポリシーが適用されるモニターにスコープされます。つまり、複数のポリシーがそれぞれ異なるモニターに適用される場合にはそれらのポリシーに特定のラベル名を再利用できますが、同じモニターに適用される複数のポリシーにラベル名を再利用することはできません。このスコープの原則は、ターゲットでないポリシーにも関連しています。

ポリシーが拒否された場合は、コンソールの作業領域でポリシーを選択し、「ターゲット」タブを表示します。このタブには、拒否されたポリシーの原因に関する情報が記載されています。

12.1.2.7.3 優先順位

オブザーバがどの構成を受信するかを決定する優先順位は次のとおりです。

1. オブザーバのベース・アドレス
ポリシーにオブザーバのベース・アドレスが指定されている場合、オブザーバはそのポリシーによって生成された構成を受信します。

2. オブザーバ構成ラベル
あるポリシーにオブザーバの構成ラベルが指定され、どのポリシーにもベース・アドレスが指定されていない場合、オブザーバは構成ラベルが指定されているポリシーによって生成された構成を受信します。

3. ターゲットでないポリシー
ターゲットでないポリシーが存在し、どのポリシーにもオブザーバのベース・アドレスや構成ラベルが指定されていない場合、オブザーバはターゲットでないポリシーによって生成された構成を受信します。

12.1.2.7.4 事前構成済のオブザーバ通信ポリシー

Business Transaction Managementには、特定のタイプのアプリケーションを監視するために事前構成されたオブザーバ通信ポリシーが数多く用意されています。これらのポリシーはいずれも編集可能で、監視ニーズにあわせて調整できます。各ポリシーの名前は太字で表示されており、その後に説明が続きます。

- オブザーバ通信ポリシー - デフォルト
このポリシーは、モニター構成とターゲットでない(デフォルト)オブザーバ構成の両方を生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、別のポリシーによって特にターゲットにされていないすべての関連付けられたオブザーバに配布されます。

- オブザーバ通信ポリシー - Fusionアプリケーション
このポリシーは、オブザーバ構成のみを生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、ラベルCONFIG_LABEL_FAPPSでタグ付けされたオブザーバのターゲットになります。この構成は、Oracle Fusion Applicationsコンポーネントを監視するためにプローブをアクティブ化し、オブザーバのランタイム設定を調整します。

- オブザーバ通信ポリシー - JavaEE
このポリシーは、オブザーバ構成のみを生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、ラベルCONFIG_LABEL_JAVAEEでタグ付けされたオブザーバのターゲットになります。この構成は、JavaEEコンポーネントを監視するためにプローブをアクティブ化し、オブザーバのランタイム設定を調整します。

- オブザーバ通信ポリシー - OSB
このポリシーは、オブザーバ構成のみを生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、ラベルCONFIG_LABEL_OSBでタグ付けされたオブザーバのターゲットになります。この構成は、Oracle Service Busコンポーネントを監視するためにプローブをアクティブ化し、オブザーバのランタイム設定を調整します。

- オブザーバ通信ポリシー - SOA
このポリシーは、オブザーバ構成のみを生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、ラベルCONFIG_LABEL_SOAでタグ付けされたオブザーバのターゲットになります。この構成は、Oracle SOAコンポーネントを監視するためにプローブをアクティブ化し、オブザーバのランタイム設定を調整します。

12.1.2.7.5 オブザーバのターゲットに関するフィールドのリファレンス

フィールド名(太字はセクション名)

説明

オブザーバのみ対象の構成の生成

このポリシーでモニターとオブザーバ構成の両方を生成する場合は、このチェック・ボックスを無効のままにします。このようなポリシーを1つのみ任意のモニターに適用できます。モニターに追加ポリシーを適用した場合は、そのいずれのポリシーでもこのチェック・ボックスを有効にする必要があります。このチェック・ボックスが有効であると、ポリシーはオブザーバ構成のみを生成します。このチェック・ボックスが有効である場合でも、ポリシーの「通信チャネル」セクションの他のすべてのフィールドに値を指定する必要があり、その値は同じモニターに適用される他のすべてのポリシーに一致する必要があります。

対象のオブザーバ

---------- これはセクション・ラベルです ---------
このセクションでは、どのオブザーバがこのポリシーによって生成されたオブザーバ構成を受信するかを指定します。

対象の指定オブザーバ

このポリシーによって生成されたオブザーバ構成で特定のオブザーバのみを構成する場合は、このチェック・ボックスを有効にします。このチェック・ボックスを有効にすると、どのオブザーバが構成を受信するかを指定できる追加フィールドが表示されます。これらの追加フィールドでは、アドレスやラベルを利用してオブザーバをターゲットにできます。
このチェック・ボックスを無効のままにした場合、ポリシーはターゲットにならず、ポリシーが適用されるモニターに関連付けられたすべてのオブザーバのデフォルト構成を生成します。関連付けられたオブザーバは、ポリシーによるターゲットでない場合、このデフォルト構成を受信します。ターゲットでないポリシーを1つのみ任意のモニターに適用できます。2つ目のターゲットでないポリシーをモニターに適用しようとすると、ポリシーは拒否されます。

注意: 2種類のメカニズム(アドレスおよびラベル)を利用して、オブザーバをターゲットにできます。ただし、同じメカニズムを利用して特定のオブザーバをターゲットにできるのは1つのポリシーのみです。たとえば、ポリシーAがラベルでオブザーバをターゲットにしている場合、ポリシーBがラベルでその同じオブザーバをターゲットにすることはできません。この場合、ポリシーBは拒否されます。ただし、ポリシーBはアドレスでオブザーバをターゲットにできます。この場合、ラベルよりアドレスが優先されるため、オブザーバはポリシーBから構成を受信します。

構成ラベル

オプション - オブザーバ構成ラベルのカンマ区切りリストを指定します。指定されたいずれかのラベルがタグ付けされているオブザーバは、このポリシーによって生成された構成を受信します(ただし、別のポリシーがアドレスでオブザーバをターゲットにしている場合を除きます)。このフィールドは、テキスト入力を受け付け、大/小文字を区別しません。
注意: オブザーバをホストするアプリケーション・サーバーにあるap.nano.config.labelという名前のシステム・プロパティを介してオブザーバをタグ付けします。

既知のアドレス

---------- これはセクション・ラベルです ---------
オプション - このセクションでは、Business Transaction Managementで認識されているアドレスのドロップダウン・リストからオブザーバ・アドレスを選択します。指定されたオブザーバは、このポリシーによって生成された構成を受信します。

オブザーバのベース・アドレス

このドロップダウン・リストでは、オブザーバがデプロイされているコンテナのアドレスを選択します。

[オブザーバ・アドレスの追加]

このリンクをクリックして「オブザーバのベース・アドレス」ドロップダウン・リストを追加します。

任意のアドレス

---------- これはセクション・ラベルです ---------
オプション - このセクションでは、テキスト・フィールドにオブザーバ・アドレスを手動で入力します。指定されたオブザーバは、このポリシーによって生成された構成を受信します。

オブザーバのベース・アドレス

このフィールドでは、オブザーバがデプロイされているアプリケーション・サーバーのアドレス(たとえば、http://my_host.com:7011)を手動で入力します。

[オブザーバ・アドレスの追加]

このリンクをクリックして、「オブザーバのベース・アドレス」テキスト・フィールドを追加します。

アドレスの検証

ポリシーによってターゲットにされるすべてのオブザーバがBusiness Transaction Managementに認識されるようにするには、このチェック・ボックスを有効にします。不明なオブザーバをターゲットにし、このフィールドを有効にした場合、ポリシーは拒否されます。
現時点ではまだ不明であるものの後で判明するオブザーバをターゲットにする場合は、このフィールドを無効にしてください。

モニターに施行

ターゲットのすべてのオブザーバがポリシーの適用先のモニターに関連付けられるようにするには、このチェック・ボックスを有効にします。
ポリシーを複数のモニターに適用する場合は、このチェック・ボックスを有効にしないでください。

12.1.2.8 Real User Experience Insightからのドリルダウンの有効化/無効化

ユーザーがOracle Enterprise Manager Real User Experience InsightからBusiness Transaction Managementへのユーザー・インタフェース・ドリルダウンを実行できるかどうかを制御できます。デフォルトでは、ドリルダウン機能は有効になっています。ドリルダウン機能を無効または再度有効にするには、12.1.2.9項の説明に従ってWEB_APPプローブのrueiPresent属性を設定します。

12.1.2.9 WEB_APPプローブ用のリクエストの監視および操作のモデル化

WEB_APPプローブを使用すると、Javaサーブレットとして実装されているWebアプリケーションを監視できます。このプローブは、あらゆるタイプのJavaサーブレットで使用できる汎用形式の処理と、Oracle Application Development Framework (ADF)アプリケーションでの使用に最適化された特別な形式の処理を備えています。この項では、これらの多様な処理をルールセットと呼びます。汎用タイプの処理はURLルールセットと呼び、ADFアプリケーションに使用されるタイプの処理はADFルールセットと呼びます。プローブは、デフォルトではURLルールセットに設定されます。

別途構成されている場合を除き、WEB_APPプローブは監視対象アプリケーション・サーバーのWebアプリケーションに対するすべてのリクエストを監視します。ただし、多くの場合、すべてのリクエストを監視することはお薦めしません。たとえば、イメージ・ファイルやHTMLファイルなど静的リソースに対するリクエストは監視しないことをお薦めします。そのため、デフォルトのオブザーバ通信ポリシーはjpg、jpeg、html、htm、css、gif、png、ico、js、swf、curのファイル拡張子を持つリソースに対するリクエストを監視しないように構成されています。このように選択的に監視することは、デフォルト・ポリシーの「WEB_APPプローブ構成」フィールドに表示されるXML構成コードのスニペットによって指定されています。

このデフォルトのXML構成コードを編集して、監視対象のリクエストのタイプを制御できます。また、XML要素を追加して管理コンソールでの表示用にアプリケーションの操作名をどのように短縮するかも制御できます(操作名はリクエストURLから導出されます)。次の表に、構成コードで使用可能なXML要素および属性を示します。表の後に使用例を示します。

注意:
XML要素の順序は重要です。要素に必須の順序については表で説明します。順序を誤ると、ポリシーは拒否されます。

要素

属性

説明

サポートされるルールセット

servletObserver

-

WEB_APPプローブによって監視されるすべてのアプリケーションの構成情報が含まれている、タグで囲まれた要素。<servletObserver>要素は1つのみ存在します。

ADF URL

-

rueiPresent

Oracle Enterprise Manager Real User Experience Insightが監視対象アプリケーションの前にインストールされていることを示します。この属性は、ユーザーがReal User Experience InsightからBusiness Transaction Managementへのユーザー・インタフェース・ドリルダウンを実行できるかどうかを制御します。
有効な値: trueまたはfalse。デフォルト設定はtrueです。

この属性がtrueに設定されている場合、Business Transaction ManagementはHttpResponseにヘッダーを追加してドリルダウン機能を有効にします。ドリルダウン機能を無効にするには、この属性をfalseに設定します。

ADF URL

-

rueiMatches

Real User Experience Insightネーミング・スキームがBusiness Transaction Managementネーミング・スキームに一致することを示します。有効な値: trueまたはfalse。

ADF URL

globalExcludeList

-

この要素では、指定したURLを監視からグローバルに除外します。ファイル・タイプ、コンテキスト・ルート、パターン一致または長さで除外するURLを指定できます。
要素順序: 使用した場合、この要素は<servletObserver>要素の最初の子として配置する必要があります。<servletObserver>ごとに1つのみ存在できます。

ADF URL

-

ext

ext="html, htm, jpg, css"というように、ファイル拡張子のカンマ区切りリストが含まれています。指定したタイプのファイルは、監視から除外されます。

ADF URL

-

contextRoot

contextRoot="console, medrec, bookmart"というように、コンテキスト・ルートのカンマ区切りリストが含まれています。指定したコンテキスト・ルートのいずれかが含まれているURLは、監視から除外されます。
空白のコンテキスト・ルートを指定するには、/を使用します。たとえば、contextRoot="console, /, bookmart"とします。

ADF URL

-

pathPattern

URLパターンのカンマ区切りリストが含まれています。指定したパターンのいずれかに一致するURLは、監視から除外されます。ワイルドカードが許可されており、*を使用して表します。
パターン一致に関する注意(pathPattern属性とpattern属性の両方に当てはまります):

- プロトコル、ホスト名、ポート番号または問合せ文字列に対してはパターン一致は実行されません。パターン一致は、URLのうちコンテキスト・ルートの前にある/で始まり(/自体を含みます)、-で終わる(-自体は含みません)セクションに対してのみ実行されます。また、パターンはその文字列全体に一致する必要があります。たとえば、URLがhttp://myhost:7654/my_context/test - param1=value1の場合、パターン一致は文字列/my_context/testに対して実行されます。このURLに一致するパターンには、*context*、/my*、*testなどがあります。

- パターン一致はデコードされたURLに対して実行されるため、パターンはデコードされたURLに一致する必要があります。たとえば、URL文字列/your%20context/testはデコードすると/your context/testになります(%20はスペースに変換されます)。このURLに一致するためには、パターンは%20ではなくスペースに一致する必要があります。

ADF URL

-

pathLength

正の整数。この文字数を超えるURLは、監視から除外されます。
プロトコル、ホスト名、ポート番号および問合せ文字列の文字はカウントに含まれません。この属性が作用するURLのセクションは、pathPattern属性と同じです。

ADF URL

application

-

監視するアプリケーションを示します。
要素順序: この要素は<servletObserver>要素の子です。<globalExcludeList>要素または<globalAdfOptions>要素に先行しないようにしてください。<servletObserver>要素ごとに任意の数だけ存在可能です。

ADF URL

-

contextRoot

監視対象アプリケーションのコンテキスト・ルート。この属性の値はサービス名として使用されます。空白のコンテキスト・ルートを指定するには、/を使用します。たとえば、contextRoot="/"とします。

ADF URL

framework

-

この要素は、<include>子要素を使用してどのURLをどのルールセットで処理するかを指定する場合に使用します。
要素順序: 使用した場合、この要素は<application>要素の最初の子として配置する必要があります。<application>要素のルールセット・タイプごとに1つ存在可能です。

ADF URL

-

type

<include> URLパターンを処理するルールセットを指定します。有効な値はADFおよびURLです。ADF Webアプリケーションの場合、この属性をADFに設定します。その他のWebアプリケーションの場合、この属性をURLに設定します。各ルールセットによって処理されるリクエストは相互排他的です。
<framework>タグが指定されている場合、プローブはデフォルトでURLルールセットに設定されます。<framework>タグが指定されている場合、デフォルト値はありません。

ADF URL

include

-

この要素を使用すると、リクエストをルールセットにマップするときに、指定したワイルドカード式に一致するものを除いてすべてのリクエストを除外できます。
この要素を使用して、以前に除外したURLを含めることはできません。たとえば、<globalExcludeList>を使用してpng拡張子を除外した場合、<include>要素に*.pngを指定してその除外をオーバーライドすることはできません。

要素順序: この要素は<framework>要素の子です。<framework>要素ごとに多数存在可能です。

ADF URL

-

pattern

一致させるURLパターン。ワイルドカードが許可されており、*を使用して表します。
この属性は、pathPattern属性と同じパターン一致ルールに従います。これらのルールについては、<globalExcludeList>要素のpathPattern属性を参照してください。

ADF URL

excludeList

-

この要素では、監視から除外する、特定のアプリケーション内のファイル・タイプを指定します。この要素は、特定のアプリケーションの<globalExcludeList>要素をオーバーライドします。
要素順序: この要素は<application>要素の子です。どの<framework>要素にも先行せず、すべての<adfOptions>要素および<operationRule>要素に先行する必要があります。<application>要素ごとに1つのみ存在可能です。

ADF URL

-

ext

html, htm, jpg, cssというように、ファイル拡張子のカンマ区切りリストが含まれています。指定したタイプのファイル(親アプリケーション内)は、監視から除外されます。
アプリケーション内のすべてのファイル・タイプを監視する場合に、<globalExcludeList>要素のext属性が設定されているときは、このext属性をヌル文字列に設定します(たとえば、ext="")。

ADF URL

adfOptions

-

この要素では、ADF UIリクエスト・パラメータoracle.adf.view.rich.monitoring.UserActivityInfoに含まれているプロパティ値を操作名に追加して、特定のアプリケーション内の操作をパーティション化します。この機能を使用するには、UserActivityInfoリクエスト・パラメータを有効にする必要があります(12.1.2.9.1項「UserActivityInfoリクエスト・パラメータの有効化」を参照)。この要素の属性は、UserActivityInfoリクエスト・パラメータのプロパティに対応しています。属性は、プロパティ値が操作名に追加されるかどうかを制御します。プロパティ値は、リクエスト・パラメータに存在する場合にのみ追加されます。
要素順序: この要素は<application>要素の子です。どの<framework>要素またはどの<excludeList>要素にも先行せず、すべての<operationRule>要素に先行する必要があります。<application>要素ごとに1つのみ存在可能です。

ADF URL

-

appendRegionViewId

__regionViewIdという書式を使用してregionViewIdプロパティの値を操作名に追加するには、この属性をtrueに設定します。デフォルト設定はfalseです。

ADF URL

operationRule

-

この要素には、URLのうち、値の一意の組合せが操作を構成する部分を指定します。この要素では、URLから導出される操作名を短縮します。
要素順序: この要素は<application>要素の子です。<framework>、<excludeList>、<adfOptions>のどの要素にも先行しないようにしてください。<application>要素ごとに1つのみ存在可能です。

ADF URL

-

excludeDirectories

操作名から除外するディレクトリ・レベルのカンマ区切りリストが含まれています。たとえば、/facesまたはセッションIDを除外できます。コンテキスト・ルートはディレクトリ・レベルとみなされないことに注意してください。また、excludeDirectoriesカウントは0ではなく1から始まります。

ADF URL

paramGroup

-

この要素では、複数のリクエスト・パラメータで操作をパーティション化します。<partitionByParam>要素をこの要素の子として追加して、リクエスト・パラメータを指定します。パーティション化は、指定したすべてのパラメータがリクエストに存在する場合にのみ発生します。パラメータ名および値は、次の書式で操作名に追加されます。

_name1_value1__name2_value2__name3_value3

名前と値の各ペア間にアンダースコア文字が2つあることに留意してください。この要素には、最大3つの<partitionByParam>要素を含めることができます。

注意: この要素を使用して既存のトランザクション定義に使用されている操作をパーティション化すると、そのトランザクションのセマンティクスが変更されます。たとえば、指定したパラメータが含まれているリクエストは元の操作に対するリクエストとしてカウントされないため、トランザクションに属するものとしてカウントされません。トランザクションの定義を適宜更新することが必要になる場合があります。

要素順序: 使用した場合、この要素は<operationRule>要素の最初の子として配置する必要があります。複数の<paramGroup>要素が存在可能です。この要素は、すべてのスタンドアロンの<partitionByParam>要素(つまり、<paramGroup>要素の子でないもの)に先行する必要があります。

ADF URL

partitionByParam

-

この要素は、指定されたリクエスト・パラメータの値に基づいて操作をパーティション化します。一意の各パラメータ値は、それぞれ独立した操作としてモデル化されます。パラメータは、URLパラメータまたはPOSTパラメータのいずれかにできます。
たとえば、actionという名前のパラメータを取るorderApplication.jspがあるとします。通常、orderApplication.jspへのリクエストはorderApplication.jspという名前の単一の操作へのリクエストとしてモデル化されます。ただし、<partitionByParam>を使用し、actionパラメータでパーティション化した場合、actionパラメータが含まれているorderApplication.jspへのすべてのリクエストがorderApplication.jsp_action_paramValueという名前の操作へのリクエストとしてモデル化されます。paramValueはactionパラメータの値です。また重要なのは、actionパラメータが含まれているリクエストは操作orderApplication.jspへのリクエストとしてカウントされないことです。(「例2 - 操作名へのパラメータ名/値のペアの追加」も参照してください。)

注意: この要素を使用して既存のトランザクション定義に使用されている操作をパーティション化すると、そのトランザクションのセマンティクスが変更されます。たとえば、指定したパラメータが含まれているリクエストは元の操作に対するリクエストとしてカウントされないため、トランザクションに属するものとしてカウントされません。トランザクションの定義を適宜更新することが必要になる場合があります。

要素順序: 使用した場合、この要素を次の2つの位置に配置できます。

- <paramGroup>要素の内側

- すべての<paramGroup>要素の後に続く、<operationRule>要素の内側

<operationRule>要素ごとに任意の数だけ存在可能です。<paramGroup>の前に単一の<partitionByParam>要素を使用する場合は、その<paramGroup>要素の内側に配置します。

注意: この要素では、ADFページ入力パラメータがサポートされません。

ADF URL

-

name

リクエストのパーティション化に使用されるパラメータの名前。特定のパラメータの各個別値は、それぞれの操作に対応しています。パラメータはname_valueとして操作名に追加されます(nameはパラメータの名前で、valueはその値です)。

ADF URL

secureParam

-

この要素は、操作名とBusiness Transaction Managementメッセージの両方で値が非表示になるか、またはいっさい格納されないURLパラメータまたはPOSTパラメータ(たとえば、パスワード)を表します。
要素順序: この要素は<operationRule>要素の子です。どの<paramGroup>要素または<partitionByParam>要素にも先行しないようにしてください。<operationRule>要素ごとに任意の数だけ存在可能です。

ADF URL

-

name

値が非表示になるか、またはいっさい格納されないパラメータの名前。

ADF URL

注意:

(1) サービスおよび操作名は、リクエストURLから導出されます。XML規格に準拠するために、プローブはスラッシュ、疑問符、等号(/、-、=)などの特殊文字をアンダースコア記号(_)に置き換えます。

(2) サービスおよび操作名は、255バイトを超える場合には短縮されます。この短縮は、名前を252バイトに切り捨ててから…を追加することによって行われます。

(3) pathLength属性の処理は、pathPattern属性の処理よりも前に行われます。サービスおよび操作名の短縮は、処理の最後に行われます。実行の完全な順序は次のとおりです。

1. <globalExcludeList>要素のpathLength属性

2. <globalExcludeList>要素のcontextRoot属性

3. <globalExcludeList>要素のpathPattern属性

4. <excludeList>要素のext属性(存在する場合)
そうでない場合:

<globalExcludeList>要素のext属性

5. <framework>要素内のinclude要素

6. サービスおよび操作名の短縮

例1 - 操作名の短縮

<ap:servletObserver xmlns:ap="http://namespace.amberpoint.com/amf">
<ap:application contextRoot="/mywebshop">
<ap:operationRule excludeDirectories="1, 2" />
</ap:application>
</ap:servletObserver>

前の構成コードが次のリクエストURLに適用されます。

http://secure.banking.de:7001/mywebshop/shopping/s28373/basket/checkout.jsp

この構成コードにより、Business Transaction Managementで次のオブジェクトが生成されます。

オブジェクト

値

説明

Service

mywebshop

サービス名はcontextRoot属性の値です。

Endpoint

http://secure.banking.de:7001/mywebshop

エンドポイントは、監視対象Webアプリケーションにサービス名(contextRoot属性の値)を付加したものの物理的位置です。

Operation

basket_checkout.jsp

デフォルトでは、操作名はリクエストURLからのディレクトリとファイル名で構成されています。この場合、デフォルトの操作名はshopping/s28373/basket/checkout.jspになります。ただし、<operationRule>要素のexcludeDirectories属性が1, 2に設定されているため、1つ目と2つ目のディレクトリ(shopping/s28373/)は除外されます。

例2 - 操作名へのパラメータ名/値のペアの追加

<ap:servletObserver xmlns:ap="http://namespace.amberpoint.com/amf">
<ap:application contextRoot="/physician">
<ap:operationRule>
<ap:partitionByParam name="lastName"/>
</ap:operationRule>
</ap:application>
</ap:servletObserver>

前の構成コードが次のリクエストURLに適用されます。

http://stbdm02:7011/physician/physicianSection/viewRecordSummary.action

POSTパラメータがlastName=Einsteinになっている構成コードにより、Business Transaction Managementで次のオブジェクトが生成されます。

オブジェクト

値

説明

Service

physician

サービス名はcontextRoot属性の値です。

Endpoint

http://stbdm02:7011/physician

エンドポイントは、監視対象Webアプリケーションにサービス名(contextRoot属性の値)を付加したものの物理的位置です。

Operation

physicianSection_viewRecordSummary.action_lastName_Einstein

<partitionByParam>要素で指定されているパラメータの名前および値がデフォルトの操作名に追加されます。

例3 - リクエストのフィルタ処理およびルールセットの適用

<ap:servletObserver xmlns:ap="http://namespace.amberpoint.com/amf">
<ap:application contextRoot="/em">
<ap:framework type="ADF">
<ap:include pattern="*/faces*"/>
</ap:framework>
<ap:framework type="URL">
<ap:include pattern="*/console*" />
</ap:framework>
<ap:operationRule excludeDirectories="1, 2" />
</ap:application>
</ap:servletObserver>

前の構成コードが次のリクエストURLに適用されます。

http://myhost:17861/em/faces/ocamm/managers/ocammHome
http://myhost:17861/em/console/all/targets/search
http://myhost:17861/em/em2go/about.jsp

この構成コードにより、Business Transaction Managementで次のオブジェクトが生成されます。

オブジェクト

値

説明

Service

em

サービス名はcontextRoot属性の値です。

Endpoint

http://myhost:17861/em

エンドポイントは、監視対象Webアプリケーションにサービス名(contextRoot属性の値)を付加したものの物理的位置です。

Operation

managers_ocammHome

(これは最初の例のURLに関連しています)
<framework>要素のタイプはADFに設定されているため、ADFルールセットが使用されます。このため、デフォルトでは操作名はリクエストURLからのディレクトリとファイル名で構成されています。この場合、デフォルトの操作名はfaces/ocamm/managers/ocammHomeになります。ただし、<operationRule>要素のexcludeDirectories属性が1, 2に設定されているため、1つ目と2つ目のディレクトリ(faces/ocamm/)は除外されます。

Operation

targets_search

(これは2つ目の例のURLに関連しています)
<framework>要素のタイプはURLに設定されているため、URLルールセットが使用されます。このため、デフォルトでは操作名はリクエストURLからのディレクトリとファイル名で構成されています。この場合、デフォルトの操作名はconsole/all/targets/searchになります。ただし、<operationRule>要素のexcludeDirectories属性が1, 2に設定されているため、1つ目と2つ目のディレクトリ(console/all/)は除外されます。

N/A

N/A

(これは3つ目の例のURLに関連しています)
タイプURLの<framework>要素は、パターン*/console*のみで指定されました。このリクエストはそのパターンに適合しません。また、ADF <framework>要素に指定されているパターンにも適合しません。このため、監視から除外されます。

例4 - 操作名へのパラメータ名と値の複数のペアの追加

<ap:servletObserver xmlns:ap="http://namespace.amberpoint.com/amf">
<ap:application contextRoot="/physician">
<ap:operationRule>
<ap:paramGroup>
<ap:partitionByParam name="firstName"/>
<ap:partitionByParam name="lastName"/>
</ap:paramGroup>
</ap:operationRule>
</ap:application>
</ap:servletObserver>

前の構成コードが次のリクエストURLに適用されます。

http://st02:7011/physician/physicianSection/viewRecordSummary.action

POSTパラメータがfirstName=JohnおよびlastName=Doeになっている構成コードにより、Business Transaction Managementで次のオブジェクトが生成されます。

オブジェクト

値

説明

Service

physician

サービス名はcontextRoot属性の値です。

Endpoint

http://st02:7011/physician

エンドポイントは、監視対象Webアプリケーションにサービス名(contextRoot属性の値)を付加したものの物理的位置です。

Operation

physicianSection_viewRecordSummary.action_firstName_John__lastName_Doe

<paramGroup>要素内に指定されたパラメータの名前および値は、リストされる順にデフォルトの操作名に追加されます。firstNameパラメータまたはlastNameパラメータが使用可能でなかった場合、この<paramGroup>要素は無視され、その結果physicianSection_viewRecordSummary.actionの値になります。

例5 - パラメータの優先順位処理

<ap:servletObserver xmlns:ap="http://namespace.amberpoint.com/amf">
<ap:application contextRoot="/physician">
<ap:operationRule>
<ap:paramGroup>
<ap:partitionByParam name="firstName"/>
<ap:partitionByParam name="lastName"/>
</ap:paramGroup>
<ap:partitionByParam name="lastName"/>
<ap:partitionByParam name="middleName"/>
</ap:operationRule>
</ap:application>
</ap:servletObserver>

前の構成コードが次のリクエストURLに適用されます。

http://st02:7011/physician/physicianSection/viewRecordSummary.action

POSTパラメータがlastName=SmithおよびmiddleName=Rodneyになっている構成コードにより、Business Transaction Managementで次のオブジェクトが生成されます。

オブジェクト

値

説明

Service

physician

サービス名はcontextRoot属性の値です。

Endpoint

http://st02:7011/physician

エンドポイントは、監視対象Webアプリケーションにサービス名(contextRoot属性の値)を付加したものの物理的位置です。

Operation

physicianSection_viewRecordSummary.action_lastName_Smith

プローブはまず、<paramGroup>要素に指定されているパラメータがリクエストにあるかどうかをチェックします。firstNameパラメータが指定されていないため、<paramGroup>要素全体がスキップされます。次にプローブは、次の<paramGroup>要素またはスタンドアロンの<partitionByParam>要素をチェックします。次の要素にlastNameパラメータが指定され、そのパラメータがリクエストにあるため、そのパラメータの名前と値が操作名(_lastName_Smith)に追加されます。この一致の検出後、プローブはパラメータのチェックを停止します。つまり、middleNameパラメータは操作名に追加されません。

12.1.2.9.1 UserActivityInfoリクエスト・パラメータの有効化

<adfOptions>要素および<globalAdfOptions>要素が備える操作パーティション化機能を使用する場合は、UserActivityInfoリクエスト・パラメータがアプリケーションに対して有効であることを確認する必要があります。Oracle Enterprise Manager Real User Experience InsightでADFサポートを使用する環境だけでなく、Oracle Fusion Applications環境でもこれがデフォルトで有効になっています。

ADFアプリケーションでUserActivityInfoリクエスト・パラメータを有効にするには、アプリケーションのweb.xmlファイルで次のプロパティを設定します。

<context-param>
<description>
This parameter notifies ADF Faces that the ExecutionContextProvider
service provider is enabled. When enabled, this will start
monitoring and aggregating user activity information for the client
initiated requests. By default, this param is not set or is false.
</description>
<param-name>
oracle.adf.view.faces.context.ENABLE_ADF_EXECUTION_CONTEXT_PROVIDER
</param-name>
<param-value>true</param-value>
</context-param>

12.1.2.10 情報設定フィールドのリファレンス

フィールド名

説明

名前

必須。ポリシーの名前を指定します。このフィールドを一意の文字列に設定できます。

バージョン

オプション。このフィールドは説明用であり、ポリシーの関連情報を入力するために用意されています。

注意

オプション。このフィールドは説明用であり、ポリシーの関連情報を入力するために用意されています。

12.1.2.11 詳細設定フィールドのリファレンス

フィールド名(太字はセクション名)

説明

オブザーバの動作

-

構成ポーリング間隔

必須。このフィールドでは、オブザーバが新しい構成がないかどうかをチェックする頻度を秒単位で指定します。

インスツルメント更新間隔

必須。このフィールドでは、オブザーバが測定データをモニターに送信する頻度を秒単位で指定します。

接続数

このフィールドでは、オブザーバが開くソケット接続の数を指定します。複数の接続を使用すると、監視のスループットが向上します。

マッピング・アルゴリズム

リクエストおよびWSDL URLのホスト名とポート番号の部分の変更に使用されるアルゴリズムを指定します。次の値から選択してください。
送信時のまま: オブザーバは、URLを書き換えずにそのままモニターに転送します。

ホスト名を使用: オブザーバは、URLのホスト名の部分をサーバーのホストの完全修飾名に置き換えます。また、URLのポート番号の部分をサーバーがリスニングしているポート番号に置き換えます。ホスト名およびポート番号は、デプロイメント環境から取得されます。

このアルゴリズムは、クラスタ化されたサーバーの前にロード・バランサがある場合に有益です。このシナリオでは、元のリクエストURLはロード・バランサのもので、ロード・バランサのホスト名およびポート番号が指定されています。オブザーバが元のリクエストURLをモニターに渡した場合、サーバーのクラスタ全体が単一のサーバーとしてモデル化されます。アルゴリズムがuseHostnameに設定されると、各サーバーは個別にモデル化されます。

IPアドレスを使用: オブザーバは、URLのホスト名をIPアドレスに変換します。ポート番号はそのままです。IPアドレスは、デプロイメント環境から取得されます。

このアルゴリズムは、モニターがホスト名を有効なIPアドレスに解決できない場合に便利です。サーバーに複数のIPアドレスがある場合には、このアルゴリズムを使用しないでください。

完全修飾名(FQN)を使用: オブザーバは、URLのホスト名を完全修飾名に変換します。ポート番号はそのままです。

このアルゴリズムは、サーバーに複数のIPアドレスがある場合に便利です。

代替を使用: このアルゴリズムでは、ホスト名、ポート番号およびプロトコルに特定の値を指定できます。次の3つのフィールドを使用して値を入力します。いずれかのフィールドに値を指定しない場合、URLの対応する部分はそのままになります。

注意: OSBオブザーバの場合、ターゲット・サービスURLは常にオブザーバ構成のFQNに設定されますが、この設定はこのポリシーには表示されていません。

代替ホスト

URLのホスト部分として使用される値。

代替ポート

URLのポート番号部分として使用される値。

代替プロトコル

URLのプロトコル部分として使用される値。

検出処理間隔

オブザーバが新しいコンポーネントの検出を試みる一定の間隔(分単位)を指定します。デフォルト値は3分です。1440分(1日)を超える値は1440分と解釈されます。負の値は3分と解釈されます。

動的検出期間の有効化

オブザーバが新しいコンポーネントの検出を試みる際のタイミングのアルゴリズムを有効化します。有効化されている場合、検出間隔は各検出後に倍になり、指定されている検出処理間隔の最大32倍にまでなります。1440分(1日)を超える計算値は1440分と解釈されます。この機能により、変更されていないコンポーネントが頻繁に処理されなくなります。
たとえば、検出処理間隔が300に設定されていて、このオプションが有効化されている場合、2番目の検出は600分後に発生し、次に1200分となりますが、1440分を超えて増加することはありません。

オブザーバのトラブルシューティング

-

トレース・ロギングの有効化

トレース・ロギングは常に有効になっており、デフォルトでは「情報」に設定されています。このチェック・ボックスは、「トレース・ロギング・レベル」フィールドを有効にして設定を編集できるようにする場合に使用します。
他のタイプのオブザーバ・エラーのロギング、エラー・ログ・ファイルの場所およびエラー・ログの場所の構成については、12.1.3項「オブザーバ・エラーおよびデバッグ情報のロギング」を参照してください。

トレース・ロギング・レベル

このフィールドでは、ログ・ファイルに書き込む情報のレベルを指定します。有効な値は情報量の少ない順に次のとおりです。
「情報」、「普通」、「詳細」、「最も詳細」

トレース・ファイルのサイズ

このフィールドには、トレース・ログ・ファイルのサイズをKB単位で指定します。

トレース・ファイルのカウント(切替え)

このフィールドには、トレース・ログ・ファイルの最大数を指定します。トレース・ログ・ファイルの最大数に達すると、切替えが発生して最も古いファイルが新しいファイルで上書きされます。
一般に、この設定を変更するのはOracleサポートからそうするように求められたときのみです。

監視対象メッセージをファイルに記録

監視対象メッセージをファイルに書き込む場合には、このチェック・ボックスを有効にします。

監視ログ・ディレクトリ

監視ログ・ファイルが含まれているディレクトリへのパス。WebLogic、OC4J、WebSphereおよびJBossサーバーの場合、絶対パスまたは相対パスを指定できます。その他のサーバーの場合、絶対パスのみを指定できます。相対パスはデフォルトの場所を基準にします。デフォルトの場所は次のとおりです。

- WebLogic: ドメイン・ディレクトリ

- 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に設定した場合、ログ・ファイルは作成されません。

オブザーバのメッセージ・キュー

このセクションのフィールドは、オブザーバの監視キューの動作に影響を及ぼします。オブザーバは、監視対象でサービス宛てのメッセージをこの送信キューにコピーします。これらの監視はその後、キューから取り出されてモニターに送信されます。

キュー・サイズ

必須。このフィールドには、オブザーバの監視キューが保持できるメッセージの最大数を指定します。数を大きくすると、キューに割り当てられるメモリー量が増えます。

最大メッセージ・サイズ

オプション。このフィールドには、オブザーバの監視キューに配置できるメッセージの最大サイズをKBで指定します。指定したサイズよりも大きいメッセージは、まず切り捨てられ、その後キューに配置されます。
このフィールドを使用すると、ネットワークおよびモニターの負荷を軽減できます。

切捨ては、メッセージの本文にのみ適用されます。メッセージのエンベロープはそのままです。

注意: サービスが他のサービスに対するクライアントである場合、この設定はそれらのサービスを監視するオブザーバと同じ値に設定する必要があります。そうしないと、依存性トラッキング・メカニズムが混乱し、存在しないクライアントが依存性ダイアグラムに表示されます。

キューが満杯の場合

注意: Oracleサポートから編集の指示がないかぎり、このフィールドはデフォルト設定のままにしてください。このフィールドのデフォルト設定は「サービス宛てのメッセージをキューにコピーせずに転送」です。
「キューが満杯の場合」フィールドには、オブザーバの監視キューが満杯になった場合の動作を指定します。次のオプションのいずれかを選択してください。

サービス宛てのメッセージをキューが空いてコピー可能になるまで延期: キューが満杯の場合、オブザーバは元のメッセージをサービスに転送する前に、キューが監視を保持するのに十分な領域を確保するまで待機します。この設定によって、すべてのメッセージのコピーがモニターに転送されるようになります。ポリシーのモニター構成セクションで「ソケットを介した監視対象メッセージの受信をキューが空くまで延期」オプションとともにこのオプションを選択すると、すべての監視がログに記録されるようになります。ただし、通信量が多い状況では、このような設定にすると、監視対象アプリケーションによるメッセージ処理の速度が低下する場合があります。

サービス宛てのメッセージをキューにコピーせずに転送: キューが満杯の場合、オブザーバはキューにコピーすることなく元のメッセージをサービスに転送します。このオプションを選択すると、監視対象アプリケーションのメッセージ処理速度が低下することなく監視がログに記録されるようになります。ただし、通信量が多い状況では、この設定にすると監視が失われる場合があります。

注意: どのような場合にも、オブザーバが元のサービス宛てのメッセージを破棄することはありません。

モニターのメッセージ・キュー

このセクションのフィールドは、モニターの監視キューの動作に影響を及ぼします。監視は、モニターに到達すると、この受信キューに配置されます。モニターはその後、パフォーマンスやトランザクションなどに関するデータを収集するためにキューから監視を取り出して処理します。

キュー・サイズ

必須。このフィールドには、モニターの監視キューが保持できるメッセージの最大数を指定します。数を大きくすると、キューに割り当てられるメモリー量が増えます。

最大メッセージ・サイズ

オプション。このフィールドには、モニターの監視キューで受け付けられるメッセージの最大サイズをKBで指定します。このフィールドを使用すると、サイズの大きなメッセージの処理を制限してモニターの負荷を軽減できます。
このフィールドに値を指定することにより、指定した値よりも大きくなった場合にはリクエストとレスポンスの両方のメッセージ(またはフォルトの場合はフォルト・メッセージ)を削除するようにBusiness Transaction Managementに指示します。サイズが大きすぎるメッセージは処理されずに削除され、スループットや平均レスポンス時間などのパフォーマンス測定の計算に使用されません。

アイドル・ソケット・タイムアウト

必須。このフィールドには、トラフィックがない場合にモニターが監視を受信するソケットを開いたままにする最大ミリ秒数を指定します。

リクエスト・メッセージの最大保持時間

オプション。この設定には、レスポンスが届かないとみなされるまでに、モニターがリクエスト・メッセージを保持する秒数を指定します。この時間を超えると、リクエストはレスポンス・メッセージがタイムアウトした場合と同じように処理されます。このフィールドを空白のままにするか、または0に設定した場合は、デフォルト値の60秒が使用されます。

メッセージを処理するスレッドの数

オプション。このフィールドには、モニターが監視メッセージの処理用に割り当てるスレッドの数を指定します。このフィールドを空白のままにするか、または0に設定した場合は、デフォルト値の5秒が使用されます。

エンドポイント検出を処理するスレッドの数

オプション。このフィールドには、モニターがエンドポイント検出メッセージの処理用に割り当てるスレッドの数を指定します。このフィールドを空白のままにするか、または0に設定した場合は、デフォルト値の2秒が使用されます。

キューが満杯の場合

必須。このフィールドには、モニターの監視キューが満杯になった場合の動作を指定します。次のオプションのいずれかを選択してください。
ソケットを介した監視対象メッセージの受信をキューが空くまで延期: 満杯になった場合、キューは監視の受信(メッセージのコピー)をそのための領域が確保できるまで拒否します。この場合、オブザーバはキューに正常に配置されるまで監視を再送信します。ポリシーのオブザーバ構成セクションで「サービス宛てのメッセージをキューが空いてコピー可能になるまで延期」オプションとともにこのオプションを選択すると、すべての監視がログに記録されるようになります。ただし、通信量が多い状況では、このような設定にすると、監視対象アプリケーションによるメッセージ処理の速度が低下する場合があります。

受信した監視対象メッセージを破棄: 満杯になった場合、キューは受信した監視を破棄します。ポリシーのオブザーバ構成セクションで「サービス宛てのメッセージをキューにコピーせずに転送」オプションとともにこのオプションを選択すると、監視対象アプリケーションのメッセージ処理速度が低下しなくなります。ただし、通信量が多い状況では、この設定にすると監視が失われる場合があります。

注意: どのような場合にも、モニターは元のアプリケーション・メッセージを破棄しません。

サーブレット・オブザーバ構成

-

WEB_APPプローブ構成の指定

このチェック・ボックスはWEB_APPプローブに関連しており、リクエストの監視および操作のモデル化を選択的に構成できるようになります。このチェック・ボックスを有効にすると、「WEB_APPプローブ構成」フィールドが表示され、これらのオプションの構成コードを入力できます。このフィールドはデフォルトで有効になっています。
注意: 「カスタム・オブザーバ構成」フィールドにカスタム・オブザーバ構成を指定する場合は、このチェック・ボックスを有効にしないでください。かわりに、「カスタム・オブザーバ構成」フィールドのカスタム・オブザーバ構成にフィルタ処理/モデル化のコードを追加する必要があります。このコードは、<servletObserver>要素に含め、カスタム構成の<nanoAgentConfigurations>要素(カスタム構成のルート要素)の最後の子として追加する必要があります。

WEB_APPプローブ構成

このフィールドは、「WEB_APPプローブ構成の指定」チェック・ボックスが有効になっている場合にのみ表示されます。
このフィールドを使用してWEB_APPプローブの構成に<servletObserver>要素を入力します。この要素により、リクエストの選択的監視および操作のモデル化を制御できます。

デフォルトでは、このフィールドに次のコードが含まれており、プローブは指定された拡張子を持つファイルに対するリクエストを監視しないように指示されます。

<ap:servletObserver rueiPresent="true" rueiMatches="false"

xmlns:ap="http://namespace.amberpoint.com/amf">

<ap:globalExcludeList ext="jpg, jpeg, html, htm, css, gif,

png, ico, js, swf, cur"/>

</ap:servletObserver>

<servletObserver>要素のコーディングについては、12.1.2.9項「WEB_APPプローブ用のリクエストの監視および操作のモデル化」を参照してください。

カスタム・オブザーバ構成

-

カスタム構成の使用

このポリシーで使用可能でないオブザーバ構成オプションが必要である場合は、このチェック・ボックスを有効にし、次のフィールドにオブザーバ構成を入力します。このチェック・ボックスが有効である場合、カスタム構成はこのポリシーの他のすべてのフィールドをオーバーライドします。

カスタム・オブザーバ構成

このフィールドでは、カスタム・オブザーバ構成を入力します。このフィールドは、「カスタム構成の使用」チェック・ボックスが有効になっている場合にのみ表示されます。

モデル構成

このセクションのフィールドでは、Business Transaction Managementが特定のタイプのコンポーネントをどのようにモデル化するかを制御します。
警告: オブザーバをインストールしてコンポーネントを検出する前に、これらのフィールドを適切な設定にあわせて調整してください。すでに検出されたコンポーネントに対してこれらの設定を編集する場合は、既存のトランザクション定義を変更したり、モデルをリセットすることが必要になる場合があります(モデルのリセット方法については、10.11項「deleteAll」を参照してください)。

SOA

このフィールドは、SOAコンポーネントをどのようにモデル化するかを制御します。次のオプションのいずれかを選択してください。
すべてモデル化: すべてのSOAコンポーネントをモデル化します。

フローのエッジのモデル化: 各SOAコンポジット・アプリケーションの最初のコンポーネント(たとえば、Webサービス・インタフェース)のみをモデル化します。これがデフォルトの設定です。この設定は、この設定にかかわらずすべてのコンポーネントが常にモデル化されるSOA_B2BまたはSOA_JCAには適用されません。

ローカルEJB

このフィールドは、ローカルEJBコンポーネントをどのようにモデル化するかを制御します。リモートEJBコンポーネントのモデル化には影響しません(すべてのリモートEJBが常に監視されます)。次のオプションのいずれかを選択してください。
すべてモデル化: すべてのローカルEJBコンポーネントをモデル化します。

モデル化しない: ローカルEJBコンポーネントをモデル化しません。これがデフォルトの設定です。

フローのエッジのモデル化: 各ローカル・リクエスト・フローの最初のローカルEJBコンポーネントのみをモデル化します。

ORA-WSのモデル化: EJB実装クラスに関する次のいずれかの注釈の存在に基づいてOracle Webサービス(ORA-WS) Webサービス用のビジネス・ロジックを実装するローカルEJBコンポーネントのみをモデル化します。

- oracle.webservices.annotations.PortableWebService

- oracle.webservices.annotations.PortableWebServiceProvider

このオプションは、特にORA-WS向けに設計されています。ORA-WSは、主としてFusion ApplicationsなどのOracleパッケージ・アプリケーションで使用されます。

OSB

このフィールドは、Oracle Service Busコンポーネントをどのようにモデル化するかを制御します。次のオプションのいずれかを選択してください。
すべてモデル化: OSBビジネス・サービス、プロキシ・サービス、分割-結合タスク、発行元が分割-結合タスクであるメッセージのパラレル・フローなど、すべてのOracle Service Busコンポーネントをモデル化します。

フローのエッジのモデル化: プロキシ・サービスのみをモデル化します。これがデフォルトの設定です。

JMS

このフィールドは、JMSトピック、キューおよびメッセージ・リスナーをどのようにモデル化するかを制御します。次のオプションのいずれかを選択してください。
すべてモデル化: すべてのJMSトピック、JMSキューおよびその関連するメッセージ・リスナーをモデル化します。

フローのエッジのモデル化: JMSトピックに関連付けられたメッセージ・リスナーのみをモデル化します。これがデフォルトの設定です。

JDBCサマリー

このセクションのフィールドは、JDBCサマリー・モードを制御します。サマリー・モードを有効にすると、関連するJDBCコールの監視が集計され、単一サマリー監視メッセージとしてモニターに送信されます。サマリー・モードを有効にすることで、特に監視されるサービスがJDBCコールを多数使用し、これらの操作に対してメッセージ・ロギングを有効にしている場合、BTMシステムのパフォーマンスを改善し、データベースのディスク領域要件を低減できます。監視メッセージのボリュームの低減、およびメッセージ・ログ・データベースに書き込まれるJDBCコール数の制約の両方により、これらの利得が達成されます。メッセージ・ロギングの制約を制御できるオプションが用意されています。
注意: JDBCサマリー・モードは、レスポンス時間などパフォーマンス測定の収集、記録または表示に影響を及ぼしません。

サマリー・モード有効化

このフィールドでは、JDBCサマリー・モードを有効または無効にします。デフォルトでは、この設定は有効です。

ログに記録する最遅JDBCコール数

ログを記録する必要がある最遅JDBCコール数を指定します。たとえば、2を指定した場合、2つの最遅コールのみがサマリー監視メッセージに含まれ、メッセージ・ログ・データベースにログが記録されます(その操作に対してメッセージ・ロギングが有効であると想定します)。デフォルト値は3つのコールです。

JDBCコールの時間制限

非推奨。この機能は指定された時間制限に達したときにのみシステム・アラートを送信します。この時間制限は、想定される最長のSQL問合せ時間よりも大きく設定することをお薦めします。JDBCコールの完了に必要と思われる最長期間を秒単位で指定します。JDBCコールが時間制限を超えた場合、サマリー監視メッセージが即時に送信されます。この不完全なサマリー監視メッセージは、問合せの完了に想定よりも長く時間がかかっているという警告として機能します(未完了のJDBCコールのレスポンス時間の値は「タイムアウト」の値で示されます)。不完全なJDBCコールを後で完了する場合、または他の関連するコールが監視される場合、前のサマリー・メッセージからの情報と、新しく完了したコールまたは新しく監視されたコール(あるいはその両方)からの情報を組み合せたフォローアップ・サマリー監視メッセージが送信されます。デフォルト値は10秒。

ログに記録するフォルト・メッセージ数

ログを記録する必要があるフォルト・メッセージ数を指定します。たとえば、1を指定した場合、最初に受信したフォルト・メッセージのみがサマリー監視メッセージに含まれ、メッセージ・ログ・データベースにログが記録されます(その操作に対してメッセージ・ロギングが有効であると想定します)。2を指定した場合、最初と最後がログに記録されます。3を指定した場合、最初、2番目、最後がログに記録されます(以降同様)。デフォルト値は2つのフォルトです。

コール元がコンテンツを取得するように構成されている場合にのみサマリーを取得

通常、エンドポイントがトランザクションに含まれ、ロギングが有効になっている場合、そのエンドポイントがトランザクションの外部から呼び出されたときでも、メッセージは取得されます。
このボックスを選択すると、JDBCおよびJDBCコール操作に対してロギングが有効である場合にのみ、(フォルトおよび最遅メッセージの)メッセージ・コンテンツがログに記録されます。(トランザクション全体に対してインスタンス・ロギングが有効であるか、またはJDBCコール操作に対してロギングが有効であるため、ロギングはJDBCコール操作に対して有効です。)

このボックスを選択しないと、コール元がトランザクションに含まれていない場合でも、JDBCエンドポイントに送信されるすべてのメッセージがカウントされます。フォルト・メッセージおよび最遅メッセージのコンテンツが記録されます。

JDBC拡張構成

このセクションのフィールドにより、JDBC機能を詳細に制御できます。

SQLパラメータの表示

通常、関連するJDBCコールの監視を集約して単一のサマリー監視メッセージとしてモニターに送信する際、すべての定数パラメータは非表示になります。このオプションを有効化した場合、パラメータが表示されます。パラメータには、機密情報が含まれる場合があることに注意してください。

コール・スタックの表示

このオプションを有効化した場合、Javaコール・スタックが表示されます。このオプションを有効化すると、パフォーマンスに影響する可能性があることに注意してください。

Oracle SQL-IDの表示

このオプションを有効化した場合、各問合せのSQL-IDが表示されます。これにより、データベース管理者によって実行される問合せを詳細に分析できます。

12.1.2.12 基準

このセクションでは、このポリシーを適用するモニターを選択します。

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

オブザーバは、次のログ・ファイルにエラーおよびデバッグ情報を書き込みます。

- NanoAgentErrorTrace.log: 他のログ・ファイルに記録されたすべてのエラーおよび警告の出現が1回分のみ含まれています。各エラーおよび警告のエントリは、<Ref>要素内で一意の識別子で参照されます。たとえば、次のとおりです。

<Ref: Dq/QGNWqOmbdXPigC+vsO40eXgs=>

この識別子を使用して、他のログ・ファイル(通常NanoAgent.log)内のエラーまたは警告のすべての出現を検索できます。これは一般に、問題が発生したときに最初にチェックするログ・ファイルです。

このログ・ファイルのデフォルト・サイズは10MBで、サーバーの再起動のたびに再作成されます。ただし、デフォルトの切替えが2に設定されているため、前のログ・ファイルはサーバーの再起動後も保持されます。

- NanoAgent.log: ランタイム・エラー、構成関連のエラーおよびデバッグ情報が含まれています(このロガーの設定は、オブザーバ通信ポリシーの「トレース・ロギングの有効化」オプションを使用して調整できます)。

- NanoAgentPreprocessTrace.log: バイトコード・インスツルメンテーションのエラーとデバッグ、クラスロードおよび前処理に関する情報が含まれています。このファイルは、サーバーの再起動のたびに再生成されます。このログ・ファイルの最大サイズは10MBです。
リリース12.1.0.2.2では、このファイルの名前が変更されました。以前のリリースのオブザーバでは、ファイルはAWTrace.logという名前でした。

注意:
また、監視対象メッセージをログに記録するようにオブザーバを構成することもできます。このトピックについては、12.1.2.11項「詳細設定フィールドのリファレンス」の「監視対象メッセージをファイルに記録」エントリを参照してください。

ログ・ファイルのデフォルトの場所は次のとおりです。

- 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スクリプトを編集します。ファイルのオプションのセクションでは、-DAP_NANO_LOG_BASEDIR="my_log_dir"をNANOAGENT_JAVA_OPTIONSの最後に追加します。この相対パスにより、ドメイン・ディレクトリのmy_log_dirディレクトリにログ・ファイルが生成されます。
ノード・マネージャを使用してWebLogicサーバーを構成する場合は、WebLogic管理コンソールを開き、サーバーを選択し、構成/サーバー起動タブを表示します。次に、-DAP_NANO_LOG_BASEDIR=my_log_dirを「引数」フィールドに追加します。この相対パスにより、ドメイン・ディレクトリのmy_log_dirディレクトリにログ・ファイルが生成されます。

- OC4Jで、-DAP_NANO_LOG_BASEDIR=my_log_dirをJava起動オプションに追加します。この相対パスにより、SOA Suiteインストール・ディレクトリ内のj2ee\homeディレクトリにあるmy_log_dirディレクトリにログ・ファイルが生成されます。

- Enterprise Gatewayで、OEG_HOME/system/conf/jvm.xmlをテキスト・エディタで開き、<SystemProperty name="AP_NANO_LOG_BASEDIR" value="C:\OEG\my_log_dir"/>を<JVMSettings>要素の子として追加します。この絶対パスにより、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を編集します。ファイルのオプションのセクションで、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に設定されている場合、ログ・ファイルは作成されません。

12.2 永続的データ

この項では、Business Transaction Managementの永続的データの管理に役立つ情報を提供します。この項の内容は次のとおりです。

- Business Transaction Managementデータベース資格証明の構成

- メッセージ・ログ・データベースの設定

- 永続記憶域ディレクトリについて

- Business Transaction Management永続記憶域ディレクトリの再配置

12.2.1 Business Transaction Managementデータベース資格証明の構成

Business Transaction Managementをインストールしたときに、Oracle Databaseを使用するように構成しました。データベースへのアクセスに使用される資格証明が変更された場合は、それに関連付けられた設定をBusiness Transaction Managementで適宜変更する必要があります。

データベース資格証明設定を変更するには:

1. 「管理」→「データベース設定の編集」を選択します。
「データベース設定の編集」ツールが開きます。このツールを使用すると、Business Transaction Managementの一元的サービスで使用されているユーザー名およびパスワードを設定して、Business Transaction Managementデータベースにアクセスできます。

注意:
「組込みデータベース」オプションは選択しないでください。3つすべてのデータベースで「外部データベース」オプションが選択されています。

2. 各データベースに応じてユーザー名およびパスワードを編集します。

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

12.2.2 メッセージ・ログ・データベースの設定

トランザクションに対してメッセージ・ロギングを有効にする場合は、メッセージをログに記録するモニター用にデータベースを設定する必要があります。Business Transaction Managementのインストールおよび初期構成時に、メッセージ・ログ・データベース(messageLogDB)を作成し、このデータベースの接続設定を指定しました。これらの接続設定は、デフォルト・メッセージ・ログ・データベース・ポリシーに自動的に格納され、すべてのモニターに適用されました。

ただし、メッセージ・ロギングに単一のデータベースを使用するという制限はありません。追加のデータベースを作成し、データベースごとに使用するモニターが異なるように構成できます。このためにはまず、別のデータベースにログを記録するモニターにはポリシーが適用されなくなるように、デフォルト・ポリシーの「基準」セクションを編集します。次に、新しいデータベースごとに新しいポリシーを作成し、各ポリシーの「基準」セクションを使用してポリシーを適切なモニターに適用します。モニターごとに1つのポリシーのみが適用されることに注意する必要があります。メッセージ・ログ・データベースの作成方法については、『Business Transaction Managementインストレーション・ガイド』を参照してください。

いずれかのメッセージ・ログ・データベースの場所またはログオン資格証明を変更した場合は、モニターがそのデータベースへの接続に使用する設定を再構成する必要があります。そのためには、適切なメッセージ・ログ・データベース・ポリシーを編集します。

既存のメッセージ・ログ・ポリシーが適用されるモニターを表示するには:

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

2. メイン領域でポリシーを選択します。

3. 「ターゲット」タブをクリックします。

新しいメッセージ・ログ・データベースを編集または適用するには:

1. メッセージ・ログ・データベース用に使用するOracle Databaseインスタンスを作成または特定します。

2. データベース接続の構成に使用するメッセージ・ログ・データベース・ポリシーを開きます。
デフォルトのメッセージ・ログ・データベース・ポリシーを編集する場合は:

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

2. メイン領域で「デフォルト・メッセージ・ロギング・データベース・ポリシー」を選択します。

3. 「変更」→「定義の編集: デフォルト・メッセージ・ロギング・データベース・ポリシー」を選択します。

新しいメッセージ・ログ・データベース・ポリシーを適用する場合は、「管理」→「システム・ポリシーの作成」→「メッセージ・ログ・データベース」を選択します。

メッセージ・ログ・データベースの作成ポリシーが開きます。

3. 「データベース・タイプ」が「外部のOracleデータベースを使用」に設定されていることを確認します。

注意:
組込みデータベースは、本番システムではサポートされていません。

4. Business Transaction Managementの一元的サービスからメッセージ・ログ・データベースに直接アクセスできるようにする場合は、「一元的アクセスの許可」オプションが有効になっていることを確認します。
このオプションが無効になっている場合、一元的サービスはモニターを介してのみメッセージ・ログ・データベースにアクセスできます。

一部の一元的サービス(トランザクション監視コンポーネントなど)では、メッセージ・ログ・データベースに格納されているメッセージ・コンテンツへのアクセスが必要になります。このような一元的サービスは、モニター経由または直接接続でデータベースにアクセスできます。直接接続を使用すると、メッセージ・ログ問合せのパフォーマンスが向上します。この通信チャネルは、可能な場合には有効にしてください。

デプロイメント・シナリオによっては、一元的サービスからデータベースに直接問い合せず、かわりにモニターがその問合せを行うようにすることをお薦めします。このような事例の1つが、モニターおよびデータベースが一元的サービスからファイアウォールで保護されている場合です。このようなシナリオでは、一元的サービスはモニターとは通信できますが、データベースとは通信できない可能性があります。

5. データベースにアクセスするための接続文字列およびユーザー資格証明を指定します。
指定した資格証明を持つユーザーは、表および索引を作成および削除する権限を持っている必要があります。

6. 必要に応じて「最大トランザクション・メトリック行数」を調整します。
当初、これはデフォルト設定のままである可能性があります。

このフィールドには、一時表に記録する行の最大数を指定します。一時表は、トランザクション測定の集計を計算する前に個々のトランザクション開始/終了メッセージを追跡するために使用されます。この値を大きくすると、パフォーマンス・サーバーがトランザクション測定をより効率的に処理できるようになりますが、メッセージ・ログ・データベースによるディスク使用量が増加するというデメリットがあります。

7. 「拡張オプションの表示」チェック・ボックスを有効にして、拡張オプションを編集できます。
次の表では、拡張オプションについて説明します。

拡張オプション

UIのデフォルト設定

説明

インデクサ・チューニング・パラメータ

-

-

自動統計を使用

有効

ブール
このパラメータが有効になっている場合、モニターはデータベースからデータベース統計を定期的に収集します。メッセージ・ログ問合せを効率よく実行するには、最新のデータベース統計を維持する必要があります。統計は、これまでに行われたデータベースへの挿入の数に基づいて収集されます。

ログ・バンドル読取りバッチ・サイズ

300

整数
単一のデータベース・トランザクションのインデクサによって処理されるメッセージの数を決定します。

インデクサ再開間隔

10

整数 - 時間(秒単位)
インデクサがウェイクアップして差し迫った作業がないかどうかをチェックする頻度を決定します。

クリーンなデータベース・チェック間隔

120

整数 - 時間(秒単位)
インデクサが様々なメンテナンス・タスクを実行する間隔を決定します。メンテナンスを実行するとき、インデクサは次のことを行います。

1. データベースから期限切れの情報を削除します。

2. サマリー統計表をクリーンアップします。

3. 期限切れのカーソルから結果を保持するデータベース表を削除します。

クリーンなカーソル・チェック間隔

3600

整数 - 時間(秒単位)
インデクサがデータベースから期限切れの問合せ結果を削除する間隔を決定します。

このタスクはインデクサの通常のメンテナンスの一部ですが、これは他のタスクよりも頻繁に行うことが必要になる場合があります。

索引付けの停止

無効

ブール
trueに設定すると、このオプションはすべてのアクティビティを一時停止するようにインデクサに指示します。索引付けされるコンテンツは引き続きアクティブなロギング・ポリシーによって取得されますが、索引付けが再開されるまでディスク上の記憶域からデータベースに転送されません。

このオプションは、特に大量のメッセージ・トラフィックが発生している場合に便利です。この場合、リソースの最適化およびトラフィックの安定した流れの方が、索引付けされたメッセージを検査できることよりも重要です。後で「索引付けの停止」の値をfalseに設定すると、Business Transaction Managementではメッセージを索引付けしてデータベースに入力できるようになります。

注意: インデクサが一時停止している間、Business Transaction Managementでは使用中のディスク領域を管理するための作業が行われません。ロギング・ポリシーによってログに記録されているメッセージを取得するために十分な空のディスク領域があることを確認します。

データベース・エラー最小遅延

10

整数 - 時間(秒単位)
データベース・エラーの発生時にロギング関連のデータベース操作を再試行するまでに、インデクサが待機する最小時間を指定します。以後の各障害では、現在の遅延に「データベース・エラー遅延拡張要因」パラメータの値を乗算することにより、遅延が伸びる方向で調整されます。再試行間の最大待機時間は、「データベース・エラー最大遅延」によって制限されています。

このパラメータが適用されるデータベース・エラーの一例は、モニターがデータベースに問い合せることができなくなることです。たとえば、デフォルト設定では、モニターはデータベースへの接続を失うと10秒後に再接続を試みます。再接続できないと、20秒待機してから再度試みます(以降同様)。試行間の最長待機時間は3600秒(1時間)です。

データベース・エラー最大遅延

3600

整数 - 時間(秒単位)
「データベース・エラー最小遅延」の説明を参照してください。

データベース・エラー遅延拡張要因

2.0

「データベース・エラー最小遅延」の説明を参照してください。

バンドル実行ごとに索引付けされる最大メッセージ数

5000

整数
各インデクサ実行で特定のエンドポイントに対して索引付けするメッセージの最大数を制限します。単一のモニターのすべてのエンドポイントは、単一のワーカーによって索引付けされます。

インデクサ問合せの最大実行時間

300

長整数 - 時間(秒単位)
インデクサが開始する問合せの実行時間に対する時間制限の上限を指定します。

問合せの最大実行時間

30

長整数 - 時間(秒単位)
ユーザーが開始する問合せの実行時間に対する時間制限の上限を指定します。ユーザーは、メッセージ・ログに対して長時間実行の問合せを開始する場合があります。いったん送信されると、ユーザーには問合せを取り消す方法はなく、完了するまで待機する必要があります。

このパラメータのデフォルト値は30秒です。この値を0に設定すると、複雑さに関係なくすべての問合せが完了まで実行されます。そのため、この設定(0)はお薦めしません。

インデクサ・ワーカー・スレッド数

3

長整数
ログ・ポリシー・インデクサで使用されているワーカー・スレッドの数を指定します。インデクサは、ロギング・ポリシーが適用されたエンドポイントを循環し、各エンドポイントを順に索引付けします。スレッドを追加すると、さらに多くのエンドポイントを同時に索引付けできます。

メタデータ挿入バッチ・サイズ

300

長整数
メタデータ挿入文を制御します。このパラメータには、SQL文を実行する前にバッチにまとめる特定のタイプの行数を指定します。実際のバッチ・サイズは、「ログ・バンドル読取りバッチ・サイズ」パラメータの影響も受けます。このパラメータによって最大トランザクション・サイズが設定されるためです。

メッセージ挿入バッチ・サイズ

30

長整数
メッセージ挿入文を制御します。このパラメータには、SQL文を実行する前にバッチにまとめる特定のタイプの行数を指定します。実際のバッチ・サイズは、「ログ・バンドル読取りバッチ・サイズ」パラメータの影響も受けます。このパラメータによって最大トランザクション・サイズが設定されるためです。

ユーザー問合せ接続数

5

長整数
ユーザー問合せの目的で確立する必要があるメッセージ・ログ・データベースへの接続の数を指定します。プールは共有プールであり、システム処理用に確立される接続(「インデクサ・ワーカー・スレッド数」によって制御されます)およびユーザー問合せ用の接続(「ユーザー問合せ接続数」によって制御されます)で構成されています。

表の再利用

無効

ブール
「メッセージ履歴」ポリシーの「切替え間隔」設定によって、メッセージがデータベースに保持される期間が制御されます。デフォルトでは、メッセージは表の削除によって削除され、表の追加によって追加されます。新しい表を削除および作成するのではなく表を再利用する場合は、この設定を有効にします。表は、再利用される前にクリアされます。ほとんどのシナリオでは、この設定を無効のままにした方が効率的です。

フラグメント当たりの最小エントリ

0

長整数
メッセージは、フラグメントと呼ばれる一連の表に格納されます。この設定では、切替え前にフラグメントが保持している必要があるメッセージの最小数を指定します。この制約は、「メッセージ履歴」ポリシーの「切替え間隔」設定の制約を補足するものです。注意: リクエスト/レスポンスのペアは、2つのメッセージであるとみなされます。

インデクサ設定データ・バージョン

-

-

label.IndexerSetupData.generateEndpointStatistics

無効

一般に、このフィールドを有効にするのは、Oracleサポートからそうするように求められた場合のみです。
モニターがトランザクションに参加するエンドポイントを管理中である場合、モニターはロギング目的でメッセージ・インデクサ(アウト・オブ・バンド・インデクサ)を実行することになります。メッセージ・インデクサがモニターで実行中である場合、モニターの「ステータス」タブにはメッセージ・インデクサのパフォーマンスに関する情報が含まれています。デフォルトでは、このタブにはメッセージの索引付けがアクティブなすべてのエンドポイントについてサマリー・インデクサ統計が表示されます。この設定を有効にすると、タブのインデクサ統計にはメッセージの索引付けに参加しているエンドポイントごとに詳細なパフォーマンス情報が含まれます。

8. 「基準」セクションで、データベースにログを記録するモニターを選択します。

注意:
単一のモニターに複数のメッセージ・ログ・データベース・ポリシーを適用しないように注意してください。つまり、新しいメッセージ・ログ・データベース・ポリシーを適用している場合は、まず新しいポリシーと同じモニターに適用されないように既存のポリシーの「基準」セクションを編集する必要があります。単一のモニターに複数のメッセージ・ログ・データベース・ポリシーを適用した場合は、Business Transaction Managementによってシステム・アラートが生成されます。
モニター・グループのすべてのモニターが同じメッセージ・ログ・データベースにログを記録する必要があります。

9. 「適用」をクリックします。

12.2.3 永続記憶域ディレクトリについて

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

永続記憶域に関する社内の手順およびルールにより、これとは異なる場所に永続記憶域ディレクトリを配置することが必要になる場合があります。このような場合、永続記憶域ディレクトリの場所を再構成できます。

インストールされたBusiness Transaction Managementシステムは一連のデプロイメント(EARファイル)で構成され、このデプロイメント自体はサブデプロイメント(WARファイル)で構成されています。各サブデプロイメントには、.warを除いた同じ名前の永続記憶域ディレクトリが関連付けられています。次の表に、デプロイメント、サブデプロイメントおよび永続記憶域ディレクトリの名前を示します。

表12-2 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

12.2.4 Business Transaction Management永続記憶域ディレクトリの再配置

このトピックでは、Business Transaction Managementデプロイメント用永続記憶域ディレクトリのデフォルトの場所を、これらのデプロイメントをホストするコンテナの外側にある場所に変更する方法について説明します。

このトピックには次の各項が含まれており、永続記憶域ディレクトリの再配置に必要な手順を説明します。

- 永続記憶域ディレクトリを再配置する前のバックアップ

- 永続記憶域ディレクトリを再配置するための一般的な手順

- 永続記憶域ディレクトリを再配置するための詳細な手順

12.2.4.1 永続記憶域ディレクトリを再配置する前のバックアップ

永続記憶域ディレクトリの場所を再配置するための手順に従う前に、コンテナのデフォルトの場所にすでに存在する永続記憶域ディレクトリをバックアップすることが非常に重要です。これらのデフォルトの永続記憶域ディレクトリは、初めてBusiness Transaction Managementデプロイメントを起動すると作成され、各コンテナの下にあるセクションにリストされます。後でこれらのディレクトリのコンテンツを各デプロイメントの永続記憶域ディレクトリ用に定義した新しい場所にコピーする必要があります。

既存の永続記憶域ディレクトリのバックアップおよび削除を行わない場合、次回Business Transaction Managementを再起動したときに、新しい永続記憶域ディレクトリの設定がロードされず、使用されないことがあります。デフォルトでは、Business Transaction Managementはデプロイメントの永続記憶域ディレクトリのデフォルトの場所を参照します。新しい場所を設定した後も引き続きデフォルトのディレクトリが存在する場合、新しい場所が認識されない可能性があります。これらの記憶域ディレクトリ内には、ユーザー・プリファレンスも含まれています。Business Transaction Managementは、再起動のたびにこれらのユーザー・プリファレンス・ファイルを読み取ります。

永続記憶域ディレクトリのデフォルトの場所はWAS_install_dir/profiles/profile_name_name/btmstorage/node_name/server_name/*です。

永続記憶域ディレクトリの再配置場所を文書化しておく必要があります。Business Transaction Managementアプリケーションを再デプロイする場合(たとえば、アップグレード時)には、その場所を再度定義する必要があるためです。LogMergerツールを使用して新しい永続記憶域ディレクトリの場所からシステム・ログ・メッセージを収集してその出力をマージする場合は、これらの場所を文書化することも重要です。最も簡単なのは、LogMergerツール用の構成ファイルを作成することです。このファイルは、新しい永続記憶域ディレクトリの場所のドキュメント・ソースとしても機能するためです。LogMergerツールおよびこのツール用の構成ファイルの作成方法の詳細は、11.3項「logMergerユーティリティ」を参照してください。

12.2.4.2 永続記憶域ディレクトリを再配置するための一般的な手順

次の手順では、永続記憶域ディレクトリを再配置するための一般的な手順について説明します。

1. Business Transaction Managementデプロイメントを停止します。

2. 永続記憶域ディレクトリをバックアップし、安全な場所に配置します。

3. 各デプロイメントのweb.xmlファイルで永続記憶域ディレクトリの場所を変更します。

4. 永続記憶域ディレクトリのバックアップ・コピーを新しい永続記憶域ディレクトリの場所に移動します。

注意:
すでに永続記憶域ディレクトリに収集した情報を新しい場所で使用する予定がない場合は、元の記憶域ディレクトリと同じ名前を使用して新しい場所に空の永続記憶域ディレクトリを作成する必要があります。

5. 必要に応じて、永続記憶域ディレクトリを再配置する各デプロイメントをパッケージ化して再デプロイします。

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

7. 新しい場所で新しいシステム出力ログ(logdir)エントリを確認します。

12.2.4.3 永続記憶域ディレクトリを再配置するための詳細な手順

Business Transaction Managementデプロイメントは、次のディレクトリの場所にあります。各デプロイメントのweb.xmlファイルで永続記憶域ディレクトリの場所を編集するためには、これらのデプロイメントの場所を確認する必要があります。

WL_install_dir/user_projects/domains/domain_name/server_name/ .wlnotdelete/extract/server_name_n_n/public/btmstorage/*

たとえば、btmcentralデプロイメントは次のディレクトリにあります。

WL_install_dir/user_projects/domains/domain_name/server_name/ .wlnotdelete/extract/server_name_btmcentral_btmcentral/public/btmstorage/btmcentral

永続記憶域ディレクトリを再配置するには:

1. Business Transaction Managementデプロイメントを停止します。

2. 現在のデフォルトの永続記憶域ディレクトリにあるコンテンツをバックアップし、安全な場所に配置します。

3. 各デプロイメントのweb.xmlファイルで永続記憶域ディレクトリの場所を変更します。

1. 記憶域ディレクトリを変更するデプロイメントの展開済warファイルがある場所を特定します。

2. 展開済warファイルから、テキスト・エディタまたはXMLエディタでデプロイメントの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>

注意:
永続記憶域ディレクトリの名前は変更しないでください。ディレクトリへのパスのみが変更可能です。

例:

- 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. 新しい場所に新しい空の永続記憶域ディレクトリを作成するか(最初から始める場合)、または元の永続記憶域ディレクトリのバックアップ・コピーを新しいディレクトリの場所に移動します。

5. 必要に応じて、永続記憶域ディレクトリを再配置する各デプロイメントを次のようにアンデプロイしてから再デプロイします。

注意:
システム・デプロイメントを再パッケージ化するときは、デプロイメントに関連付けられたマニフェスト・ファイルを必ず含めてください。このファイルにはデプロイメントに必要な重要な情報が含まれているためです。

1. 編集したweb.xmlファイルが含まれている新しいデプロイメントを新しいアプリケーションのwarファイルにパッケージ化します。

2. WebLogic Consoleを使用して既存のデプロイメントをアンデプロイします。

3. WebLogicサーバーを停止し、元の永続記憶域ディレクトリを削除します。

注意:
デフォルトの場所から永続記憶域ディレクトリを削除する必要があります。デプロイメントは、デフォルトの場所で永続記憶域ディレクトリを検出すると、新しいディレクトリの場所を無視します。

4. WebLogicを再起動し、WebLogic Consoleを使用して新しいシステム・デプロイメントを再デプロイします。

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

7. 新しい場所で新しいシステム出力ログ(logdir)エントリを確認します。
この時点で、各デプロイメントのweb.xmlファイルに定義した永続記憶域ディレクトリの場所にデータが書き込まれます。コンテナの起動時に、新しいシステム・サービス・ログ・ファイル(logdir)とその他のディレクトリが新しい場所に作成されたことを確認します。

logMergerツールを使用してシステム・サービス・ログをマージする場合は、ログ・ファイルをマージするときに新しい永続記憶域ディレクトリの場所を参照する必要があります。

12.3 Business Transaction Managementシステムのセキュリティ

この項では、Business Transaction Managementシステムのセキュリティの管理に役立つ情報を提供します。この項の内容は次のとおりです。

- 認証およびロール・マッピング

- Business Transaction Managementアプリケーションのユーザー・ロール

12.3.1 認証およびロール・マッピング

Business Transaction Managementは、認証およびユーザーへのロールの関連付け用にデプロイされているWebLogicサーバーを利用します。デフォルトでは、認証は管理コンソールに対して有効です。認証を無効にするには、現在使用中のアプリケーション・サーバーに適した任意のツールまたはプロシージャを使用します。

注意:
管理コンソールにログインするには、btmAdmin、btmUser、btmObserverのBusiness Transaction Managementユーザー・ロールの1つ以上にマップされている資格証明を使用する必要があります。

認証を無効にした場合も、引き続き管理コンソールのユーザーがログインする必要があります。ただし、任意のユーザー名を使用してログイン可能であり、パスワードを指定する必要はありません。ナビゲータ、フィルタ、列セットに対する編集などすべてのUIパーソナライズは、プリファレンスとして格納され、ユーザー名に関連付けられることに注意してください。

このトピックでは、サポートされているアプリケーション・サーバーがどのようにユーザーを認証して、Business Transaction Managementアプリケーション・ロールにマップするかを説明します。

12.3.1.1 初期アプリケーション・ロール・マッピングのサマリー

Business Transaction Managementロール

WebLogicグループ

btmAdmin

WebLogic Administrators

btmUser

WebLogic Operators & Monitors

btmObserver

Everyone

btmInspector
(ロール名は単数形で、グループ名は複数形であることに注意してください。)

btmInspectors

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

12.3.2 Business Transaction Managementアプリケーションのユーザー・ロール

Business Transaction Managementは、ロールを使用してユーザー・インタフェースの様々な部分へのアクセスを認可します。

12.3.2.1 プライマリ・ロール

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

btmAdmin: このロールを持つユーザーには、すべての権限が付与されます。このようなユーザーは、機密プロパティの表示と作成、すべてのメッセージ・コンテンツの表示など、Business Transaction Managementコンソールが備えるすべてのツールおよび機能を使用できます。

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

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

注意:
管理コンソールでのすべての移動および表示は、すべてのプライマリ・ロールで可能です。ただし、ロールによっては特定のメニューとメニュー項目、およびそれらに関連付けられたツールにアクセスできません。

12.3.2.2 補助ロール

プライマリ・ロールの他、Business Transaction Managementには補助ロールが定義されています。補助ロールにより、特定のユーザーに割当て可能な追加の権限が提供されます。たとえば、あるユーザーにメッセージ・コンテンツへのアクセスは許可するものの、フル管理権限は付与しない場合があります。これを実現するために、ユーザーにbtmUserのプライマリ・ロールおよびbtmInspectorの補助ロールを割り当てることができます。補助ロールは次のとおりです。

btmInspector: このロールを持つユーザーは、メッセージ・コンテンツを表示し、プロパティ(機密プロパティを含む)を表示および作成できます。

注意:
btmAdminロールは、btmInspectorのすべての権限を持っています。

12.4 Business Transaction Managementのバックアップおよびリストア

次の各項では、システムのバックアップとリストアの方法について説明します。トピックは次のとおりです。

- バックアップ処理とリストア処理について

- Business Transaction Managementのバックアップ

- Business Transaction Managementのリストア

- データ記憶域のリファレンス

12.4.1 バックアップ処理とリストア処理について

Oracle Business Transaction Managementは、大量のデータを格納します。このデータは、システムの構成、現在監視中の対象、および監視対象アプリケーションの現在と過去の状態に関するものです。このデータのいずれもシステムの運用に必要です。なんらかの事態が発生してこのデータが消失または破損した場合、システムは想定どおりに実行できなくなります。このような理由から、システムのデータのバックアップを作成し、このデータをリカバリできることが重要です。

次の様々な理由でBusiness Transaction Managementをバックアップすることが必要になります。

- 予期しない出来事からのリカバリを可能にする定期的なバックアップ

- 新しいスフィアに移行する前

- Business Transaction Management環境でアプリケーション・サーバーをアップグレードする前またはアプリケーション・サーバーを追加する前

- 新しいバージョンのBusiness Transaction Managementをインストールする前

この項では、バックアップおよびリカバリの一般的なガイドラインを示し、定義した処理をテストするためのマイルストンを提案します。データをバックアップしてチェックポイントを作成する頻度は、アプリケーションのライフサイクル・ステージおよびビジネス要件に全面的に依存します。

Business Transaction Managementのバックアップおよびリストアには、ホストしているアプリケーション・サーバーとその構成設定のバックアップおよびリカバリは含まれていません。含まれていないものには、JVM設定やJavaシステム・プロパティなど、Business Transaction Managementが正しく機能するために必要なものもあります。アプリケーション・サーバーとその構成をバックアップするための処理はすでに用意されています。

12.4.1.1 バックアップの前に

Business Transaction Managementは複雑な環境で動作します。そのため、バックアップする前に、Business Transaction Managementコンポーネントを分離できることと、バックアップ手順とリカバリ手順の影響を受ける可能性がある他のシステムを特定できることを確認することが重要です。次のような問題について検討します。

- データベースがBusiness Transaction Management以外のコンポーネントと共有されている場合があります。問題がデータベース自体の障害である場合を除き、Business Transaction Managementで使用されるデータベース・インスタンスのみをリストアすることが重要です。

- リカバリは他のシステムに影響を及ぼす可能性があります。たとえば、Business Transaction Managementが他のアプリケーションとJDBCドライバを共有している場合、リカバリによってドライバが以前のバージョンにリストアされ、それが原因でそのドライバを使用している他のアプリケーションで障害が発生することがあります。

12.4.1.2 バックアップ手順とリカバリ手順のテスト

リカバリを試し、他の問題を発生させることなくシステムを目的の状態に戻すことができることを確認することにより、バックアップ手順を定期的にテストしてください。バックアップ手順に関する問題を特定して解決することにより、リカバリが重要になったときにリカバリを正常に完了できるようになります。バックアップ検証チェックリストには、次の事項を含めてください。

- データベースとファイル・システムの構造、および権限が想定どおりであること

- Business Transaction Managementが機能し、想定どおりの状態であること(コンソールにすべてが順調であり、サービスにアクセス可能であり、トラフィックが正常に流れていることなどが表示される)

- 同じリソースを共有するどのアプリケーションも悪影響を受けていないこと

12.4.2 Business Transaction Managementのバックアップ

この項では、Business Transaction Managementデータの編成方法、各タイプのデータのバックアップ方法およびバックアップに関連するタイミングの問題について説明します。

12.4.2.1 Business Transaction Managementデータの編成方法

次の図に、多種多様なBusiness Transaction Managementデータおよびこのデータを利用するBusiness Transaction Managementシステム・サービスを示します。

この図では、データのバックアップの基本原理は次のとおりです。

- データベースに含まれているすべてのデータは、データベースのバックアップによってバックアップされます。

- ファイルまたはディレクトリに含まれているすべてのデータは、btmstorageディレクトリのバックアップによってバックアップされます。このディレクトリは、Business Transaction Managementシステム・サービスまたは監視の1つがデプロイされているあらゆるホストに存在します。自分のサーバーでのこのディレクトリの場所は、12.4.2.2項「Business Transaction Managementデータのバックアップ」に指定されています。

この項では以降、前掲の図に示した要素について詳しく説明します。バックアップおよびリカバリを実行するのみの場合、このレベルまで詳しく知る必要はありません。しかし、この詳細はBusiness Transaction Managementで使用されているリソースのトラブルシューティングおよび理解に役立つ場合があります。必要に応じて、12.4.2.2項「Business Transaction Managementデータのバックアップ」までスキップできます。

図に示すように、Business Transaction Managementは複数のシステム・サービスで構成されています。

- Business Transaction Managementの操作全体およびそのメンバー・サービスの調整を担当するスフィア

- パフォーマンス測定の収集を担当するSLMサービス

- トランザクション管理を担当するExMサービス

- オブザーバからのデータの収集を担当するモニター・エージェント

これらの各サービスは、システムの構成を指定し、現在監視中の対象を表し、監視対象アプリケーションの状態を記録するというデータに依存しています。このデータは、図に示された3つのカテゴリにグループ化できます。

- 定義メタデータは2か所に格納され、次の情報が含まれています。
スフィア・データベースには、Business Transaction Managementと監視対象ユーザー・システムを説明するデータが含まれています。それには、ユーザーのアプリケーション、その監視に使用されるポリシー、トランザクション定義の説明などが含まれています。

モニター・エージェント構成ファイルには、各ユーザー・エンドポイントが監視中かどうか、およびその方法について説明するデータが含まれています。

- 操作データはBusiness Transaction Managementがユーザー・アプリケーションについて収集する情報で、パフォーマンスと行動のメトリック、ログ・メッセージ、トランザクション・インスタンスおよび生成されたアラートがあります。この情報は図に示された測定、トランザクション、エージェント・メッセージ・ログの各データベースに格納されます。

- システム構成データはBusiness Transaction Managementの基本的な動作を制御するものであり、接続先のデータベース、コンテナがスフィアへの接続に使用するアドレス、デフォルトのGUI表示とレイアウトがあります。この情報は、初期構成データ、GUIカスタマイズ、設定データ、コンテナ登録、その他の構成ファイルなど様々な構成ファイルに保存されます。

12.4.2.2 Business Transaction Managementデータのバックアップ

Business Transaction Managementのバックアップは非常に簡単です。データベースに含まれているデータをバックアップするには、それぞれのデータベースをバックアップします。ファイルまたはディレクトリに含まれているデータをバックアップするには、btmstorageディレクトリをバックアップします。

btmstorageディレクトリは、Business Transaction Managementシステム・サービスまたは監視の1つが次の場所にデプロイされているあらゆるホストに存在します。

WebLogic_InstllDir/user_projects/domains/MyDomain/servers/MyServer/btmstorage

データベースおよびbtmstorageディレクトリのバックアップが終了すると、バックアップ処理は完了です。

一般に、データのサブセットのみが破損または消失した場合でも、すべてのデータをバックアップし、リカバリすることをお薦めします。ただし、Business Transaction Managementで使用されている個々のコンポーネントをさらに詳しく知りたい場合は、12.4.4項「データ記憶域のリファレンス」を参照してください。

12.4.2.3 バックアップのタイミング

バックアップのタイミングは重要です。データベースおよびbtmstorageディレクトリは、可能なかぎり近いタイミングでバックアップしてください。可能な場合には、次のガイドラインに従います。

1. 可能な場合にはシステムを停止します。

2. btmstorageディレクトリをバックアップします。

3. 最新のスフィア・データがあるデータベースをバックアップします。

12.4.3 Business Transaction Managementのリストア

Business Transaction Managementをリストアする目的は、他の問題を発生させることなく目的の状態に戻すことです。この処理を開始する前に、リストアしようとしているBusiness Transaction Managementシステムについて完全かつ正確な情報を持っていることを確認します。

Business Transaction Managementをバックアップ元と同じ環境にリストアするものと想定しています。異なる環境にリカバリする必要がある場合(たとえばハードウェア障害の場合)は、リストアするマシンのホスト名をその障害が発生したマシンのホスト名に(オペレーティング・システム・レベルで)変更する必要があります。また、新しいマシンにホストされているBusiness Transaction Managementサービスが古いマシンと同じポートで動作することを確認する必要もあります。その場合、サービスを中断することなく新しいマシンにリカバリできます。

リストア処理では、バックアップ処理によって作成された最後のチェックポイントにシステム全体がリカバリされます。

注意:
リストア後、データベース・スキーマおよびファイル・システムにはバックアップ時点の状態が反映されている必要があります。これを確実にするため、リストアする前に、既存のデータベースおよび記憶域ディレクトリが完全にクリーンであることを確認してください。2つの記憶域の場所にあるデータは様々な方法で接続されるため、どちらかがバックアップされたデータよりも新しいデータを保持していると、問題が発生することがあります。このため、既存のbtmstorageディレクトリにバックアップをリストアしないでください。ほとんどのデータベース・リストアはこの問題に対処していますが、ご使用のデータベースも対処していることを確認してください。

リストア処理は、次の2つの手順で構成されています。

- データベースをリストアします。

- システム・サービスまたはモニターをホストする各サーバーにbtmstorageディレクトリをリストアします。

なんらかの原因でインストールしたインスタンスが損傷または破損したためにBusiness Transaction Managementソフトウェア自体に損傷がある場合は、次の手順を実行することをお薦めします。

1. Business Transaction Managementソフトウェアを再インストールします。

2. システム・サービスまたはモニター・エージェントをホストする各サーバーにbtmstorageディレクトリをリストアします。

3. データベースをリストアします。

注意:
損傷がEAR、WARまたはJARファイル自体にのみ影響を及ぼす場合、必要なのはBusiness Transaction Managementソフトウェアの簡単な再インストールを実行することのみです。

12.4.4 データ記憶域のリファレンス

次の表に、Business Transaction Managementコンポーネントに関する追加の詳細を示します。この詳細は、各コンポーネントの役割を理解する場合や、特定の情報を探す場合に役立ちます。

データ

内容

バックアップ手順

スフィア・データベース

Business Transaction Managementシステム、監視およびロギング・ポリシー、トランザクション定義、ユーザー・アプリケーション定義の説明。

Oracle Databaseのバックアップ機能を使用してバックアップを作成します。

監視状態

各ユーザー・エンドポイントが監視中かどうかとその方法に関する情報。
このデータはスフィア・データベースにもレプリケートされますが、モニター・エージェントの構成ファイルがこの情報のマスター・ソースとみなされます。監視状態データはスフィア・データベースをバックアップするときにバックアップされ(そしてスフィア・データベースをリストアするときにリストアされます)が、そのコピーはカウントされません。また、元の監視状態を取得せずにエージェントをリカバリした場合、エンドポイントは最終的に監視対象外になります。

btmstorageディレクトリをバックアップします。

操作データ

Business Transaction Managementがユーザー・アプリケーションに関して収集する情報。このデータは、パフォーマンス・マネージャのデータベース、トランザクション・マネージャのデータベースおよびメッセージ・ログ・データベースに格納されます。これらは同じ物理的なデータベースに存在する場合もありますが、個別のデータベースであるとみなされます。

Oracle Databaseのバックアップ機能を使用してバックアップを作成します。

初期構成データ

デフォルトでは、Business Transaction Managementのユーザーの初期構成から収集された情報は、次のディレクトリのessentialConfiguration.xmlファイルに保存されます。
WebLogic_InstallDir/user_projects/domains/MyDomain/servers/MyServer/btmstorage/globalPreferences

WAS_InstallDir/profiles/MyProfile/btmstorage/MyNode/MySrvr/DeployEarFileName/globalPreferences

この情報には、Business Transaction Managementで使用されているデータベースの場所、デプロイメント資格証明、データベース・タイプなどが含まれています。

btmstorageディレクトリをバックアップします。

UIのカスタマイズ

管理者が行ったカスタマイズと、ユーザーが作成したプリファレンスおよびビューに関する情報。デフォルトでは、この情報は次のディレクトリ内のファイルに格納されます。
WebLogic_InstallDir/user_projects/domains/MyDomain/servers/MyServer/btmstorage/btmui/userPreferences

WAS_InstallDir/profiles/MyProfile/btmstorage/MyNode/MySrvr/DeployEarFileName/btmui.war/userPreferences

btmstorageディレクトリをバックアップします。

モニター登録

システムに追加したモニター・エージェントに関する登録情報。

btmstorageディレクトリをバックアップします。

システム・サービス設定

各Business Transaction Managementシステム・サービスの設定データ。

btmstorageディレクトリをバックアップします。

その他のスクリプトおよび構成

Business Transaction Managementの構成中に、様々な構成スクリプトを作成する場合があります。たとえば、通知サービスに認識されている電子メール・サブスクリプションを構成するスクリプトや、ベースライン・パフォーマンス値を設定するスクリプトなどです。

btmstorageディレクトリをバックアップします。
他の場所にスクリプトを格納した場合は、そのディレクトリもバックアップします。

12.5 データの移行

この項では、ある環境から別の環境にデータを移行するために必要な手順の概要を説明します。たとえば、テスト環境から本番環境に移行するときには、これを行うことが必要になる場合があります。

ある環境から別の環境にデータを移行するには、次の手順を実行します。

1. 常に、データを移行する前にシステムをバックアップします。システムのバックアップについては、12.4項「Business Transaction Managementのバックアップおよびリストア」を参照してください。

2. 次のように、CLIコマンドを使用してデータをエクスポートします。エクスポートの順序は重要ではありません。

- exportProfileコマンドを使用して、プロパティ定義をエクスポートします。まだプロパティを定義していない場合は、これを行う必要はありません。

- exportTransactionDefnsコマンドを使用して、トランザクション定義をエクスポートします。

- ビジネス・オブジェクトの自動作成を使用しない場合は、exportBusinessObjectsコマンドを使用してコンシューマ・データをエクスポートします。

- 新しい環境で使用するために停止時間スケジュールを作成した場合は、exportSchedulesコマンドを使用してそれらをエクスポートします。

- exportPoliciesコマンドを使用して、ポリシー定義をエクスポートします。
必要な操作は、ユーザー定義のポリシーをエクスポートすることのみです。これはほとんどの場合SLAポリシーです。システム・ポリシーまたはトランザクション用に作成されたポリシーはエクスポートしないでください。システム・ポリシーは環境の構成に関連しており、新しい環境では異なる可能性があります。トランザクション用にシステムが生成したポリシーは、トランザクション定義をインポートすると自動的に再作成されます。

3. 新しいBTM環境をインストールし、構成します。
新しいシステムでは、エクスポートしたトランザクションの作成に使用した本番環境のあらゆるものを監視できることを確認してください。トランザクションに含まれているサービスがわかっている場合は、BTMコンソールを使用して必要なサービスを探し、そのサービスがすでに監視対象になっていることを確認できます。

4. CLIコマンドを使用して、次に示す順序でデータをインポートします。

1. エクスポート済のプロファイルがある場合は、importProfileコマンドを使用します。

2. importTransactionsDefnsコマンドを使用して、トランザクション定義をインポートします。
インポートが失敗した場合は、トランザクションに含まれているサービスがまだ監視されていないことが原因である可能性があります。さらに多くのトラフィックを実行してから、再度インポートを試すことができます。

3. 必要に応じてimportBusinessObjectsコマンドを使用します。

4. 必要に応じてimportSchedulesコマンドを使用します。

5. importPoliciesコマンドを使用して、ポリシー定義をインポートします。

この時点でトランザクションは新しい環境で機能します。ある程度のトラフィックを実行して、トランザクション監視が想定どおりに機能していることを確認してください。

12.6 ロード・バランサの設定

ロード・バランサを設定すると、Business Transaction Managementでトラフィックのフローを正しくモデル化し、Business Transaction Managementコンソールからロード・バランサの管理コンソールにアクセスできます。

この項では、F5デバイスを設定して、1つのオブザーバから複数のモニターにメッセージのロード・バランシングを行う方法について説明します。内容は、次のとおりです。

- ロード・バランサの設定

- レプリケート対象モニターを使用するためのF5デバイスの構成

12.6.1 ロード・バランサの設定

複数のコンテナにサービスをデプロイした場合、Business Transaction Managementはこれらのレプリケートされたエンドポイントが同じサービスの一部であると認識し、これらのレプリケートされたエンドポイントにメッセージをルーティングするロード・バランサの存在を推察できます。つまり、Business Transaction Managementはロード・バランサ自体ではトラフィックのフローを監視しない場合でも、依存性ダイアグラムでトラフィックのフローを正しくモデル化できます。ただし、ユーザーの助けがないと、Business Transaction Managementは推察したロード・バランサに関する詳細な情報を提供できません。ロード・バランサを設定すると、Business Transaction Managementに情報が提供されて次のことを実行できるようになります。

- 管理コンソールにロード・バランサに関する情報を提供します。たとえば、ロード・バランサの表示名やロード・バランサに関連付けられたベンダーなどです。

- ロード・バランサをホストしているデバイスを識別します。

- ロード・バランサの管理コンソールに容易にアクセスします。

- ロード・バランサ・デバイスのライフサイクル・フェーズおよびそのデバイス内に作成されるすべてのエンドポイントを指定します。

ロード・バランサの設定は、その登録から始まります。ロード・バランサを登録するには、CLIコマンドregisterDeviceを使用するか、または管理コンソールを使用します。場合によっては、ロード・バランサへのエントリ・ポイントを指定し、メッセージのルーティング先に対応するターゲット・エントリ・ポイントを定義することが必要になる場合もあります。

この項では、ロード・バランシングに関連するいくつかの基本的な用語、Business Transaction Managementでサポートされているデバイス、さらに次のユーザー・タスクについて説明します。

- ロード・バランサの登録

- ロード・バランサに関する情報の変更

- ルーティング関係を示すエントリ・ポイントの追加

- ロード・バランサの登録解除

Business Transaction Managementでは、様々なロード・バランシング・デバイスがサポートされています。F5ロード・バランサに対して最大のサポートが提供されますが、他のハードウェア・ロード・バランサおよびソフトウェア・ロード・バランサを認識し、モデル化することもできます。

12.6.1.1 基本的な用語

次の図に、ロード・バランサを使用してメッセージAおよびBを3つのレプリケート・エンドポイント(E1、E2、E3)にルーティングする様子を示します。マークされた要素、つまりルーティング・エントリ・ポイントとターゲット・エントリ・ポイントに注意してください。ロード・バランサは、ルーティング・エントリ・ポイントでメッセージを受信してターゲット・エントリ・ポイントに転送します。ロード・バランサを登録した後、次の項の説明に従ってエントリ・ポイント情報を指定することが必要になる場合があります。

12.6.1.2 サポートされているデバイス

Business Transaction Managementでは、F5デバイス、その他のハードウェア・デバイス、ソフトウェア・ロード・バランサの3種類のロード・バランサを操作できます。Business Transaction Managementでメッセージ・トラフィックのモデル化を行うために必要な作業は、個々の事例によって異なります。

- Business Transaction Managementは、F5デバイスに関するほとんどの情報を認識しており、1つの登録手順のみで必要な情報を導出できます。Business Transaction Managementは、メッセージのルーティングにおけるF5のロールの全体像を示すために追加の検出パスを実行する場合があります。

- ハードウェア・ロード・バランサの場合、Business Transaction Managementは通常、監視対象メッセージのHTTPホスト・ヘッダーの情報に基づいて自動的にルーティング・エントリ・ポイントを検出し、モデル化できます。ただし、デバイスを明示的に登録すると(CLIコマンドregisterDeviceまたは管理コンソールを使用)、Business Transaction Managementでデバイスの場所およびその他の属性に関する情報を表示できます。
どのデバイスも登録しない場合、Business Transaction Managementではデフォルトのロード・バランサを自動的に登録し、このデバイスによるメッセージの流れをモデル化できます。この場合も、デフォルトのロード・バランサの「プロファイル」ページを編集して名前、ベース・アドレス、管理UIおよびベンダーを指定できます。

監視対象メッセージがHTTPホスト・ヘッダーで元の受信者(ロード・バランサ)に関する情報を伝送しない場合は、次に説明するように、ソフトウェア・ロード・バランサの場合と同じくデバイスを登録し、ルーティング・エントリ・ポイントおよびターゲット・エントリ・ポイントを指定する必要があります。

- バックエンド・サーバーへのHTTP接続を別途確立する(単にHTTPメッセージを転送するのではなく)ソフトウェアによって実装されたロード・バランサの場合、Business Transaction Managementでルーティング関係が正しくモデル化されるようにルーティング関係を記述する必要があります。このためには、デバイスを登録し、ロード・バランサのエントリ・ポイントを追加し、メッセージのルーティング先に対応するターゲット・エントリ・ポイントを指定する必要があります。

12.6.1.3 デフォルトのロード・バランサ

デフォルトのロード・バランサは、最初に登録されたロード・バランサまたはsetDefaultLoadBalancerコマンドを使用してデフォルトに設定したロード・バランサです。

コール元のサービスは、ルーティング・エントリ・ポイントを使用してロード・バランサと通信します。Business Transaction Managementは、メッセージを監視してルーティング・エントリ・ポイントを検出します。ロード・バランサがまだ登録されていない場合、Business Transaction Managementはデフォルトのロード・バランサを作成し、検出したルーティング・エントリ・ポートを割り当てます。新たに検出されたルーティング・エントリ・ポイントは、登録済F5ロード・バランサに属している場合を除いて、デフォルトのデバイスの一部としてモデル化されます。

自動的に作成されたデフォルトのロード・バランサのプロファイルを編集して追加で詳細な情報を提供したり、必要に応じてデフォルトのロード・バランサを登録解除し、実際のロード・バランサを明示的に登録することもできます。

12.6.1.4 管理コンソールを使用したロード・バランサの登録

CLIコマンドregisterDeviceまたはコンソールを使用して、ハードウェア・ロード・バランサまたはソフトウェア・ロード・バランサを登録できます。

登録完了後、ナビゲータで「エクスプローラ」→「デバイス」を選択すると、デバイスがサマリー・ペインにリストされます。

コンソールを使用してハードウェア・ロード・バランサまたはソフトウェア・ロード・バランサを登録するには:

1. 「管理」→「登録」→「デバイス」を選択し、次に「F5ネットワーク」を選択してF5ロード・バランサを登録するか、または「その他」を選択してその他のロード・バランサを登録します。

2. 次のダイアログで、次の表に示すように値を指定します。

フィールド

説明

ベンダー

F5では編集不可。他のロード・バランサでは必須。
手順1で「F5ネットワーク」を選択した場合、このフィールドは「F5」という編集不可の値に設定されます。

「その他」を選択した場合は、ロード・バランサのベンダーの名前を指定します。このフィールドは単に説明を目的としたものです。任意の値(「F5」を除く)を指定できます。指定した値は、管理コンソールに表示されます。

デバイス名

必須。
ロード・バランサのわかりやすい名前を指定します。この名前は、管理コンソールに表示されます。

注意

オプション。このロード・バランサの性質または目的を思い出せるようにノートを追加します。

ライフサイクル・フェーズ

ドロップダウン・リストからライフサイクル・フェーズを選択します。使用可能な値は、「非推奨」、「開発」、「本番」、「ステージング」および「テスト」です。これらは大文字/小文字が区別されません。

構成URL

必須であり、F5を選択した場合にのみ表示されます。
次の書式でF5コンソールのURLを指定します。

https://managementPortIP/iControl/iControlPortal.cgi

managementPortIPを適切なホスト名およびポート番号に置き換えます。このURLは通常、iControl/IControlPortal.cgiで終了します。

ユーザー名とパスワード

この値は必須であり、「F5ネットワーク」を選択した場合にのみ表示されます。
F5ロード・バランサのアカウントのユーザー名およびパスワードを指定します。Guestのユーザー・ロールで十分な権限が与えられます。

CLIコマンドencryptPasswordを使用してパスワードを暗号化できます。たとえば、次に示す例のようにします。

btmcli encryptPassword -password "myPassword"

ベース・アドレス

必須であり、「その他」を選択した場合にのみ表示されます。
ロード・バランサのURLのベース・アドレスを指定します。たとえば、次のようにします。

https://myLoadBalancer:443/

管理用URL

オプションであり、「その他」を選択した場合にのみ表示されます。
ロード・バランサのHTML管理コンソールのURLを指定します。このURLへのリンクはBusiness Transaction Managementの管理コンソールに表示され、ロード・バランサのコンソールに簡単にアクセスできます。

Business Transaction ManagementがURLを自動的に取得するため、このフラグはF5ロード・バランサでは必要ありません。

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

4. 必要に応じて、12.6.1.6項「ルーティング関係を示すエントリ・ポイントの追加」の説明に従って、ルーティング・エントリ・ポイントおよびターゲット・エントリ・ポイントを割り当てます。

12.6.1.5 ロード・バランサに関する情報の変更

すでに登録したデバイスまたはデフォルトのデバイスに関する情報を変更できます。

デバイスに関する情報を変更するには:

1. ナビゲータから「エクスプローラ」→「デバイス」を選択します。

2. サマリー領域で、属性を指定または編集するデバイスを選択します。

3. 「変更」→「プロファイルの編集: deviceName」を編集します。

4. 次のダイアログで、関心のあるフィールドを(デバイス登録時の説明に従って)変更します。

5. 「適用」をクリックします。

12.6.1.6 ルーティング関係を示すエントリ・ポイントの追加

ほとんどの場合、Business Transaction Managementはメッセージ・トラフィックを監視し、メッセージ・ヘッダーから宛先情報を読み取ることにより、ルーティング関係を自動的に検出してモデル化します。ただし、監視対象メッセージがHTTPホスト・ヘッダーで元の受信者(ロード・バランサ)に関する情報を伝送しない場合は、ロード・バランサへのルーティング・エントリ・ポイントを手動で作成する必要があります。また、ターゲット・エントリ・ポイントを追加してメッセージのルーティング先を示す必要もあります。

ルーティング関係を指定しないと、Business Transaction Managementは連続する依存性フローを描画できなくなります。トランザクションの場合にも、手動キーを使用して関連するサービスをリンクすることにより、これらの非結合フローを接続できます。

ルーティング・エントリ・ポイントおよびターゲット・エントリ・ポイントを追加するには:

1. ナビゲータから「エクスプローラ」→「デバイス」を選択します。

2. サマリー領域で、ルーティング関係を明確化するデバイスを選択します。

3. 「作成」→「エントリ・ポイント: deviceName」を選択します。

4. 次のエントリ・ポイントの作成ツールで、次の情報を指定します。--「ホスト先」セクションで、ロード・バランサが監視メッセージを受信するIPアドレスおよびポート番号を指定します(HTTPポート)。--「ターゲット・エントリ・ポイントを追加」をクリックし、ドロップダウン・リストから宛先を選択します。各宛先は、ロード・バランサがメッセージをルーティングしているターゲット・エントリ・ポイントを参照します。使用する可能性がある宛先ごとにこれを行ってください。注意: ドロップダウン・リストには、ルーターが使用しているよりも多くのエントリ・ポイントがあります。その一部は、別のロード・バランサがメッセージを送信しているアドレスである可能性があります。(基本的に、ドロップダウン・リストにはスフィアに認識されているすべてのエントリ・ポイントが表示されます。)

5. 「適用」をクリックします。

12.6.1.7 ロード・バランサの登録解除

ロード・バランサの登録解除には、管理コンソールのみを使用できます。

ロード・バランサを登録解除するには:

1. ナビゲータから「エクスプローラ」→「デバイス」を選択します。

2. サマリー領域で、登録解除するデバイスの名前を選択します。

3. 「変更」→「deviceName登録の削除」を選択します。

4. 次のダイアログで「削除」をクリックして、削除アクションを確定します。

12.6.2 レプリケート対象モニターを使用するためのF5デバイスの構成

Business Transaction Managementでの監視では、特定のサービスを介してメッセージ・トラフィックを監視するオブザーバと、オブザーバによって取得されたデータを分析して格納するモニターとの間で発生する通信が利用されます。

システムの規模を変更し、システムをフォルト・トレラントにするために、いくつかのレプリケート対象モニター(モニター・グループ)をオブザーバに関連付けることができます。レプリケート対象モニターには、メッセージをオブザーバからモニターにルーティングできるサード・パーティ・ロード・バランサが必要です。この項では、オブザーバから2つ以上のモニターに対してメッセージのロード・バランシングが行われるようにF5デバイスを設定する方法について説明します。

F5の設定を理解するには、オブザーバと単一のモニターとの通信を可能にするメカニズムを確認することが役立ちます。次の図にこれを示します。

図に示すように、オブザーバとモニター間の通信は2つのパスによって行われます。

- オブザーバは、モニターに構成情報を問い合せて、モニターのHTTPポートからその情報を受信します。(構成データの大部分はモニターからオブザーバに流れますが、接続はオブザーバによって確立されます。)このポートは、プラットフォームに応じてAP_NANO_CONFIG_URLというJavaシステム・プロパティまたはAmberPoint:NanoConfigRLというWindowsキーを使用して指定します。図に示されたサンプルのURLは、MyApSvr:8080/apmonitor/agent/agentです。オブザーバは起動するとリクエストをこのURLに送信して構成情報を受け取り、測定内容とその頻度が指示されます。このように、様々な種類の情報に対するニーズの変化に応じてオブザーバを動的に再構成できます。

- オブザーバは、オブザーバ通信ポリシーに指定されているソケット・ポートで測定データをモニターに送信します。デフォルトでは、このポートは36963です。

F5デバイス経由でオブザーバとレプリケート対象モニターとの間に通信を確立する場合、F5デバイスは追加したあらゆるレプリケート対象モニターに対してこの同じ2つの(構成およびデータ)パスを含めるように構成されている必要があります。次の図に、F5デバイスがどのようにオブザーバをレプリケート対象モニターと接続するかを示します。

前述のような体系を確立するには、F5デバイスの構成、Javaシステム・プロパティまたはWindowsキーの設定およびレプリケート対象モニター用オブザーバ通信ポリシーの定義が必要です。

F5デバイスを設定するときは、そのデバイス用の管理コンソールを使用して次のことを行う必要があります。

- オブザーバが構成情報を受け取るために使用するHTTP仮想サーバーを作成します。前掲の図では、これはポート5060で示されています。
接続先のモニターのHTTPポートに対応するメンバー・ポート番号を持つHTTP仮想サーバーにプールを割り当てます。図に示すように、HTTP仮想サーバーのプールにはポート11080および11081が含まれています。

- オブザーバがデータをモニターのソケット・ポートに送信するために使用するソケット仮想サーバーを作成します。前掲の図では、これはポート5061で示されています。接続先のモニターのソケット(データ)ポートに対応するメンバー・ポート番号を持つソケット・サーバーにプールを割り当てます。図に示すように、ソケット仮想サーバーのプールには各ホスト・マシンの36330のポートが含まれています。

AP_NANO_CONFIG_URLというJavaシステム・プロパティまたはAmberPoint:NanoConfigURLというWindowsキーを設定するときは、次のような値を指定する必要があります。

http://10.147.46.152:5060/btmmonitor/agent/agent/

URLの太字の部分をメモします。これは、F5デバイス(ホスト)のIPアドレスと仮想サーバーのHTTPポートです。(これらの値は実際のデプロイメントでは異なります。)

オブザーバ通信ポリシーに指定する値は、次のように、F5デバイスに対して定義されている値に対応しています。

オブザーバ通信ポリシー(ルーターからモニター・グループへ)

F5デバイスの値

ルーターのIPアドレス

F5デバイスのIPアドレス。図ではこれは10.147.46.152になります。

ルーターのポート番号

仮想サーバーのソケット番号。図ではこれは5061になります。

モニターのポート番号

プール・メンバー・ポートの1つ。図ではこれは36630になります。
なんらかの理由で複数のレプリケート対象モニターが同じマシンにある場合、各モニターのポート番号はそれぞれ異なるものになり、モニターごとに異なるオブザーバ通信ポリシーが必要になります。

オブザーバ通信ポリシーを最初に定義し、次にF5を定義するかどうかは重要ではありません。重要なのは、モニターに割り当てられたソケット・ポートがF5デバイスの仮想サーバー・ソケット・プールに定義されたものと対応していることです。

この項では、レプリケート対象モニターをデプロイおよび登録し、モニター・グループを作成するための作業がある程度すでに完了しているものとしています。その方法およびオブザーバ通信ポリシーの定義方法については、『Business Transaction Managementインストレーション・ガイド』を参照してください。

12.7 検出問題の解決

有用な検出構成を作成しようとすると、特にBusiness Transaction Managementを使用する早い段階では何度か繰り返し作業することになる場合があります。プローブを有効にするためのデフォルト設定にあまりにも多くの情報が含まれる場合や、デプロイメントまたはオブザーバ・モニター・トポロジの変更によって情報が冗長になったり誤ったものになる場合があります。システムを再インストールしたり、すべての監視対象エンティティおよび関連するアーティファクトを手動で削除する必要がないようにするために、Business Transaction ManagementにはdeleteAllコマンドが用意されています。このコマンドは、すでに検出されたオブジェクトをトランザクション、プロパティ、登録済サービス、デバイス、コンテナなど関連するアーティファクトとともに削除します。

監視したオブジェクトに関する履歴データなどのデータの不要な損失を防ぐために、このコマンドは慎重に使用してください。このコマンドが最も適しているのは、Business Transaction Managementでの作業を開始し、検出方式を微調整するときです。本番環境では使用しないでください。詳細は、10.11項「deleteAll」を参照してください。

検出構成を微調整し、Business Transaction Managementでしばらく作業した後、引き続き問題が発生する場合があります。サービスを監視できない最も単純な理由は次のとおりです。

- Business Transaction Managementがサービスを表示するほど十分に長くまたは十分に多様にトラフィックが実行されていません。この場合の解決策は、より多くのトラフィックを実行し、可能性のあるすべてのブランチをトラバースしてみることです。

- サービスの監視を担当するプローブがアクティブ化されていません。確認するには、ナビゲータから「管理」→「オブザーバ」を選択し、検出しようとしているサービスのタイプに適したプローブがアクティブであることを確認します。そうでない場合は、オブザーバ通信ポリシーを編集してアクティブ化します。デフォルトでは、JAVAプローブを除くすべてのプローブがアクティブ化されています。JAVAプローブを有効にするには、監視する特定のJavaクラスの名前でJAVAプローブを構成する必要があります。

サービスがレプリケートであるかどうかを決定する場合には、さらに複雑な問題が発生します。サービスおよびエンドポイントを適切に検出して表現する処理では、サービスのコピーが有効なレプリケートを表しているかどうか、逆に言うとWSDL定義が同じではないサービスが同じインタフェースを実際に実装しているかどうかをBusiness Transaction Managementが認識する必要があります。これらの決定は、検出されたWSDLを比較し、システム・サービス・バージョニング・ポリシーで定義されている基準に従うことによって行われます。また、所有権またはアカウントの問題のため、異なるバージョンのサービスを分離またはマージすると効果的である場合もあります。Business Transaction Managementには、レプリケーションおよび重複の問題と、ユーザーのニーズや意図を推測できない事例の解決に使用可能なコマンドおよびツールが用意されています。

この項では、このような問題の概要を説明し、問題の対処に使用するコマンドを紹介します。また、管理コンソールからアクセスする「エンドポイントの明確化」ツールを使用して解決できる検出問題もあります。この項の内容は、次のとおりです。

- サービス・バージョニング・ポリシーの変更

- レプリケーションの問題の解決

- 重複の問題の解決

- コンソールを使用したエンドポイントの明確化

12.7.1 サービス・バージョニング・ポリシーの変更

デフォルトでは、サービス・バージョニング・ポリシーはBusiness Transaction Managementで新規または変更済のWSDLにどのように対処するかに関するガイドラインを設定します。

- サービスの修飾名、ポート・タイプ名およびポート定義が一致した場合、2つのエンドポイントは同じサービス・バージョンの一部として扱われます。

- 既存のサービスの異なるバージョンを定義するWSDLが検出された場合、登録するエンドポイント位置のホストとポートに基づいて新しいサービス・バージョンが作成されます。

- WSDLの再読取り時に、サービスの修飾名が変更された場合は、以前のエンドポイントが置き換えられるため、すべての測定結果が失われます。

デフォルトのサービス・バージョニング・ポリシーを編集してこれらの基準を強化または緩和することによって、検出問題を未然に防ぐことができる場合があります。ポリシーの変更では不十分な場合、検出結果の修正に使用可能でコンソールからアクセスできる数多くのCLIコマンドと1つのツールがあります。追加情報

デフォルトのサービス・バージョニング・ポリシーを編集するには

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

2. サマリー領域で「サービス・バージョニング・ポリシー」項目をダブルクリックして、詳細領域に現在のバージョニング・ポリシーを表示します。

3. 「変更」メニューから、「定義の編集: サービス・バージョニング・ポリシー」を選択します。

4. 必要な変更を行い、「適用」をクリックします。

12.7.2 レプリケーションの問題の解決

複数のコンテナにサービスをデプロイした場合、Business Transaction Managementは同じサービスがすべてのエンドポイントから参照され、すべてのエンドポイントが1つのインタフェースを共有していると認識できます。したがって、サービス・レベルでレプリケートに関する統計の集約が可能になり、その結果、サービスのすべてのエンドポイントで共有される操作に関してメッセージ・プロパティを定義できます。

同じサービスのレプリケートとして扱われる2つのエンドポイントでは、次のことが必要です。

- 2つのサービスのWSDLは修飾名(ターゲット・ネームスペースと簡単な名前)が同じです。

- エンドポイントには、同じインタフェースが実装されています。

- エンドポイントのサービス・タイプが同じです。

例をあげると、同じ名前を持つユーザーWebサービス、OSBビジネス・サービスおよびOSBプロキシ・サービスは、それぞれのサービス・タイプが異なるため、3つの異なるサービスとして表示されます。

ただし、この情報は決定を下すのに十分でなく、2つのエンドポイントが同じか異なるかをシステムに通知することが必要になる場合があります。次のいずれの場合にも、なんらかの対策を講じるように警告されます。

1. 開発環境で、同じサービスの複数のバージョンが互換性のないまま作成される場合があります。Business Transaction Managementでは、以前のものとは異なって見えるバージョンが検出されると、別のバージョンとして扱われます。その違いが重要でない場合は、mergeServicesコマンドを実行して2つのバージョンを1つにマージできます。

2. ローリング・アップグレードであるために、すべてのサーバーがアップグレードされるまで、パラレル・バージョンが一時的に共存することが必要になる場合があります。この場合、Business Transaction Managementでは新しいサービス・バージョンは生成されませんが、アラートは生成されます。それにより、アップグレードされたエンドポイントを必要に応じて新しいサービス・バージョンに移動できます。既存のポリシーがアップグレードされたバージョンと互換性がないと、このような状態になる場合があります。moveEndpointsコマンドを使用して、アップグレードされたエンドポイントを新しいサービス・バージョンに移動できます。アップグレードが完了するまでには、すべてのエンドポイントが新しいサービス・バージョンになります。

3. アップグレードが失敗したり不完全であると、意図しなかったバージョン・スキューが発生しますが、これによりサービスの2つの異なるバージョンが存在することになります。2つのバージョンをマージすることも、分離することもできます。

4. 並行アップグレードによってアプリケーションの新しいバージョンがデプロイされ、新しいエンドポイント位置でインタフェースが更新されると、Business Transaction Managementはデフォルトでは新しいサービス・バージョンを生成します。これを受け入れることも、新しいバージョンを古いバージョンとマージしてサービス履歴を保持することもできます。

5. 同じサービスを識別するWSDLの2つのセットは通常はレプリケートとして扱われますが、サービスの様々なインスタンスが各部門によって異なる方法で使用されるため、サービス・バージョン間でエンドポイントを手動で分けることが必要になる場合があります(moveEndpoints)。この場合、新しいレプリケート・エンドポイントが検出されるとBusiness Transaction Managementはアラートを生成します。これにより、そのエンドポイントがどのサービス・バージョンに属しているかを判断できます。

6. サービスの更新後のバージョンをデプロイすると、Business Transaction Managementによって古いバージョンが削除される場合があります。古いバージョンに関連付けられた測定結果を保持する場合は、moveMeasurementsコマンドを使用して測定結果を古いバージョンから新しいバージョンに移動できます。

12.7.3 重複の問題の解決

Business Transaction Managementは、マシン名またはコンテナのリスニング・アドレスを変更した結果または同じホスト名に複数の別名を使用した結果発生した問題を、ユーザーの支援を受けることなく解決しようとします。システムによって推測されたこのような状態への対処方法が誤っている場合、最もよく見られる症状は、実際には1つのみ存在するサービスまたはエンドポイントが重複して検出されることです。次の表に記載されているコマンドを使用して、重複の問題の回避または解決に役立てることができます。

WSDL、サービスまたはエンドポイントの識別子として使用される部分は次のとおりです(次の例の場合)。

http://jbujes-pc.edge.com:8080/Bookmart/Credit/CreditService?wsdl

ベース・アドレスはhttp://jbujes-pc.edge.comです。

ノードはjbujes-pc.edge.comです。

パスはBookmart/Credit/CreditService?wsdlです。

一般に、removeDuplicateEndpoint (またはaddBaseAddressAlias)コマンドを使用すると、必要なすべてが実現されます。つまり、重複が再び発生しないように、重複した項目が削除され、適切な別名が定義されます。ただし、次にあげるコマンドで行われるすべての別名修正では遡って修正されないことに注意してください。つまり、誤ってすでに作成された重複は削除されません。

コマンド

バランシングのコマンド

説明

addBaseAddressAlias

removeBaseAddressAlias

2つのベース・アドレスが同じであることを認識するようにシステムに伝えます。これにより、エンドポイントが重複して検出されるのを防ぐことができます。

addNodeAlias

removeNodeAlias

2つのノード・アドレスが同じであることを認識するようにシステムに伝えます。

addPathAlias

removePathAlias

特定のエンドポイントまたはWSDLアドレスでは2つのパスが同じであることを認識するようにシステムに伝えます。

listNodeAliases

なし

現在のノードの別名をリストします。

removeDuplicateEndpoint

なし

パスは同じであるもののホスト名が異なる2つのエンドポイントが検出されました。このコマンドを実行すると、重複が削除され、欠落していた別名が追加されるため、今後の検出では重複するエンドポイントが再作成されることはありません。

removeNode

なし

ノードとその別名に関するすべての情報を削除します。ノードの削除は、様々なマシンの別名が混在しているために、ノードをプルーニングするかシステムを再インストールするかという選択に直面している場合を除いて、通常必要ない操作です。

この他に重複が見られるのは、2つのエンドポイントが同じURLを共有し、それらの説明が記述されているWSDLで同じポート名が指定されている場合です。デフォルトでは、ポート名はわかりやすい名前として使用されます。わかりやすい名前は一意である必要はありませんが、一意のエンドポイントを参照する必要があるコマンドではわかりやすい名前ではなくエンドポイントURL (および場合によってはその他の特性)を指定する必要があります。renameEndpointコマンドを使用して(あるいは単に目的のエンドポイントを選択し、その「プロファイル」タブでわかりやすい名前を変更して)、エンドポイントを相互に区別できます。

12.7.4 コンソールを使用したエンドポイントの明確化

「エンドポイントの明確化」ツールを(コンソールから)使用して、次のことを行うことができます。

- サービスのマージ: ソース・サービスを指定のターゲット・サービスにマージします。

- エンドポイントの移動: ソース・エンドポイントを既存または新規のサービスに移動します。

- 重複するエンドポイントの削除: ターゲット・エンドポイントの重複であるソース・エンドポイントを削除します。

「エンドポイントの明確化」ツールを使用するには:

1. ソース・サービスまたはソース・エンドポイントを選択し、「管理」→「エンドポイントの明確化」を選択します。「エンドポイントの明確化」ツールがコンソールに表示されます。ツールは主に3つの領域で構成されています。ソースとターゲットを比較する領域、使用可能なアクションをリストする領域および実際に実行する前にアクションの影響をプレビューできる領域です。
ソースのドロップ・リストには、システムでの重複という内部評価に基づいて可能性のあるすべてのソースが含まれています。最上部に示されるサービスまたはエンドポイントは、ツールを開いたときに選択したものです。必要に応じて別のものを選択できます。

ターゲットのドロップ・リストには、可能性のあるすべてのターゲットが含まれており、ソースに対して選択した項目が指定されています。

ドロップ・リストの下に、選択したソースおよびターゲットの基本情報が表示されます。アイコン(等しい/等しくない)は、ソースとターゲットの要素が同じかどうかを示します。WSDLのリストでの違いを表示するには、リンクをクリックしてWSDLの内容を表示します。

2. ドロップ・リストを使用して、ソースおよびターゲットを選択します。
新しいサービスをターゲット・サービスとして作成する場合は、新規サービス・チェック・ボックスを選択し、サービスの名前およびバージョンを指定します。まだ存在しないサービスにソース・エンドポイントを移動する場合には、これを行うことをお薦めします。

3. 「エンドポイントの明確化」ツールのアクション部分には、選択したソースおよびターゲットに基づいて、実行できる可能性があるアクションが表示されます。
有効なアクションをクリックします。目的のアクションが使用可能でない場合は、ターゲットを変更するか、または「新しいサービスの作成」を選択することが必要になる場合があります。これらの各アクションの影響の詳細は、mergeServices、removeDuplicateEndpointまたはmoveEndpointsの対応するコマンドラインを調べてください。これらのアクションを必要とするユースケースについては、すでに説明しています。

4. アクションを選択した後、そのアクションの影響が「プレビュー」領域に表示されます。表示された結果が想定どおりである場合は、「OK」ボタンをクリックして選択したアクションを実行します。

12.8 その他の管理トピック

この項では、Business Transaction Managementの管理に役立つその他の情報を提供します。この項の内容は次のとおりです。

- システム・サービスのステータスの確認

- システムの再同期および稼働ステータスのチェック

- エンドポイントの監視の開始および停止

- コンテナの使用

- システム・ポリシーの使用

12.8.1 サービスの登録解除

サービスを登録解除するには、管理コンソールで次の手順を使用します。また、CLIコマンドunregisterを使用してサービスを登録解除することもできます。このCLIコマンドの使用方法については、第10章「コマンドおよびスクリプト」を参照してください。

サービスを登録解除するには

1. サービスを選択します。

2. 「変更」→「My_Service登録の削除」を選択します。My_Serviceは選択したサービスの名前です。
「サービス登録の削除」ツールが開きます。

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

12.8.2 システム・サービスのステータスの確認

次のリストでは、システム・サービスのステータスの確認方法について説明します。リストには、これらのタスクが高レベルから低レベル(上位から下位)の順に並んでいます。リストされた各タスクにより、監視を実行できる場所へと移動し、さらに詳細な情報へのリンクが提供されます。

次のものを確認するには:

- システム・サービスおよびシステム・アラートのサマリー
「ダッシュボード」→「操作状態サマリー」に移動します。

- すべてのシステム・アラートの詳細なビュー
「過去1時間のアラート」→「システム・アラート」に移動します。

- 特定のシステム・サービスの現在のステータス
特定のシステム・サービスに移動し、「ステータス」タブを表示します。

12.8.2.1 システム・アラート

システム・アラートは、Business Transaction Managementインフラストラクチャの状態に関する情報を提供します。Business Transaction Managementは、致命的なエラー、コンテナの停止、ポリシーの拒否、使用中の属性の削除などが発生した場合にシステム・アラートを発行します。

12.8.2.2 「ステータス」タブ

選択したBusiness Transaction Managementシステム・サービスのステータスを確認するには、「ステータス」タブを使用します。

サービス・ステータス表

「ステータス」タブの最上部にある表には、サービスに関する次の情報が記載されています。

- URL: Business Transaction ManagementがサービスのUUIDが見つかると認識している場所。

- ID: サービスに割り当てられたUUID。

- ステータス: サービス・ステータスは、次のいずれかの値になります。

- RUNNING: システム・サービスは実行中で正しく動作しています。システム・サービスがRUNNINGである場合、そのすべての関連付けられたリソースはアクセス可能で実行中である必要があります。

- DEGRADED: リソースはアクセス不可である場合がありますが、そのリソースはシステム・サービスの稼働に必須ではありません。低下状態のサービスに対するアクセス不可のリソースを調べることをお薦めします。システムの再同期により、低下状態のサービスが修正される場合があります。低下状態のサービスは、システム・ログへのアラートをトリガーしません。

- FAULTED: 必須のリソースにアクセスできません。通常、フォルト値はサービスが必要とするデータベースが停止したときに表示されます。サービスは、フォルト状態になると、使用できないとみなされます。その後、エラーがシステム全体に伝わらないように、サービスへのアクセスが停止します。フォルト状態のサービスは、システム・ログへのアラートをトリガーします。このアラートにより、問題の根本原因への対処方法に関する情報が提供されます。システムの再同期により、フォルト状態のサービスが修正されることはありません。そのかわり、まず問題の根本原因に対処し、次にフォルト状態のサービスが含まれているBusiness Transaction Managementデプロイメントを再起動する必要があります。

- SETUP_REQUIRED: システム・サービスの必須のリソースや要素がまだアップグレードされていません。たとえば、トランザクション管理コンポーネントがデータベースに接続されていません。

- INITIALIZING: サービスは、その存続時間の冒頭でこの一時的な状態になります。

リソース・ステータス表

サービス・ステータス表の下にリソース・ステータス表があり、選択したサービスに関係があるBusiness Transaction Management環境の他のコンポーネントに関するステータス情報が提供されます。たとえば、いくつかのシステム・サービスがデータベースを使用します。リソースのセクションでは、データベースが実行中で正しく動作していることを確認できます。

リソース・ステータス表では、次のタイプの情報が提供されます。

- ステータス: リソース・ステータスは、次のいずれかの値になります。

- OK: リソースは実行中で正しく動作しています。

- FAULTED: 必須のリソースにアクセスできません。

- SETUP_REQUIRED: 必須のリソースがまだアップグレードされていません。

- 最終アクセス: サービスがリソースへの最終アクセスを試みたときのタイムスタンプ。

- 最後の正常なアクセス: サービスが最後にリソースにアクセスしたときのタイムスタンプ。システム・ログを使用して問題を診断するときは、リソースの「最後の正常なアクセス」のタイムスタンプが適切な開始点です。

リソース・ステータス表に含まれているもう1つの重要な情報は、選択したシステム・サービスが関連付けられているスフィア・サービスのURLです。

注意:
リソースURLは、ダッシュ「-」またはカッコ「()」とともに表示されます。ダッシュとともに表示されるURLはスフィア・サービスなどインストール内に1回のみ存在できるリソースを表し、カッコとともに表示されるURLはモニターなど複数のインスタンスを存在させることができるリソースを表します。

12.8.3 システムの再同期および稼働ステータスのチェック

スフィアは約15分おきに同期します。「管理」→「システムの再同期」を選択して、スフィアを手動で再同期できます。再同期によって、スフィアにシステムの現在の状態が反映されるようになります。また、「システムの再同期」では同時に稼働ステータス・チェックも実行されます。

デフォルトでは、稼働ステータスが2分おきにチェックされて、サービスが稼働しているのか停止しているのかが確認されます。次の説明に従って、自動稼働ステータス・チェックの時間間隔を変更できます。(CLIで稼働ステータス・チェックに相当するのは、configureAlivenessCheckコマンドです。)

12.8.3.1 自動稼働ステータス・チェックの時間間隔の変更

自動稼働ステータス・チェックの時間間隔を変更するには:

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

2. AP_Sphere_Serviceを選択し、次に「管理」→「設定データの編集: AP_Sphere_Service」を選択します。

3. 「XMLの編集」リンクをクリックします。

4. <AlivenessInterval>要素を探し、その値を適切な秒数に変更します。デフォルト値は120秒(2分)です。

5. 「適用」をクリックします。

12.8.4 エンドポイントの監視の開始および停止

Business Transaction Managementは、オブザーバ通信ポリシーの設定方法に応じてコンポーネントを自動的に検出および監視します。コンポーネントの検出の完了後、エンドポイントの監視を明示的に開始および停止できます。

エンドポイントの監視を開始または停止すると、モニターとオブザーバ構成の両方が更新されます。監視が停止すると、パフォーマンス測定は記録されず、メッセージはログに記録されず、トランザクションはトレースされません。

エンドポイントの監視を停止するには

1. エンドポイント(またはサービス)を選択します。

2. 「管理」→「監視の停止」を選択します。
監視の停止ツールが開き、監視を停止する追加のエンドポイントを選択できます。

エンドポイントの監視を開始するには

1. エンドポイント(またはサービス)を選択します。

2. 「管理」→「監視の開始」を選択します。
監視の開始ツールが開き、監視を開始する追加のエンドポイントを選択できます。

12.8.5 コンテナの使用

注意:
Business Transaction Managementは、監視対象外コンテナで実行中のサービス・エンドポイントが監視対象コンテナ内のサービスと対話している場合、依存性分析を使用してそれらのエンドポイントを検出できます。registerExternalContainerコマンドを使用して、このようなエンドポイントのコンテナを定義できます。

ナビゲータで「エクスプローラ」→「コンテナ」を選択して、登録済のコンテナを調べることができます。サマリー領域にすべての登録済のコンテナがリストされます。

メイン領域でコンテナを選択して、「プロファイル」タブにそのコンテナに関する情報を表示します。「管理UIコンソール」フィールドのURLをクリックして、コンテナの管理コンソールを開きます。「変更」→「プロファイルの編集: the_selected_container」を選択して、コンテナのプロファイルを編集できます。

コンテナで実行中のサービスを表示するには、そのコンテナを選択し、「サービス」タブを表示します。また、メイン領域にコンテナを展開して、そのコンテナで実行中のサービス・エンドポイントにドリルダウンすることもできます。

12.8.5.1 コンテナの監視

次のリストでは、コンテナの状態の監視方法について説明します。リストには、これらの監視タスクが高レベルから低レベル(上位から下位)の順に並んでいます。リストされた各タスクにより、監視を実行できる場所へと移動し、さらに詳細な情報へのリンクが提供されます。

次のものを確認するには:

- すべてのコンテナの全体的な現在の状態
「ダッシュボード」→「操作状態サマリー」に移動します。

- すべてのコンテナ関連の問題(さらに他のシステム関連の問題)の最新履歴
「過去1時間のアラート」→「システム・アラート」に移動します。

- 特定のコンテナの現在の状態
特定のコンテナに移動し、サマリー領域で「稼働中/停止ステータス」アイコンを選択します。

12.8.5.2 コンテナの登録解除

コンテナを登録解除する必要がある場合があります(つまり、スフィアおよび管理コンソールからコンテナを削除します)。たとえば、次のいずれかの記述が当てはまる場合、コンテナの登録解除が可能であり、そうすることをお薦めします。

- 異なるスフィアでコンテナを登録しました。
異なるスフィアに登録されているモニターに監視を送信するようにオブザーバを再構成すると、このようになります。この場合、オブザーバが稼働中のコンテナは、トラフィックが監視されるとすぐに他のスフィアに自動的に登録されます。

- コンテナからオブザーバをアンインストールしました。

- システムからコンテナをアンインストールしたか、または物理的に除外しました。

このいずれの記述も当てはまらない場合にコンテナを登録解除したときは、コンテナとの間でメッセージ・トラフィックが監視されるとすぐにコンテナが自動的に再登録されます。

コンテナを登録解除するには

1. 登録解除するコンテナを選択します。

2. 「変更」→「selected_container登録の削除」を選択します。
登録の削除ツールが開きます。

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

12.8.6 システム・ポリシーの使用

システム・ポリシーは通常、管理者が使用します。ほとんどのシステム・ポリシーは編集できません。変更できるポリシーでは、カスタム属性の定義、メッセージ・ロギング・データベースへの接続の構成、検出の構成、測定を集約して収集する間隔の指定、新規または変更されたWSDLに対して実行するアクションに関するシステムへの通知が可能です。

この項では、使用可能なシステム・ポリシー、システム・ポリシーへのアクセス方法、システム・ポリシー定義の表示方法、システム・ポリシーの定義方法およびシステム・ポリシーの変更方法について説明します。

12.8.6.1 システム・ポリシーへのアクセス

ナビゲータで「管理」→「システム・ポリシー」を選択して、システム・ポリシーを表示できます。次の表では、次のポリシーについて説明します。

名前

説明

ベースライン格納

エンドポイント、サービスおよびトランザクションに対するベースライン値の導出と格納が可能です。

コールアウト測定

特定のリンクの平均レスポンス時間、スループットおよびフォルト・カウントの測定と表示が可能です。このポリシーは編集できません。

条件測定

特定のトランザクションに対する条件アラート数および条件アラート数率の測定が可能です。このポリシーは編集できません。

コア測定

特定のエンドポイントとサービスについて、平均レスポンス時間、最大レスポンス時間、スループット、フォルト・カウント、トラフィック、フォルトの割合、スループット率およびフォルト率のカウントの計算が可能です。このポリシーは編集できません。

データ・モデル属性定義

サービス、エンドポイント、操作、コンテナ、エージェント、ビジネス・オブジェクト、トランザクションおよびタイプ・ドメインのカスタム属性を拡張します。

デフォルト・メッセージ・ロギング・データベース

メッセージのロギングに使用されるデータベースへの接続を構成します。詳細は、12.2.2項「メッセージ・ログ・データベースの設定」を参照してください。

デフォルト・オブザーバ通信ポリシー

どのジャンルを監視するかを決定し、モニターのポート番号を指定します。

イベント生成ポリシー

イベント通知の発生に基づいてイベントの生成を構成します。

イベント通知測定ポリシー

通知サービスで使用されます。このポリシーの基準は再定義のみ可能です。

測定間隔ポリシー

測定結果がBusiness Transaction Management全体で集計および収集される間隔を指定します。

サービス・バージョニング・ポリシー

新規または変更されたWSDLに対して実行するアクションをシステムに指示します。詳細は、12.7項「検出問題の解決」を参照してください。

シンプル・トランザクション測定ポリシー

特定のトランザクションの平均レスポンス時間、最大レスポンス時間、完了済トランザクション・カウント、開始済トランザクション・カウント、完了済トランザクション率および開始済トランザクション率の測定が可能です。
Business Transaction Managementは、トランザクションの定義方法および使用されている機能に応じて、このポリシーまたはトランザクション測定ポリシーを使用して、トランザクション・パフォーマンスを測定します。

このポリシーは編集できません。

トランザクションのシステム生成ログ・ポリシー

トランザクション・メッセージの格納場所、時間ストアの制限、切替え間隔を指定し、ロギングの範囲を定義します。
このポリシーは編集できません。

トランザクション測定

特定のトランザクションの平均レスポンス時間、最大レスポンス時間、完了済トランザクション・カウント、開始済トランザクション・カウント、完了済トランザクション率および開始済トランザクション率の測定が可能です。
Business Transaction Managementは、トランザクションの定義方法および使用されている機能に応じて、このポリシーまたはシンプル・トランザクション測定ポリシーを使用して、トランザクション・パフォーマンスを測定します。

このポリシーは編集できません。

稼働時間測定

特定のエンドポイントとサービスの稼働時間の測定が可能です。このポリシーは編集できません。

モニター・グループ・ポリシー

モニター・エージェント・グループの作成と構成を行います。

12.8.6.2 システム・ポリシー定義の表示

システム・ポリシー定義を表示するには:

1. 「管理」→「システム・ポリシー」を選択します。

2. メイン・ペインで関心のあるポリシーをダブルクリックします。

3. 「プロファイル」タブをクリックします。

12.8.6.3 システム・ポリシーの定義および変更

システム・ポリシーを定義するには:

1. 「管理」メニューから「システム・ポリシーの作成」を選択します。

2. 「メッセージ・ログ・データベース」、「モニター・エージェント・グループ」、「オブザーバ通信」のいずれかを選択します。

3. 必須の情報を指定し、「適用」をクリックします。

ポリシーを定義するときは、識別情報としてポリシーの名前およびそれが有効かどうかを指定する必要があります。また、ポリシーが実現する内容を決定する設定と、ポリシーが適用されるエンドポイント(ターゲット)を決定する条件を指定する必要があります。

一部のシステム・ポリシーは変更のみが可能で、ナビゲータの「管理」→「システム・ポリシー」からアクセスする必要があります。

システム・ポリシーを変更するには

1. 「管理」→「システム・ポリシー」を選択します。

2. メイン領域で関心のあるポリシーを選択します。

3. 「変更」→「定義の編集: policy」を選択します。このメニュー項目が使用可能でない場合、ポリシーは変更できません。

索引
A  B  C  D  E  F  G  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W

A

アクセシビリティ, はじめに

キーボード・ショートカット, 3.4.5

actorプロパティ, 5.2.2 addBaseAddressAliasコマンド, 10.2 addNodeAliasコマンド, 10.3 addPathAliasコマンド, 10.4 ADFルールセット, 12.1.2.9 aggregateCountプロパティ, 5.2.2 aggregateFaultCountプロパティ, 5.2.2 アラート

条件, 8.10

条件の解釈, 8.8.2

有効期限の変更, 8.10.3

通知, 10.46

システム, 12.8.2.1

エイリアス

ベース・アドレス, 10.2, 10.36

ノードのリスト, 10.28

同じホストに対する複数の別名, 12.7.3

ノード, 10.3, 10.39

パス, 10.4, 10.40

「分析」タブ, 3.4.1 任意のアドレスフィールド, 12.1.2.7.5 AP_NANO_CREATE_LOG_BASEDIRプロパティ, 12.1.3 AP_NANO_LOG_BASEDIR Javaプロパティ, 12.1.3 AP_NANO_LOG_BASEDIRプロパティ, 12.1.3 AP_SPHERE_URL環境変数, 10.1.5 AP_USER_LOGIN環境変数, 10.1.3, 10.1.5 アーキテクチャの概要, 1.3 arrivalTimeプロパティ, 5.2.2, 5.2.2, 5.2.2 属性

コンシューマ・ビジネス・オブジェクト, 7.1.1

連絡先ID, 10.1.6

コンテナ, 10.1.6

フィルタリングのカスタム属性, 3.4.4

デプロイメント, 10.1.6

説明, 10.1.6

エンドポイント, 10.1.6

インタフェース, 10.1.6

インタフェース操作, 10.1.6

CLIコマンドでの名前, 10.1.6

ノート・タイプ, 10.1.6

操作, 10.1.6

rueiPresent, 12.1.2.8

サービス, 10.1.6

トランザクション, 10.1.6

認証, 12.3.1 平均レスポンス時間インスツルメント, 6.3.1, 6.3.2 AWTrace.log, 12.1.3

B

システムのバックアップ, 12.4.1

ベース・アドレス別名, 10.2, 10.36

ベースライン格納システム・ポリシー, 12.8.6.1

ベースライン, 10.48

btmAdminロール, 12.3.1.1, 12.3.2.1

btmcli.batファイル, 10.1

btmcli.shファイル, 10.1

btmInspectorロール, 12.3.1.1, 12.3.2.2

btmObserverロール, 12.3.1.1, 12.3.2.1

btmUserロール, 12.3.1.1, 12.3.2.1

ビジネス・オブジェクト

エクスポート, 10.13

インポート, 10.21

C

コールアウト測定システム・ポリシー, 12.8.6.1

セントラル・サーバー, 1.3

動作保証マトリックス, 1.1

チャート

カスタム, 3.4.1.10

表示, 3.2.3

codeプロパティ, 5.2.2 列チューザ, 3.2.1.2 列サイズ設定, 3.2.1.2 コマンドライン・インタフェース

コマンド一覧, 10.1.4

環境変数, 10.1.5

コマンドの実行, 10.1.2

ヘルプ, 10.1.1

概要, 10.1

セキュリティ・オプション, 10.1.3

完了済トランザクション率インスツルメント, 6.3.1 完了済トランザクション・インスツルメント, 6.3.1 「コンプライアンス」タブ, 8.6 条件アラート率インスツルメント, 6.3.1 条件アラート

「分析」タブ, 3.4.1.7

インスツルメント, 6.3.1

解釈, 8.8.2

率, 6.3.1

条件アラート・インスツルメント, 6.3.1 条件測定システム・ポリシー, 12.8.6.1 条件

定義, 8.8.1, 8.9.2

定義, 変更, 5.10.3

削除, 8.9.7

無効化, 8.9.3

複製, 8.9.6

有効化, 8.9.3

評価, 8.8.1

フォルト監視, 8.9.1

概要, 8.8

欠落メッセージ, 不正確, 5.11

変更, 8.9.5

タイプ, 8.8

使用, 5.1.6

アラート情報の表示, 8.10

情報の表示, 8.9.4

構成ファイル, 10.5.2 「構成ラベル」フィールド, 12.1.2.7, 12.1.2.7.5 configureコマンド, 10.5 configureAlivenessCheckコマンド, 10.6 Business Transaction Managementの構成, 10.5 コンソール

認証, 12.3.1

チャート, 3.2.3

列チューザ, 3.2.1.2

ダッシュボード, 3.2.5

設計, 3.1.1

フィルタリング・コントロール, 3.2.1.1

インスペクタ, 3.2.1.4

概要, 3.1

メイン領域, 3.1.3

メニュー, 3.1.4

オブジェクト詳細ウィンドウ, 3.1.6

ポップアップ・リンク, 3.2.1.4

表, 3.2.4

タブ, 3.1.5

時間間隔コントロール, 3.2.1.3

コンシューマ・ビジネス・オブジェクト

カスタマイズ, 7.2.1

概要, 7.1

コンシューマ

追加, 7.4

作成, 7.1.2

ラベルのカスタマイズ, 7.6

デフォルト名, 変更, 7.1.3

削除, 7.4

名前の編集, 7.5

概要, 7.1

メッセージへのマッピング, 7.2, 7.2.2

監視, 7.3

名前, 7.5

セグメント化, 5.4.1.2, 7.1.1

「分析」タブの使用状況, 3.4.1.4

連絡先ID属性, 10.1.6 コンテナ

稼働ステータス, チェック, 10.6

属性, 10.1.6

検出, 4.1.1

外部, 10.34

情報, 4.2.2

情報の変更, 4.2.3

監視, 12.8.5.1

登録解除, 4.2.4, 10.53, 12.8.5.2

検出済の表示, 4.2

表記規則, はじめに コア測定システム・ポリシー, 12.8.6.1 countプロパティ, 5.2.2 「カウント」表, 3.4.1.1 createOrUpdateGenreコマンド, 10.7 createOrUpdatePolicyコマンド, 10.8, 10.9 createSettingsDocumentコマンド, 10.9 資格証明「セキュリティ」を参照 credStoreToolコマンド, 10.10 現在のコンプライアンス・ステータス・インスツルメント, 6.3.1, 6.3.2 カスタム・データ・エクスプローラ, 3.3.2

D

ダッシュボード

状態サマリー, 3.4.2

上位10件のサービス, 6.2

表示, 3.2.5

データ

移行, 12.5

データ・モデル属性定義システム・ポリシー, 12.8.6.1 データベース

インストール前の表の作成, 11.2

資格証明設定, 変更, 12.2.1

組込み, 12.2.2

メッセージ・ログ, 設定, 12.2.2

操作データ, 12.4.2.1

パフォーマンス・マネージャ, 12.4.4

datastoreUtilユーティリティ, 11.2 デフォルト・メッセージ・ロギング・データベース・システム・ポリシー, 12.8.6.1 デフォルト・オブザーバ通信システム・ポリシー, 12.8.6.1 deleteAllコマンド, 10.11 依存性

削除, 4.4.5

検出, 4.1.1

エンドポイント間, 4.4.3

操作間, 4.4.4

関連要素, 4.4

サービス間, 4.4.2

表示, 4.4

デプロイメント

属性, 10.1.6

永続記憶域ディレクトリ, 12.2.3

推奨, 1.3

トポロジ, 4.3.2

説明属性, 10.1.6 detailプロパティ, 5.2.2 デバイス

F5, 12.6.1.2, 12.6.2

登録, 10.33

「エンドポイントの明確化」ツール, 12.7.4 検出

ワークフローの一部, 2.1.2

結果の削除, 10.11

制限, 4.1.5

制限, 1.4.2

手動登録, 4.1.5

プロセス, 4.1, 4.1.2

問題の解決, 12.7

ドキュメントURL, 11.4 停止時間, スケジューリング, 8.7

E

ECID

概要, 5.9.2.1

手動キー, 定義, 5.4.1.1

関係ID, 5.9.2.3

検索基準, 5.8.2

メッセージの検索, 5.8

トランザクション操作, 5.9.2.2

EJBコンポーネント, ローカルのモデル化, 12.1.2.1 電子メール・サブスクリプション, 10.47 パスワードの暗号化, 10.12 encryptPasswordコマンド, 10.12 endpoints

稼働ステータス, チェック, 10.6, 12.8.3

属性, 10.1.6

依存性, 4.4.3

監視の無効化, 12.8.4

明確化, 12.7.4, 12.7.4

検出, 4.1.1

重複, false, 12.7.3

監視の有効化, 12.8.4

ジャンル, 10.7

外部コンテナでのグループ化, 10.34

測定の移動, 10.31

移動, 10.30

重複の削除, 10.37

名前の変更, 10.43

レプリケート, 問題, 12.7.2

停止時間のスケジューリング, 8.7

監視停止, 10.51

登録解除, 10.52, 10.52

「モニターに施行」フィールド, 12.1.2.7, 12.1.2.7.5 Enterprise Managerコンソール, 5.9.3 環境変数, 10.1.5 イベント生成システム・ポリシー, 12.8.6.1 イベント通知測定システム・ポリシー, 12.8.6.1 イベント通知, 10.46 execute操作, 4.1.4 existsプロパティ, 5.2.2, 5.2.2, 5.2.2 exportBusinessObjectsコマンド, 10.13, 12.5 エクスポート

ビジネス・オブジェクト, 10.13

メッセージ, 10.14

ポリシー, 10.15

ポリシー・テンプレート, 10.16

プロファイル, 10.17

スケジュール, 10.18

トランザクション定義, 10.19

exportMessagesコマンド, 10.14 exportPoliciesコマンド, 10.15, 12.5 exportPolicyTemplatesコマンド, 10.16 exportProfileコマンド, 10.17, 12.5 exportSchedulesコマンド, 10.18, 12.5 exportTransactionDefnsコマンド, 10.19, 12.5

F

失敗アラート・インスツルメント, 6.3.2

フォルト監視, 8.9.1

フォルトの割合インスツルメント, 6.3.2

フォルト率インスツルメント, 6.3.2

フォルト・インスツルメント, 6.3.2

フィルタ・ツール, 3.4.3

フィルタ処理

コントロール, 3.2.1.1

カスタム属性, 3.4.4

フィルタ・ツール, 3.4.3

フィルタリング・コントロール, 3.2.1.1 マップのフィルタ, 3.2.2.2 機能アップグレードの問題, 1.4

G

「オブザーバのみ対象の構成の生成」フィールド, 12.1.2.7, 12.1.2.7.5

getSetupDataコマンド, 10.20

I

importBusinessObjectsコマンド, 10.21, 12.5

インポート

ビジネス・オブジェクト, 10.21

ポリシー, 10.22

ポリシー・テンプレート, 10.23

プロファイル, 10.24

スケジュール, 10.25

トランザクション定義, 10.26

importPoliciesコマンド, 10.22, 12.5 importPolicyTemplatesコマンド, 10.23 importProfileコマンド, 10.24, 12.5 importSchedulesコマンド, 10.25, 12.5 importTransactionDefnsコマンド, 10.26 importTransactionsDefns, 12.5 インスペクタ, 3.2.1.4 インストーラの場所, 11.4 インスツルメント

表示期間, 6.3

評価期間, 6.3

使用可能リスト, 10.27

操作, 6.3.2

サービス, 6.3.2

サマリー, 6.3

トランザクション監視, 6.3.1

インタフェース属性, 10.1.6 インタフェース操作属性, 10.1.6 IPアドレス・セグメンテーション, 5.4.1.2

J

JAVA_HOME環境変数, 10.1, 11.1

JDBCコール

モデル化, 4.1.4

JDBCサマリー・モード

有効化の効果, 4.1.4.1

有効化, 4.1.4

データの表示の理解, 4.1.4.1

トランザクション定義の更新, 4.1.4.2

JMSコンポーネント, モデル化, 12.1.2.1 JVM診断, 5.9 JVMDビュー

アクセス, 5.9.3

K

キーボード・ショートカット, 3.4.5

L

ラベル, オブザーバ構成, 12.1.2.7.1

リンクの平均レスポンス時間, 6.3.2

リンク・フォルト・インスツルメント, 6.3.2

リンク・スループット・インスツルメント, 6.3.2

listInstrumentsコマンド, 10.27

listNodeAliasesコマンド, 10.28

ロード・バランサ

デフォルト, 12.6.1.2, 12.6.1.3

概要, 12.6

情報の変更, 12.6.1.5

登録, 12.6.1.4

ルーティング・エントリ・ポイント, 12.6.1.1, 12.6.1.6

デフォルトの設定, 10.49

設定, 12.6.1

ターゲット・エントリ・ポイント, 12.6.1.1, 12.6.1.6

サポートされるタイプ, 12.6.1.2

登録解除, 12.6.1.7

ロギング

オブザーバ・エラーおよびデバッグ情報, 12.1.3

オブザーバ・エラーおよび監視対象メッセージ, 12.1.2.1

logMerger構成ファイル, 11.3.1 logMergerユーティリティ, 11.3

M

メイン・サーバー, 1.3

管理コンソール

「コンソール」を参照

マップ

表データの表示, 3.2.2.1

フィルタおよび調整, 3.2.2.2

スケーリング, 3.2.2.3

表示, 3.2.2

最大レスポンス時間インスツルメント, 6.3.1, 6.3.2 測定間隔システム・ポリシー, 12.8.6.1 メニュー, 3.1.4 mergeServicesコマンド, 10.29 メッセージ・ログ・データベース

一元的サービスによるアクセス, 12.2.2

設定, 12.2.2

メッセージ・ログ検索ツール, 5.8.2 メッセージ・ログ

不正確, 5.11

切替え, 5.4.1.5

メッセージ・サイズ

モニターでの調整, 12.1.2.1

オブザーバでの調整, 12.1.2.1

メッセージ

ECID, 5.9.2.1

エクスポート, 10.14

コンシューマへのマッピング, 7.2, 7.2.2

「メッセージ」表, 3.4.1.1 データの移行, 12.5 SOA、OSB、JMSおよびローカルEJBコンポーネントのモデル化, 12.1.2.1 モニター・グループ・システム・ポリシー, 12.8.6.1 モニタリング

コンシューマ, 7.3

コンテナ, 12.8.5.1

必要性の決定, 2.1.5

サービス, 6.1

状態情報, 12.4.4

モニター

メッセージ・サイズの調整, 12.1.2.1

キュー動作の調整, 12.1.2.1

F5デバイス, 12.6.2

概要, 1.3

メッセージ・ログ・ポリシー, 適用, 12.2.2

オブザーバ通信ポリシー, 12.1.2

オブザーバ, 12.1.1

登録, 10.35

登録情報, 12.4.4

レプリケート,12.1.2.4

セキュアな通信, 12.1.2.5

登録解除, 10.54

moveEndpointsコマンド, 10.30 moveMeasurementsコマンド, 10.31

N

NanoAgentErrorTrace.log, 12.1.3

NanoAgent.log, 12.1.3

NanoAgentPreprocessTrace.log, 12.1.3

ナビゲータ, 3.1.2

ノート・タイプ属性, 10.1.6

通知サービス, 10.46, 10.47

O

オブジェクト詳細ウィンドウ, 3.1.6

「オブザーバのベース・アドレス」フィールド, 12.1.2.7, 12.1.2.7.5

オブザーバ通信ポリシー, 12.1.2

複数の適用, 12.1.2.7

事前構成済, 12.1.2.7.4

オブザーバのターゲット, 12.1.2.7

オブザーバ構成ラベル, 12.1.2.7.1 オブザーバ

メッセージ・サイズの調整, 12.1.2.1

キュー動作の調整, 12.1.2.1

動作保証マトリックス, 1.1

通信ポリシー, 12.1.2

概要, 1.3

デバッグ情報のロギング, 12.1.3

エラーのロギング, 12.1.2.1, 12.1.3

メッセージのロギング, 12.1.2.1

構成の優先順位, 12.1.2.7.3

プローブ, 12.1.1

セキュアな通信, 12.1.2.5

構成/通信ポリシーを使用したターゲット, 12.1.2.7

タイプ, 12.1.1

汎用, 1.4.1

操作

属性, 10.1.6

依存性, 4.4.4

ECID, 5.9.2.1

インスツルメント, 6.3.2

オブザーバ構成の優先順位, 12.1.2.7.3 OSBコンポーネント, モデル化, 12.1.2.1

P

パスワード, 10.12

パフォーマンス

不完全または不正確な測定, 5.11

監視, サービス, 6.1

「分析」タブのペイン, 3.4.1.1

レポート, 9

パフォーマンス目標, 8.2.1 パフォーマンス・サーバー

概要, 1.3

永続記憶域ディレクトリ

デフォルトの場所, 12.2.4.1

概要, 12.2.3

再配置, 12.2.4

ポリシー

作成(CLI), 10.8

削除, 8.4

無効化, 8.4

複製, 8.4

エクスポート, 10.15

インポート, 10.22

変更, 8.4

削除, 10.41

サービス・レベル合意, 8.4

システム, 12.8.6

更新(CLI), 10.8

ステータスの表示, 8.4

ポリシー・テンプレート

エクスポート, 10.16

インポート, 10.23

削除, 10.42

パフォーマンス・サーバー

操作データ, 12.4.4

プローブ, 12.1.1

アクティブ化および非アクティブ化, 12.1.2.2

追加, 12.1.2.3

JAVA, 12.1.2.2

WEB_APP, 12.1.2.9

プロファイル

エクスポート, 10.17

インポート, 10.24

データの更新, 10.55

プロパティ

コンシューマ・セグメンテーション, 使用, 7.1.1

定義, 5.3.1

定義の複製, 5.3.6

情報, 5.10.4

概要, 5.2

変更, 5.3.5

目的, 5.1.2

削除, 5.3.7

検索基準, 5.8.2.2

WSDLがないサービス, 5.3.2

標準, 5.2.2

使用, 5.2.1

ユーザー定義, 5.2.3

ログの表示, 5.8

値の表示, 5.3.3

putSetupDataコマンド, 10.32

Q

キュー動作

モニターでの調整, 12.1.2.1

オブザーバでの調整, 12.1.2.1

R

システムのリカバリ, 12.4.1

registerDeviceコマンド, 10.33

registerExternalContainerコマンド, 10.34

registerMonitorコマンド, 10.35

関係ID, 5.9.2.3

removeBaseAddressAliasコマンド, 10.36

removeDuplicateEndpointコマンド, 10.37

removeNodeコマンド, 10.38

removeNodeAliasコマンド, 10.39

removePathAliasコマンド, 10.40

removePolicyコマンド, 10.41

removePolicyTemplateコマンド, 10.42

renameEndpintコマンド, 10.43

レポート

生成, 9.2

測定データの取得, 10.45

概要, 9.1

テンプレート, 9.1

インスタンス診断リクエスト, 5.9 「インスタンス診断リクエスト」ビュー, 5.9.2, 5.9.2.3

アクセス, 5.9.3

requestECIDプロパティ, 5.2.2, 5.9.2.1 resetSphereUrlコマンド, 10.44 「レスポンス時間」チャート, 3.4.1.1 responseECIDプロパティ, 5.2.2, 5.9.2.1 responseTimeプロパティ, 5.2.2 responseTime responseTime, 5.2.2 システムの再同期化, 12.8.3 retrieveObjectDataコマンド, 10.45 ロール

補助, 12.3.2.2

アプリケーション・サーバーへのマッピング, 12.3.1

プライマリ, 12.3.2.1

ルーター, 4.3.3 ルーティング・エントリ・ポイント, 12.6.1.1, 12.6.1.6

モデル化, 10.49

RUEIドリルダウン, 12.1.2.8 rueiPresent属性, 12.1.2.8

S

マップのスケーリング, 3.2.2.3

スケジュール

エクスポート, 10.18

インポート, 10.25

スクリプト

ワークフローでの作成, 2.1.6

実行,10.1.2

メッセージの検索, 5.8.2, 5.8.2 セキュリティ

資格証明, 10.10

デフォルト設定, 1.4.3

パスワードの暗号化, 10.12

システム, 12.3

ユーザー・ロール, 12.3.2.1

CLIのセキュリティ・オプション, 10.1.3 senderプロパティ, 5.2.2, 5.2.2, 5.2.2 sendEventNotificationコマンド, 10.46 sendToNotifierコマンド, 10.47 サービス・レベル合意

ベースライン, 10.48

コンプライアンス・ステータス, 6.3.1

「コンプライアンス」タブ, 8.6

定義, 8.3

評価期間, 8.2.2

概要, 8.2

コンプライアンスの監視, 8.5

パフォーマンス目標, 8.2.1

ポリシー, 8.4

使用, 5.1.6

サービス・バージョニング・システム・ポリシー, 12.8.6.1 サービス

属性, 10.1.6

依存性, 4.4.2

検出, 4.1.1

ジャンル, 10.7

インスツルメント, 6.3.2

マージ, 10.29

監視, 6.1

測定の移動, 10.31

複数バージョン, 12.7.2

「分析」タブの「パフォーマンス」, 3.4.1.3

手動による登録, 4.5

停止時間のスケジューリング, 8.7

構造, 10.50

上位10件, 6.2

タイプ, 4.3.1

登録解除, 12.8.1

バージョニング・ポリシー, 変更, 12.7.1

表示, 4.3, 4.3.4

setBaselinesコマンド, 10.48 setDefaultLoadBalancerコマンド, 10.49, 12.6.1.3 関連の表示, 4.4 showProductInfoユーティリティ, 11.4 showServiceコマンド, 10.50 シンプル・トランザクション測定システム・ポリシー, 12.8.6.1 SOAコンポーネント, モデル化, 12.1.2.1 スフィア

データベースのバックアップ, 12.4.4

定義メタデータ, 12.4.2.1

URLのリセット, 10.44

標準プロパティ, 5.2.2 開始済トランザクション・インスツルメント, 6.3.1, 6.3.1 stringプロパティ, 5.2.2 サポート情報, はじめに 構文表記規則, はじめに システム

アラート, 12.8.2.1

バックアップとリストア, 12.4

構成データ, 12.4.2.1, 12.4.4

情報, 11.4

ポリシー, 12.8.6

損傷または破損からのリカバリ, 12.4.3

リストア, 12.4.3

再同期化, 12.8.3

システム・コンテナ, 未割当てのエンドポイント, 4.5 システム生成ログ・システム・ポリシー, 12.8.6.1 システム・ポリシー, 12.8.6 システム・サービス

使用されるデータ, 12.4.2.1

ログ・ファイルのマージ, 11.3

設定ファイル, 10.20, 10.32

ステータス, 12.8.2.2

ステータス, 確認, 12.8.2

T

表

カスタマイズ, 3.4.1.11

変更, 3.3.1

表示, 3.2.4

タブ

分析「「分析」タブ」を参照

概要, 3.1.5

ターゲット・エントリ・ポイント, 12.6.1.1, 12.6.1.6 「対象の指定オブザーバ」フィールド, 12.1.2.7.5 スループット・インスツルメント, 6.3.2 スループット率インスツルメント, 6.3.2 時間間隔コントロール, 3.2.1.3 トラフィック・インスツルメント, 6.3.2 トランザクション・サーバー, 1.3 トランザクション, 10.26

アラート, 5.5.3

属性, 10.1.6

自動相関と手動相関, 5.1.3

条件「条件」を参照

メッセージの相関, 5.4.1.4

デフォルト定義, 5.1.4

デフォルトの評価期間, 5.6

定義, 5.1.1, 5.4.1

ワークフローでの定義, 2.1.4

定義の削除, 5.4.3

有効化, 5.4.1.1

定義のエクスポート, 10.19

リストのフィルタ処理, 5.5.1

索引のメッセージ・コンテンツ, 5.4.1.5

インスタンス・インスペクタ, 5.7.2

インスタンス・ロギング, 5.4.1.3, 5.8.3

インスタンス, アセンブル, 5.7.2

インスタンス, 定義, 5.1.1

インスタンス, 表示, 5.7

監視のインスツルメント, 6.3.1

概要, 5.1

JVM診断, 5.9

ログ・メッセージ, 表示, 5.8

メッセージ・ログ・データベース, 設定, 12.2.2

メッセージ・ログ検索ツール, 5.8.2

メッセージ・ロギング, 5.4.1.3, 5.8.3

定義の変更, 5.4.2

パフォーマンス分析, 5.5.2.2

「分析」タブの「パフォーマンス」, 3.4.1.2

パフォーマンス, 5.5, 5.5.2

パフォーマンス・サマリー, 5.5.2.1

適用されるポリシー, 5.10.2, 5.11.1

プロファイル情報, 5.10

プロパティ「プロパティ」を参照

インスタンス診断リクエスト, 5.9.2

スコープ, 5.1.1

セグメンテーション, 有効化, 5.4.1.2

記憶域設定, 5.4.1.5

タブ, 5.5

上位10件, 5.6

トラブルシューティング, 5.11

トラブルシューティング, 1.4

U

unmonitorEndpointコマンド, 10.51

unregisterコマンド, 10.52

unregisterContainerコマンド, 10.53

サービスの登録解除, 12.8.1

unregisterMonitorコマンド, 10.54

updateProfileDataコマンド, 10.55

アップグレードの問題, 1.4

稼働時間インスツルメント, 6.3.2

稼働時間測定システム・ポリシー, 12.8.6.1

URLルールセット, 12.1.2.9

ユーザー・プリファレンス・ディレクトリ, 12.4.4

ユーザー・ロール, 12.3.2.1

userPreferencesディレクトリ, 12.4.4

ユーティリティ, 11.1

V

「アドレスの検証」フィールド, 12.1.2.7, 12.1.2.7.5

ビュー

新規作成, 3.3

保存, 3.3.3

違反アラート・インスツルメント, 6.3.2 違反アラート%インスツルメント, 6.3.2

W

警告アラート・インスツルメント, 6.3.2

WEB_APPプローブ, 12.1.2.9

ワークフロー, 基本, 2.1

WSDL

新規または変更済, 12.7.1

登録解除, 10.52

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, 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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。