Oracle® Fusion Middleware

Oracle Service Busの管理

12c (12.2.1.1.0)

E77221-02(原本部品番号:E67912-02)

2016年8月

このドキュメントは、インポートとエクスポート、モニター、レポート、操作設定、グローバル・リソース管理など、Oracle Service Busランタイム環境をモニターおよび管理する方法について説明した管理者向けのドキュメントです。

Oracle Fusion Middleware Oracle Service Busの管理、12c (12.2.1.1.0)

E77221-02

Copyright © 2008, 2016, Oracle and/or its affiliates. All rights reserved.

原本著者:  Oracle Corporation

原本協力著者:

協力者:

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

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

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

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およびその関連会社は一切の責任を負いかねます。

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

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

目次

表一覧

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

はじめに

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

- 表記規則

このガイドでの新しい情報

第I部 Oracle Service Bus管理の理解

1 相互運用性、互換性およびシステム・サポート

- 1.1 サポートされているシステム構成

- 1.2 Oracle製品との相互運用性および互換性

- 1.3 サポート対象の標準と実装

- 1.4 相互運用性とサポートに関する制限事項

- 1.4.1 .NETの相互運用性に関する制限事項

- 1.4.2 Apache Axisの相互運用性に関する制限事項

- 1.4.2.1 Axisで生成されたRPCエンコードのWSDLドキュメントのインポート時に参照が解決されない

- 1.4.2.2 Axisで生成されたWSDLファイルのSOAPAction属性が空の文字列に初期化される

- 1.4.2.3 一方向の操作のHTTPレスポンスとステータス・コード

- 1.4.2.4 エラーが発生する一方向の操作のHTTPレスポンスおよびステータス・コード

- 1.4.3 WebSphereの相互運用性に関する制限事項

2 Oracle Service Bus管理について

- 2.1 Oracle Fusion Middlewareの概要

- 2.2 Oracle Service Busの概要

- 2.2.1 サービスのモニターと管理について

- 2.2.1.1 管理コンソール

- 2.2.1.2 監査機能

- 2.2.2 Oracle Service Busのモニター・フレームワークについて

- 2.2.3 JMX APIを使用した統計へのアクセス

- 2.2.4 クラスタにおける統計へのアクセス

- 2.3 Oracle Service Busの実行時モニター

- 2.3.1 サービス・ヘルスのモニター

- 2.3.1.1 メトリックの集約

- 2.3.1.2 名前が変更されたサービスまたは移動されたサービスのモニター

- 2.3.2 SLAアラートおよびパイプライン・アラートのモニター

- 2.3.2.1 SLAアラートの概要

- 2.3.2.2 パイプライン・アラートの概要

- 2.3.3 リシーケンス・グループのモニター

- 2.3.4 ログ・ファイルのモニター

- 2.3.5 メッセージ・レポート

- 2.4 Oracle Service Busの実行時管理

- 2.4.1 環境のカスタマイズ

- 2.4.2 ランタイム構成

- 2.4.3 ビジネス・サービス・エンドポイントの管理

- 2.4.4 エンドポイント・スロットルによるパフォーマンスのチューニング

- 2.4.5 リソースのインポートとエクスポート

- 2.4.6 診断

- 2.5 Oracle Service Busの実行時セキュリティ

- 2.5.1 セキュリティ・ポリシーの使用

- 2.5.2 セキュリティ管理の定義

- 2.6 集約間隔について

- 2.6.1 モニター・データのリフレッシュ間隔

- 2.6.2 集約間隔におけるサンプル間隔

- 2.6.3 集約間隔のプロパティ

- 2.6.4 統計のリセット

- 2.7 サーバーのモニターと管理

- 2.8 Oracle Service BusとOracle Enterprise Scheduler

3 Oracle Service Bus管理のスタート・ガイド

- 3.1 管理およびモニター・ページについて

- 3.1.1 Service Busのドメイン・レベルのモニター・ページ

- 3.1.1.1 ダッシュボード(ドメイン・レベル)

- 3.1.1.2 アラート履歴

- 3.1.1.3 サービス・ヘルス

- 3.1.1.4 リシーケンス・メッセージ

- 3.1.1.5 操作

- 3.1.1.6 グローバル設定

- 3.1.2 Service Busのプロジェクト・モニター・ページ

- 3.1.3 Service Busサービスのモニター・ページ

- 3.1.3.1 ダッシュボード(サービス・レベル)

- 3.1.3.2 プロパティ

- 3.1.3.3 ポリシー

- 3.2 Oracle Enterprise Manager Fusion Middleware Controlへのログイン

- 3.3 Oracle Service Bus管理ページへのナビゲート

- 3.3.1 Service Busホーム・ページおよびメニューを使用したナビゲート

- 3.3.2 Service Busプロジェクト・ホーム・ページおよびメニューを使用したナビゲート

- 3.3.3 ホーム・ページからのOracle Service Busページへのナビゲート

- 3.4 システムMBeanブラウザへのナビゲート

- 3.5 アクセシビリティ・オプションの設定

- 3.6 Oracle Enterprise Manager Fusion Middleware Controlからのログアウト

- 3.7 Oracle Service Busサーバーの起動

第II部 Oracle Service Busのモニター

4 Oracle Service Busのアラートのモニター

- 4.1 Oracle Service Busのアラートについて

- 4.1.1 Service Busダッシュボード上のアラート

- 4.1.2 アラートおよび操作設定

- 4.2 サービス・レベル・アグリーメントのアラートについて

- 4.2.1 SLAアラートの重大度レベル

- 4.2.2 集約間隔

- 4.2.3 SLAアラートの間隔

- 4.2.3 SLAアラートの統計

- 4.2.4.1 カウント統計の詳細

- 4.2.4.2 最大、最小および平均の統計の詳細

- 4.2.4.3 ステータス統計の詳細

- 4.3 パイプライン・アラートについて

- 4.3.1 パイプライン・アラートの使用例

- 4.4 アラートの有効化と無効化

- 4.5 サービス・レベル・アグリーメントのアラート・ルールの作成

- 4.5.1 始める前に

- 4.5.2 SLAアラート・ルールのプロパティの構成

- 4.5.3 SLAアラート・ルールの条件の定義

- 4.6 SLAアラート・ルールの更新

- 4.6.1 アラート・ルールの編集

- 4.6.2 アラート・ルールの削除

- 4.7 SLAアラートおよびパイプライン・アラートのモニター

- 4.7.1 アラートのレポートの有効化

- 4.7.2 ドメイン内のすべてのSLAアラートおよびパイプライン・アラートの表示

- 4.7.3 SLAアラートおよびパイプライン・アラートのフィルタ

- 4.7.4 SLAアラートおよびパイプライン・アラートの詳細の表示

- 4.7.4.1 Service Busダッシュボードでのアラートの詳細の表示

- 4.7.4.2 「アラート履歴」ページでのアラートの詳細の表示

- 4.7.5 アラート・ルール構成の表示

- 4.7.5.1 Service Busダッシュボードでのアラート・ルール構成の表示

- 4.7.5.2 「アラート履歴」ページでのアラート・ルール構成の表示

- 4.7.6 SLAアラートおよびパイプライン・アラートの削除

- 4.7.7 SLAアラートおよびパイプライン・アラートのパージ

5 Oracle Service Busのサービス・ヘルスのモニター

- 5.1 サービス・ヘルスのメトリックについて

- 5.1.1 ドメインとプロジェクトのサービス・ヘルス・メトリック

- 5.1.2 プロキシ・サービスのメトリック

- 5.1.3 ビジネス・サービスのメトリック

- 5.1.4 パイプライン・サービスのメトリック

- 5.1.5 分割-結合サービスのメトリック

- 5.2 サービス・ヘルス統計のモニター

- 5.2.1 最も多くのエラーがあるサービスの統計の表示

- 5.2.2 ドメインのサービス・ヘルス統計の表示

- 5.2.3 プロジェクトのサービス・ヘルス統計の表示

- 5.2.4 サービスのすべてのサービス・ヘルス統計の表示

- 5.3 サービス・モニターの統計のリセット

- 5.3.1 統計のリセットについて知っておくべきこと

6 リシーケンス・グループのモニター

- 6.1 リシーケンス・グループについて

- 6.1.1 Oracle Service Busリシーケンス・メッセージの状態

- 6.1.2 リシーケンサのエラー処理

- 6.1.3 リシーケンサ・データベース

- 6.1.4 デプロイメント・アクティビティがリシーケンスに与える影響

- 6.1.5 サーバーのシャットダウンがリシーケンスに与える影響

- 6.1.5.1 Service Busからリシーケンサにメッセージが転送されているときのサーバー・シャットダウン

- 6.1.5.2 ロッカー・スレッドによってグループがロックされているときのサーバー・シャットダウン

- 6.1.5.3 メッセージがリシーケンサで処理されているときのサーバー・シャットダウン

- 6.2 リシーケンスの実行時の構成

- 6.3 リシーケンス・グループおよびメッセージのモニター

- 6.3.1 リシーケンス・グループおよびメッセージのモニター

- 6.3.2 リシーケンス・グループに関する情報の表示

- 6.4 リシーケンス・グループの実行時の管理

- 6.4.1 メッセージのシーケンスIDのスキップ

- 6.4.2 リシーケンス・グループがタイムアウトになった場合の回復方法

- 6.4.3 リシーケンスのフォルトからの回復

7 ログ・ファイルの構成とモニター

- 7.1 Oracle Service Busのロギングについて

- 7.1.1 ODLログ・ファイル

- 7.1.2 ODLロギング・レベル

- 7.1.3 ODLメッセージ書式

- 7.1.4 ODLログ構成

- 7.1.5 Oracle Service Busのログ出力

- 7.2 Oracle Service Bus用のDiagnostic Loggingの構成

- 7.2.1 Fusion Middleware ControlでのService Busのロギングについて

- 7.2.2 Service Busのログ・レベルとログ・ファイルの構成

- 7.2.3 WLSTコマンドを使用したOracle Service Busのロギングの構成

- 7.2.4 Fusion Middleware Controlでのデバッグのためのロギング・レベルの設定

- 7.2.5 Oracle Service Busのエラー・メッセージ接頭辞の設定

- 7.2.6 オフライン・ロギングのためのOracle Service Busの構成

- 7.3 Oracle Service Busの診断ログ・ファイルの表示

- 7.3.1 Fusion Middleware ControlでのOracle Service Busのログ・ファイルの表示

- 7.3.2 ログ・メッセージ・ビューのカスタマイズ

- 7.3.3 WLSTコマンドを使用したOracle Service Busのログ・ファイルの表示

- 7.4 Oracle Service Busのログ出力

- 7.4.1 Service Busの標準のログ出力

- 7.4.2 11gおよび12cのService Busのデバッグ・ログ出力

- 7.5 11gからアップグレードした後のログ構成

- 7.5.1 ロギング・レベル

- 7.5.2 ログ・メッセージの書式

第III部 Oracle Service Busランタイムの管理

8 操作設定とグローバル設定の構成

- 8.1 操作設定について

- 8.1.1 使用可能な操作設定

- 8.1.1.1 状態

- 8.1.1.2 モニター

- 8.1.1.3 集約間隔

- 8.1.1.4 サービス・レベル・アグリーメントのアラート

- 8.1.1.5 パイプライン・アラート

- 8.1.1.6 レポート

- 8.1.1.7 ロギング

- 8.1.1.8 実行トレース

- 8.1.1.9 メッセージ・トレース

- 8.1.1.10 オフラインのエンドポイントURI

- 8.1.1.11 スロットルの設定

- 8.1.1.12 結果キャッシュの状態

- 8.1.1.13 自動サービス移行

- 8.1.1.13.1 自動サービス移行を有効にする前提条件

- 8.1.1.14 JavaScriptタイムアウト

- 8.1.1.15 リシーケンサ設定

- 8.1.2 グローバル・レベルおよびサービス・レベルの操作設定

- 8.2 操作設定の表示と構成

- 8.2.1 グローバル・レベルの操作設定の構成

- 8.2.2 グローバル・レベルの操作設定

- 8.2.3 操作設定を構成するサービスの検索

- 8.2.4 複数のサービスに対する操作設定の有効化と無効化

- 8.2.5 単一のサービスに対する操作設定の有効化と無効化

- 8.2.6 サービスの集約間隔の設定

- 8.2.7 パイプラインまたは分割-結合のモニター・レベルの構成

- 8.2.8 サービスのメッセージ・トレースの構成

- 8.2.9 サービスのSLAアラート・レベルの構成

- 8.2.10 パイプライン・アラート・レベルの構成

- 8.2.11 サービスのロギング・レベルの構成

- 8.2.12 ビジネス・サービスのスロットルの構成

- 8.2.13 ビジネス・サービスのオフライン・エンドポイントURI処理の構成

- 8.3 操作設定の一括更新

- 8.4 リソースのインポート時の操作設定の保持

9 Oracle Service Bus環境のカスタマイズ

- 9.1 環境値について

- 9.1.1 検索と置換

- 9.1.2 構成ファイル

- 9.1.2.1 スキーマ・ファイル

- 9.1.2.2 操作設定

- 9.1.2.3 環境値

- 9.1.2.4 検索と置換

- 9.1.2.5 参照マッピング

- 9.2 Oracle Service Busコンソールを使用した環境値の検索と置換

- 9.2.1 環境値の検索

- 9.2.2 環境値の置換

- 9.3 環境値と操作設定を更新するための構成ファイルの使用

- 9.3.1 構成ファイルの作成

- 9.3.2 構成ファイルの実行

- 9.4 使用可能な環境値

- 9.5 操作設定の環境値

- 9.6 サンプル構成ファイル

10 Oracle Service Busリソースのインポートとエクスポート

- 10.1 Oracle Service Busリソースのインポートとエクスポートについて

- 10.2 Fusion Middleware Controlを使用したOracle Service Busリソースのエクスポート

- 10.3 Fusion Middleware Controlを使用したService Busリソースのインポート

11 Oracle Service Busのアクセス・セキュリティの定義

- 11.1 Oracle Service Busのアプリケーション・セキュリティの理解

- 11.1.1 ユーザー

- 11.1.2 グループ

- 11.1.3 ロール

- 11.1.3.1 Oracle Service Busのアプリケーション・ロール

- 11.1.3.1.1 MiddlewareAdministrator

- 11.1.3.1.2 Developer

- 11.1.3.1.3 Composer

- 11.1.3.1.4 Deployer

- 11.1.3.1.5 Tester

- 11.1.3.1.6 MiddlewareOperator

- 11.1.3.1.7 ApplicationOperator

- 11.1.3.1.8 Monitor

- 11.1.3.2 WebLogic Serverのセキュリティ・ロール

- 11.1.3.3 旧リリースとの互換性

- 11.1.4 アクセス制御ポリシー

- 11.1.5 セキュリティ構成データとセッション

- 11.2 エクスポート時のセキュリティ構成

- 11.3 Oracle Service Bus管理セキュリティの構成

- 11.3.1 個別のユーザーに権限を付与する方法

- 11.3.2 ユーザー・グループ内のユーザーに権限を付与する方法

- 11.3.3 Oracle Service Busのグループの作成

- 11.3.4 グループへの権限の付与

- 11.3.4.1 アプリケーション・ロールへのグループの割当て

- 11.3.4.2 グループへの個別の権限の付与

- 11.3.5 Oracle Service Busユーザーの作成

- 11.3.6 ユーザーをグループに割り当ててアクセス権を付与する方法

- 11.3.7 個別のユーザーへの権限の付与

- 11.3.7.1 アプリケーション・ロールへのユーザーの割当て

- 11.3.7.2 ユーザーへの個別の権限の付与

- 11.4 本番環境でのOracle Service Busのセキュリティ

- 11.4.1 Service Bus (SB)リソースのアンデプロイ

- 11.4.2 bodyコンテンツをストリーミングする場合の一時ファイルの保護

- 11.4.3 Oracle Service Busコンソールに対するサービス拒否攻撃からの保護

第IV部 高度な管理タスクの実行

12 メッセージおよびアラートのレポートの構成

- 12.1 Service Busのレポート・フレームワークについて

- 12.1.1 メッセージ・レポートの構成

- 12.1.2 デフォルトのレポート・プロバイダ

- 12.1.3 カスタム・レポート・プロバイダ

- 12.1.4 レポートのワークフロー

- 12.2 JMSレポート・プロバイダについて

- 12.2.1 パイプライン・レポート・アクションについて

- 12.2.2 グローバル・トランザクションでのレポート・アクション

- 12.3 JMSレポート・プロバイダ・データ・ストア用データベースの構成

- 12.3.1 トランザクションのレポート・データ・ソースの構成

- 12.3.2 JMSレポート・プロバイダ・ストア用データベースの作成

- 12.4 メッセージ・レポートの有効化

- 12.5 メッセージ・レポートの操作

- 12.5.1 メッセージ・レポートの検索

- 12.5.2 メッセージ・レポートの詳細の表示

- 12.5.3 レポート・データ・ストアからのメッセージ・レポートのパージについて

- 12.5.4 レポート・データ・ストアからのメッセージ・レポートのパージ

- 12.6 レポート・プロバイダの停止

- 12.7 レポート・プロバイダの起動

- 12.8 JMSレポート・プロバイダの割当て解除

- 12.8.1 ドメインの作成時にデフォルトのJMSレポート・プロバイダを割当て解除する方法

- 12.8.2 JMSレポート・プロバイダの割当て解除(サーバーが実行中の場合)

- 12.8.3 JMSレポート・プロバイダのターゲット設定解除(サーバーが実行されていない場合)

- 12.9 Oracle Advanced Queueing JMSの使用

13 セキュリティ・ポリシーのモニターと管理

- 13.1 セキュリティ・ポリシーについて

- 13.2 グローバル・ポリシーの構成

- 13.2.1 グローバル・ポリシー・セットの作成方法

- 13.2.2 グローバル・ポリシーのサービスを有効化する方法

- 13.2.3 グローバル・ポリシーのサービスを無効化する方法

- 13.3 セキュリティ・ポリシーのモニター

- 13.3.1 サービスにアタッチされたポリシーの表示

- 13.3.2 ポリシー使用状況のモニター

- 13.3.3 ポリシー違反の表示

- 13.4 セキュリティ・ポリシーの管理

- 13.4.1 サービスへのセキュリティ・ポリシーのアタッチ

- 13.4.2 サービスからのポリシーのデタッチ

- 13.4.3 セキュリティ・ポリシーのオーバーライド

14 ビジネス・サービスのエンドポイントURIのモニターおよび管理

- 14.1 エンドポイントURIの管理について

- 14.1.1 エンドポイントURIについて

- 14.1.2 オフラインおよびオンラインのエンドポイントURI

- 14.1.2.1 一時的なオフライン・エンドポイントURIについて

- 14.1.2.2 永続的なオフライン・エンドポイントURIについて

- 14.1.2.3 クラスタ環境のオフラインURI

- 14.1.3 エンドポイントURIをモニターするためのメトリック

- 14.1.3.1 エンドポイントURIの状態

- 14.1.3.2 エンドポイントURIのパフォーマンス・メトリック

- 14.2 応答しないエンドポイントURIをオフラインにするService Busの構成

- 14.3 エンドポイントURIに手動でオフラインのマークを付ける方法

- 14.4 オフラインのURIにオンラインのマークを付ける方法

- 14.5 ビジネス・サービスに対するエンドポイントURIのメトリックの表示

- 14.6 エンドポイントURIのメトリックに基づいたアラートの作成

- 14.6.1 エンドポイントURIの状態に基づいたSLAアラートの作成について

- 14.6.2 エンドポイントURIの状態に基づいたSLAアラートの作成

- 14.6.3 エンドポイントURIの統計に基づいたアラート・ルールの構成

15 メッセージ・スロットル用にビジネス・サービスを構成する方法

- 15.1 スロットルについて

- 15.1.1 スロットルの概念

- 15.1.2 スロットルのプロパティ

- 15.1.2.1 最大同時実行性

- 15.1.2.2 スロットル・キューの長さ

- 15.1.2.3 メッセージの有効期限(TTL)

- 15.1.3 スロットル・グループ

- 15.1.4 スロットル・グループのプロパティとビジネス・サービスのスロットルのプロパティ

- 15.1.5 複数のエンドポイントURIを使用するビジネス・サービスのスロットル

- 15.1.6 再試行されたメッセージのスロットル

- 15.1.7 スロットルとワーク・マネージャ

- 15.2 クラスタ内でのスロットル

- 15.3 スロットルのメトリック

- 15.3.1 スロットルのメトリックを使用したアラートの定義

- 15.4 1つのビジネス・サービスに対するスロットルの構成

- 15.4.1 1つのビジネス・サービスに対するスロットルの構成

- 15.4.2 1つのビジネス・サービスに対するスロットルの無効化

- 15.5 ビジネス・サービスのグループに対するスロットルの構成

- 15.5.1 スロットル・グループの作成

- 15.5.2 ビジネス・サービスとスロットル・グループの関連付け

- 15.5.3 スロットル・グループの編集

- 15.5.4 スロットル・グループの削除

16 リシーケンサ表の管理

- 16.1 リシーケンサ・データベース表について

- 16.1.1 データベース表パージ・スクリプト

- 16.1.2 完了リシーケンサ・メッセージの自動パージ

- 16.1.3 リシーケンスのためのデータソース

- 16.1.4 パージ・スクリプトおよびリシーケンス・メッセージのパージ・ステータス

- 16.2 Oracle Service Busのリシーケンサ・データのパージ

- 16.2.1 完了メッセージを自動的にパージするためのリシーケンサの構成

- 16.2.2 SQLスクリプトを使用したリシーケンサ表のパージ

- 16.2.2.1 環境とスクリプトの設定

- 16.2.2.2 Oracle Service Busのパージ・プロシージャの実行

- 16.2.2.3 Service Busのパージ・スクリプトの実行

- 16.2.2.4 SOA Suiteのパージ・スクリプトの実行(ループ・モード)

- 16.3 サポートされないアクティブなリシーケンサの再構成

第V部 Oracle Service Busサービスのトラブルシューティング

17 実行トレースを使用した問題の診断

- 17.1 実行トレースについて

- 17.2 実行トレースの有効化および無効化

- 17.2.1 Oracle WebLogic Serverのログ・レベルの設定

- 17.2.2 1つのサービスに対する実行トレースの構成

- 17.2.3 複数のサービスに対する実行トレースの構成

- 17.3 実行トレースの情報へのアクセス

18 診断フレームワークを使用した問題の診断

- 18.1 Oracle Service Busの診断の理解

- 18.1.1 Oracle WebLogic診断フレームワーク

- 18.1.1.1 監視と通知

- 18.1.1.2 診断シナリオとMBean

- 18.1.2 Oracle Fusion Middleware診断フレームワーク

- 18.1.2.1 診断ダンプ

- 18.1.3 自動診断リポジトリについて

- 18.1.4 事前定義済のインシデント処理ルール

- 18.1.5 ダイナミック・モニタリング・サービス・メトリック

- 18.2 Oracle Service Bus診断ダンプの操作

- 18.2.1 使用可能な診断ダンプのリスト

- 18.2.2 派生リソースのキャッシュ診断のダンプ(OSB.derived-caches)

- 18.2.2.1 Oracle Service Bus派生リソースのキャッシュ

- 18.2.2.2 派生リソースのキャッシュ・ダンプの説明の表示

- 18.2.2.3 派生リソースのキャッシュ・ダンプの実行

- 18.2.2.4 派生リソースのキャッシュ・ダンプの出力例

- 18.2.3 JMS相関表診断ダンプ(OSB.jms-async-table)の実行

- 18.2.3.1 JMS相関表ダンプの説明の表示

- 18.2.3.2 JMS相関表ダンプの実行

- 18.2.3.3 JMS相関表ダンプの出力例

- 18.2.4 MQ相関表診断ダンプ(OSB.mq-async-table)の実行

- 18.2.4.1 MQ相関表ダンプの説明の表示

- 18.2.4.2 MQ相関表ダンプの実行

- 18.2.4.3 MQ相関表ダンプの出力例

- 18.3 RDAを使用した診断ダンプの生成

- 18.4 ADRツールを使用したインシデント・パッケージの表示

- 18.5 問題とインシデントの問合せ

付録

A JMXモニタリングAPI

- A.1 JMXモニタリングAPIについて

- A.2 JMXモニタリングAPIの使用

- A.2.1 公開POJOオブジェクト

- A.2.1.1 ResourceType

- A.2.1.2 ServiceResourceStatistic

- A.2.1.3 ResourceStatistic

- A.2.1.4 StatisticValue

- A.2.1.5 StatisticType

- A.2.2 ServiceDomainMBean

- A.2.3 MonitoringConfigurationMBean

- A.2.4 Oracle Service Busについて収集される統計

- A.2.4.1 リソース・タイプの統計の詳細 - SERVICE

- A.2.4.2 リソース・タイプの統計 - FLOW_COMPONENT

- A.2.4.3 リソース・タイプの統計の詳細 - WEBSERVICE_OPERATION

- A.2.4.4 リソース・タイプの統計の詳細 - URI

- A.2.5 注意事項

- A.2.6 パフォーマンス

- A.3 APIの使用方法の例

- A.3.1 サンプル・プログラム

B Oracle Service BusデプロイメントAPIの使用

- B.1 デプロイメントMBeanの概要

- B.2 プログラムとスクリプトを使用したセッションの管理

- B.2.1 セッションの作成、アクティブ化、破棄、検索

- B.3 プログラムとスクリプトを使用した構成タスクの管理

- B.3.1 構成のインポート、エクスポートおよび問合せ

- B.3.2 環境固有の情報の更新

C Oracle Service Busシステムの監査

- C.1 構成の変更の監査

- C.2 メッセージ・フローの監査証跡の作成

- C.3 セキュリティ違反の監査

D WSRPとの相互運用性

- D.1 WSRPのプロデューサとコンシューマ

- D.2 WSRPのアーキテクチャ

- D.2.1 Oracle Service Busを使用した拡張アーキテクチャ

- D.3 WSRP設計の概念

- D.3.1 WSRP WSDLドキュメント

- D.3.2 WSRPメッセージ

- D.4 WSRP対応Oracle Service Busの構成

- D.4.1 プロデューサWSDLドキュメントの取得

- D.4.2 WSRPプロデューサによるSSLの使用

- D.4.3 コンシューマとプロデューサの間でのメッセージのルーティング

- D.4.4 WSRPアプリケーションのモニター

- D.4.5 ロード・バランシングとフェイルオーバー

- D.4.5.1 セッション固定性を持たないWSRPの制限

- D.4.5.2 HTTPセッション固定性を持つWSRPの使用法

E Oracle Service Busでのロール・ベースのアクセス

- E.1 アプリケーション・セキュリティ・ロール

- E.1.1 Oracle Service Busコンソールでのアプリケーション・ロール・ベースのアクセス

- E.1.1.1 リソース・アクションへのアプリケーション・ロール・ベースのアクセス

- E.1.1.2 管理機能へのアプリケーション・ロール・ベースのアクセス

- E.1.1.3 セッション管理へのアプリケーション・ロール・ベースのアクセス

- E.1.2 Fusion Middleware Controlでのアプリケーション・ロール・ベースのアクセス

- E.2 エンタープライズ・セキュリティ・ロール

- E.2.1 Oracle Service Busコンソールでのエンタープライズ・ロール・ベースのアクセス

- E.2.1.1リソース・アクションへのエンタープライズ・ロール・ベースのアクセス

- E.2.1.2 管理機能へのエンタープライズ・ロール・ベースのアクセス

- E.2.1.3 セッション管理へのエンタープライズ・ロール・ベースのアクセス

- E.2.2 Fusion Middleware Controlでのエンタープライズ・ロール・ベースのアクセス

- E.3 ロール・ベースのセキュリティ構成アクセス

表一覧

- 1-1 サポート対象の標準と実装

- 1-2 Oracle WebLogicファミリ・プラットフォーム

- 1-3 Oracleファミリ・プラットフォーム

- 1-4 サード・パーティ・プラットフォーム

- 2-1 サンプル間隔

- 4-1 カウント統計の詳細

- 4-2 最大、最小および平均の統計の詳細

- 4-3 ステータス統計の詳細

- 5-1 Oracle Service Busサービスのメトリック

- 7-1 11gおよび12cのService Busのデバッグ・ログ出力

- 7-2 11gログ・レベルの12cへのマッピング

- 7-3 ODLへのメッセージ書式のマッピング

- 8-1 グローバル・レベルの操作設定

- 9-1 リソースの環境値

- 9-2 操作設定の環境値

- 11-1 Oracle Service Bus 11gのグループ

- 14-1 エンドポイントURIのステータス

- 18-1 Service Busセンサー

- 18-2 Service Bus診断ダンプ

- 18-3 JMS相関表診断ダンプ

- 18-4 Oracle Service Bus派生リソースのキャッシュ

- 18-5 JMS相関表診断ダンプ

- 18-6 MQ相関表診断ダンプ

- A-1 SERVICE統計

- A-2 FLOW_COMPONENT統計

- A-3 WEBSERVICE_OPERATION統計

- A-4 エンドポイントURIの統計

- B-1 セッション管理メソッド

- D-1 プロデューサ・サービス

- E-1 アプリケーション・ロール・ベースのリソースへのアクセス

- E-2 管理機能へのアプリケーション・ロール・ベースのアクセス

- E-3 セッション管理へのアプリケーション・ロール・ベースのアクセス

- E-4 Fusion Middleware Controlでのアプリケーション・ロール・ベースのアクセス

- E-5 リソース・アクションへのエンタープライズ・ロール・ベースのアクセス

- E-6 管理機能へのエンタープライズ・ロール・ベースのアクセス

- E-7 セッション管理へのエンタープライズ・ロール・ベースのアクセス

- E-8 エンタープライズ・ロール・ベースのモニターおよび管理アクセス

- E-9 ロール・ベースのセキュリティ構成アクセス

はじめに

ここでは、このガイド『Oracle Service Busの管理』の表記規則について説明します。

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

Oracleのアクセシビリティへの取り組みについては、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)にアクセスしてください。

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、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドで説明する新機能

リリース12.2.1.1.0では、このガイドに対する変更はありません。

既知の問題のリスト(リリース・ノート)については、http://www.oracle.com/technetwork/middleware/soasuite/documentation/soaknowissues12211-2873928.htmlのOracle SOA製品の既知の問題に関する説明を参照してください。

第I部 Oracle Service Bus管理の理解

この部では、Service Busの管理タスクを開始するために必要な基本情報および手順について説明します。

この部は、次の章で構成されています。

- 相互運用性、互換性およびシステム・サポート

- Oracle Service Bus管理について

- Oracle Service Bus管理のスタート・ガイド

1 相互運用性、互換性およびシステム・サポート

この章では、オラクル社およびサード・パーティの製品、プロトコル、Webサービス標準を含むOracle Service Busでサポートされている製品、標準およびテクノロジをリストします。

この章には、Oracle Service Busの相互運用性に関する情報も含まれています。次の項目が含まれます。

- サポートされているシステム構成

- Oracle製品との相互運用性および互換性

- サポート対象の標準と実装

- 相互運用性とサポートに関する制限事項

1.1 サポートされているシステム構成

テクニカル・サポートを受けるには、アプリケーションやプラットフォームを含めて、サポートされている環境にいる必要があります。ベンダーが製品のサポートをやめた場合、Oracleのテクニカル・サポート・サービスを継続して受けるには、現在の認証済のサポートされている製品、アプリケーション、ハードウェア・プラットフォーム、データベースおよびオペレーティング・システム構成の一部または全部をアップグレードする必要がある場合があります。

ベンダーのオペレーティング・システム、JDK、ハードウェアおよびデータベースのサポート情報については、http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlでOracle Fusion Middlewareのサポートされるシステム構成を参照してください。

1.2 Oracle製品との相互運用性および互換性

『相互運用性および互換性の理解』のガイドは、Oracleコンポーネントが、同じバージョンであるか違うバージョンであるかによって、相互にどのように連携するかを理解するのに役立ちます。このガイドには、サポート・マトリクスも記載されています。

詳細は、『相互運用性および互換性の理解』を参照してください。

1.3 サポート対象の標準と実装

Oracle Service Busでは、これらの標準と実装がサポートされます。

表1-1 サポート対象の標準と実装

標準/実装

バージョン

電子メール・サーバー

- Microsoft Windows IIS SMTPサーバー

- Sol/Apache SMTPサーバー

FTPサーバー

- Microsoft Windows IIS FTPサーバー

- Sol/Apache FTPサーバー

- ProFTPDサーバー

Webサービス

- WSDL 1.1

- SOAP 1.1および1.2

- SOAP with Attachments (SwA)

- XML-binary Optimized Packaging (XOP)を使用するSOAP Message Transmission Optimization Mechanism (MTOM)

- Universal Description, Discovery, and Integrationバージョン3 (UDDI v3)

- WS-ReliableMessaging 1.0、1.1および1.2

- WS-Addressing 1.0

- WS-AT 1.0、1.1および1.2

- XACML 2.0

- WS-Inspection

- Web Services Interoperability Basic Profile (WS-I BP) 1.1

- Web Services Interoperability Basic Security Profile (WS-I BSP) 1.0

セキュリティ

- Oracle Web Services Manager (OWSM)

- Oracle Platform Security Services (OPSS)ログイン・モジュール

EJB

- 2.1

- 3.0

SNMP

- SNMPv1

- SNMPv2c

WebLogic JMS

WebLogic Server

- 8.1 SP4-SP6

- 9.0, 9.1, 9.2

- 10.0

- 10.3.x

- 12.1.3

- 12.2.1

サード・パーティJMS

JMS仕様を実装するすべてのJMSプロバイダは、外部JMSプロバイダとしてOracle WebLogic Serverでサポートされています。

Microsoft .NET 1.1とSOAP 1.1の組合せ

スタイル・エンコーディング: ドキュメント・リテラル、RPCエンコード

- Oracle Service Busでは、ドキュメント・リテラルがサポートされ、.NETサービスと相互運用できます。

- Oracle Service Busは、着信および発信(ルーティングおよびパブリッシュ)時に、.NETのRPCエンコード・サービスと相互運用できます。この場合、パラメータのタイプに関係なく相互運用が可能です。

- Oracle Service Busサービス・コールアウトは、.NETのRPCエンコード・サービスと相互運用できない場合があります。

注意: DIME添付はOracle Service Busではサポートされません。

「.NETの相互運用性に関する制限事項」も参照してください。

Microsoft .NET 2.0とSOAP 1.1/SOAP 1.2との組合せ

2.0、3.0および3.5とSOAP 1.1/SOAP 1.2の組合せ

「.NETの相互運用性に関する制限事項」を参照してください。

WebLogic JMS Client for Microsoft .Net (.Net C#クライアント・アプリケーションの場合)

『Oracle WebLogic Server JMS .NETクライアント・アプリケーションの開発』のWebLogic JMS .NETクライアントの動作に関する項を参照してください。

Oracle Service Busは、次の表に示すプラットフォームと相互運用します。

表1-2 Oracle WebLogicファミリ・プラットフォーム

相互運用性

バージョン

WebLogicプラットフォームとのWS-*およびJMS相互運用性

- 8.1 SP4-SP6 (WS-Securityは除く)

- 9.0、9.1、9.2 (WS-Securityは除く)

- 10.0 (WS-Securityは除く)

- 10.3.x

- 12.1.3

- 12.2.1

Web Services for Remote Portlets (WSRP)とOracle WebLogic Portalの組合せ

- 9.2

- 10.0

- 10.2

- 10.3.x

Oracle WebLogic Portal

- 8.1 SP6

- 9.2

- 10.0

- 10.2

- 10.3

表1-3 Oracleファミリ・プラットフォーム

相互運用性

バージョン

Oracle Service Bus

- 3.0

- 10.3および10.3.1

- 11.1.1.3以降

- 12.1.3

- 12.2.1

Oracle Service Registry

11.1.1.6

Oracle Web Services Manager

- 10.1.3.x以降

- 11.1.1

- 12.1.3

- 12.2.1

Oracle BPEL Process Manager

- 10.1.3.4.x以降

Oracle JDeveloper

- 12.1.3

- 12.2.1

Oracle JCAアダプタ

- 12.1.3

- 12.2.1

Oracle Data Service Integrator

- 12.1.3

- 12.2.1

Oracle Tuxedo/WebLogic Tuxedo Connector

- 12.1.1

- 12.1.3

表1-4 サード・パーティ・プラットフォーム

相互運用性

バージョン

IBM WebSphere MQ

- 7.5

SOAP 1.2ではなく、SOAP 1.1でのサポート。「WebSphereの相互運用性に関する制限事項」を参照してください。

IBM WebSphere EJB/RMI

6.0

IBM WebSphere WS

6.1 (Fixpack 15)

SOAP 1.2ではなく、SOAP 1.1でのサポート。「WebSphereの相互運用性に関する制限事項」を参照してください。

JBoss Application Server

- 4.x

- 5.x

- 6.x

- 7.x

Tibco Enterprise Message Service

Oracle WebLogic ServerでJMS 1.2仕様を満たすすべてのバージョン

Apache Axis

- 1.2.1

- 1.4.1

SOAP 1.2ではなく、SOAP 1.1でのサポート。「Apache Axisの相互運用性に関する制限事項」を参照してください。

BMC Patrol

http://www.softwareinnovations.co.uk/products/patrol.html

1.4 相互運用性とサポートに関する制限事項

この項では、様々なプラットフォームでの相互運用性に関する制限事項について説明します。

- .NETの相互運用性に関する制限事項

- Apache Axisの相互運用性に関する制限事項

- WebSphereの相互運用性に関する制限事項

1.4.1 .NETの相互運用性に関する制限事項

- 基本認証を使用して、Oracle Service Busと通信する必要がある.NETクライアントは、最初のリクエストで認証情報を送信する必要があります。そうしないと、Oracle Service Busは.NETクライアントに資格証明を要求しないため、呼出しに失敗します。

- Oracle Service Busの基本認証を使用しての.NETとの相互運用性は、Windows 2003/IIS 6.0と構成されると正しく機能します。ただし、Windows XP/IIS 5.1上で基本認証を使用しての.NETとの相互運用性はサポートされません。

- .NETクライアントのメッセージ・レベルのセキュリティに関する相互運用性は、SOAP 1.1を使用した場合のみ機能します。WSE SOAPプロトコル・ファクトリでは、SOAP 1.2を使用したセキュリティはサポートされません。『Oracle Service Busでのサービスの開発』の「.Net 2.0とメッセージ・レベルのセキュリティ」を参照してください。

.NET Framework 1.1の次のセキュリティ構成は、Oracle Service Busメッセージ・レベルのセキュリティと相互運用できません。

- WebLogicから.NET WSE 2.0 (Webservices Security Extension)へのメッセージ本文の署名は相互運用できない。ただし、WSEはデフォルトで追加ヘッダー(WS-Addressingやtimestampなど)を要求する。このため、Oracle Service Busメッセージ・レベルのセキュリティを.NET Webサービスと相互運用できるようにするには、.NETセキュリティ・ポリシー構成からメッセージ本文以外のメッセージ述部をすべて削除する必要があります。

- Oracle Service Busと.NETを相互運用するには、リプレイ検出属性である<replayDetection>を.NET側でdisabledに設定する必要があります。

1.4.2 Apache Axisの相互運用性に関する制限事項

この項では、Apache Axisと連携して動作する際に発生する問題について説明し、それらの問題に対処するための方法も示します。

- Axisで生成されたRPCエンコードのWSDLドキュメントのインポート時に参照が解決されない

- Axisで生成されたWSDLファイルのSOAPAction属性が空の文字列に初期化される

- 一方向の操作のHTTPレスポンスとステータス・コード

- エラーが発生する一方向の操作のHTTPレスポンスおよびステータス・コード

1.4.2.1 Axisで生成されたRPCエンコードのWSDLドキュメントのインポート時に参照が解決されない

Axisで生成されたRPCエンコードWSDLファイルをOracle Service Busにインポートすると、解決の必要な参照がWSDLファイルに含まれることを示す警告メッセージが表示される場合があります。

この問題を回避するには、インポートされたWSDLファイルの構造ビューをOracle Service Bus管理コンソールの「WSDLの表示」ページで開き、未解決のスキーマ・インポートを表示します。「インポート」セクションに未解決のスキーマ・インポートが表示されます。

この問題は、Oracle Service Bus環境でWSDLファイルを使用する機能に影響しません。この警告が表示されないようにするには、WSDLファイルから未解決のスキーマを削除します。

1.4.2.2 Axisで生成されたWSDLファイルのSOAPAction属性が空の文字列に初期化される

Axisで生成されたWSDLファイルには、空の文字列に初期化されたSOAPAction属性が含まれます。このWSDLファイルを使用してOracle Service Busビジネス・サービスを構成すると、「SOAPActionがありません」エラーが発生して、このWebサービスへの呼出しが失敗します。

問題回避し、Oracle Service BusからAxisへのWebサービス呼出しが正常に行われるようにするには、パイプラインでトランスポート・ヘッダーを構成します。メッセージ・フロー・ルートにトランスポート・ヘッダーを設定リクエスト・アクションを追加し、「パイプラインを介してすべてのヘッダーを渡す」オプションを有効にします。

回避策を実施した場合でも、この問題によってOracle Service Busテスト・コンソールからの呼出しが失敗します(「SOAPActionがありません」エラーが発生します)。テスト・コンソールからの呼出しが機能するようにするには、メッセージ・フローのルートのトランスポート・ヘッダーを設定リクエスト・アクションにSOAPAction HTTPヘッダーを設定します。

1.4.2.3 一方向の操作のHTTPレスポンスとステータス・コード

ドキュメント・リテラル・タイプおよびRPCエンコード・タイプのWebサービスでは、一方向の操作を呼び出すと、ステータス・コード「202 OK」と共に空のHTTPレスポンスがAxisからクライアントへ送信されることが予期されます。しかし、Axisからは、ステータス・コード「200 OK」と共に、空でないHTTPレスポンスが送信されます。このHTTPレスポンスのBodyには、空のSOAPエンベロープが含まれます。その結果、予期された結果に反して、Oracle Service Busのプロキシ・サービスまたはビジネス・サービスからクライアントへ同じレスポンス・コード「200 OK」が送信されます。

1.4.2.4 エラーが発生する一方向の操作のHTTPレスポンスおよびステータス・コード

ドキュメント・リテラル・タイプおよびRPCエンコード・タイプのWebサービスでは、エラーが発生する一方向の操作を呼び出すと、ステータス・コード「202 OK」と共に空のHTTPレスポンスがAxisからクライアントへ送信されることが予期されます。しかし、Axisからは、ステータス・コード「500 Internal Server Error」と共に、空のSOAPエンベロープをBodyとする空ではないHTTPレスポンスが送信されます。その結果、予期された結果に反して、Oracle Service Busのプロキシ・サービスまたはビジネス・サービスからクライアントへ同じレスポンス「500 Internal Server Error」が送信されます。

1.4.3 WebSphereの相互運用性に関する制限事項

ドキュメント・リテラル・タイプおよびRPCエンコード・タイプのWebサービスでは、一方向の操作を呼び出すと、ステータス・コード「202 OK」と共に空のHTTPレスポンスがWebSphereからクライアントへ送信されることが予期されます。しかし、WebSphereからは、ステータス・コード「200 OK」と共に、空でないHTTPレスポンスが送信されます。このHTTPレスポンスのBodyには、空のSOAPエンベロープが含まれます。

その結果、予期された結果に反して、Oracle Service Busのプロキシ・サービスまたはビジネス・サービスからクライアントへ同じレスポンス・コード「200 OK」が送信されます。

2 Oracle Service Bus管理について

この章では、Oracle Fusion MiddlewareとOracle Service Busの概要、およびOracle Enterprise Manager Fusion Middleware ControlとOracle Service Busコンソールから実行できる管理タスクのタイプの概要について説明します。

この章の内容は次のとおりです。

- Oracle Fusion Middlewareの概要

- Oracle Service Busの概要

- Oracle Service Busの実行時モニター

- Oracle Service Busの実行時管理

- Oracle Service Busの実行時セキュリティ

- 集約間隔について

- サーバーのモニターと管理

- Oracle Service BusとOracle Enterprise Scheduler

2.1 Oracle Fusion Middlewareの概要

Oracle Fusion Middlewareは標準ベースのソフトウェア製品の集まりで、Java EEや開発ツールから統合サービス、ビジネス・インテリジェンスおよびコラボレーションまで、様々なツールやサービスが含まれます。

Oracle Fusion Middlewareは、アプリケーションの開発、デプロイおよび管理を完全にサポートします。Oracle Fusion Middlewareコンポーネントは、Oracle Enterprise Manager Fusion Middleware Controlコンソールを使用して実行時にモニターされます。

2.2 Oracle Service Busの概要

Oracle Service Busは、大規模なSOA環境に標準ベースの統合をもたらすOracle Fusion Middlewareのコンポーネントです。

Service Busは、Oracle SOA Suiteのコア・コンポーネントであり、SOAメッセージングのバックボーンとしての役割を果たします。Service Busは、企業全体のサービス・ネットワークにわたって異種サービス、レガシー・アプリケーション、パッケージ・アプリケーションおよび複数のEnterprise Service Bus (ESB)インスタンス間の相互作用を結合、仲介および管理します。Service Busは、大まかで緩やかに結合された標準ベースのサービスの構築と、ビジネス機能がサービス・コンシューマとバックエンド・ビジネス・サービスに接続できる中立コンテナの作成を、基盤となるインフラストラクチャとは無関係に行うというSOAの原則に基づいています。

2.2.1 サービスのモニターと管理について

Service Busには、モニター、アラート、レポート、構成および管理のための強力なランタイム・ツールのセットが含まれています。Service Busのモニター・フレームワークは、正常に処理されたメッセージまたは処理に失敗したメッセージの数、メッセージ処理の平均実行時間、生成されたエラーおよびアラートの数、平均レスポンス時間など、サーバー統計へのアクセスを提供します。Fusion Middleware Controlを使用することにより、現在の集約間隔のモニター統計を表示できます。また、このサービスの統計を最後にリセットした時点、またはすべてのサービスの統計を最後にリセットした時点以降の期間のモニター統計を表示できます。パブリックAPIを使用することにより、最後のリセット以降の統計だけにアクセスすることもできます。

2.2.1.1 管理コンソール

Service Busは、SOA全体を管理するためにFusion Middleware Controlと完全に統合されています。Service Busサービスのほとんどのモニターおよび管理タスクは、Fusion Middleware Controlを使用して実行されますが、一部の管理タスクでは、Oracle Service Busコンソールが必要です。

Fusion Middleware Controlでは、Service Busにより、サービス・ステータスおよび統計に関するクラスタ全体のビューを提供することで、SLAアラート、パイプライン・アラート、ログ、レポートおよびポリシー使用状況をモニターできるようにする操作関連機能および設定が提供されます。フレームワークは、ビジネス・サービス、プロキシ・サービス、パイプラインおよび分割-結合をモニターします。これには、レスポンス時間、メッセージ数、エラー数、セキュリティ・ポリシー使用状況と違反などが含まれます。Fusion Middleware Controlを使用して、トレースの有効化および無効化、サービスの有効化および無効化、ロギングおよびアラート・レベルの更新、およびリシーケンス・フォルトからのリカバリを実行することもできます。サービス・レベル・フラグとグローバル・フラグは、モニター、アラート、レポート、およびロギングの制御に役立ちます。

Oracle Service Busコンソールには、ビジネス・サービス・エンドポイント用のサービス・レベル・アグリーメントのアラート、パイプライン・アラート、メッセージ・レポート・アクション、アラート宛先、およびスロットル・グループを作成するための構成ツールが用意されています。コンソールを使用して、環境値を個別に、またはまとめて更新することもできます。

2.2.1.2 監査機能

Service Busには、サービスの監査とモニターのための次の機能があります。

- メッセージ呼び出し、エラー、パフォーマンス特性、渡されるメッセージおよびSLA違反について統計値を収集します。

- サード・パーティESMソリューションとの統合を可能にするため、SLAベースのアラートをSNMPトラップとして送信します。

- システム処理とビジネス監査の両方を目的として、メッセージの選択された部分をログに記録します。

- メッセージの主要情報を抽出して検索索引として使用する検索機能があります。

2.2.2 Oracle Service Busのモニター・フレームワークについて

モニター・フレームワークは、Service Busの操作リソース、サーバーおよびサービス・レベル・アグリーメント(SLA)をモニターします。図2-1に、モニター・フレームワークのアーキテクチャを示します。

図2-1 Oracle Service Busのモニター・フレームワーク

Service Busのモニター・アーキテクチャは、次のコンポーネントで構成されます。

- コレクタ: クラスタ内の管理対象サーバーがそれぞれコレクタをホストします。コレクタは、操作リソースの統計を一定の時間間隔で収集します。これは、RMIオブジェクト内で管理されます。また、集約間隔の時間が経過するまで、収集した統計の履歴も保持します。
Service Busランタイムは、コレクタを1分ごとに呼び出します。システム定義のチェックポイント間隔ごとに、コレクタは回復の目的で現在の統計のスナップショットを永続ストアに格納し、情報を未処理形式で集約機能に送信します。これは、未処理形式が高速収集および小フットプリント用に最適化されているためです。

注意:

操作リソースは、モニター・サブシステムにより統計情報を収集できる単位として定義されます。操作リソースには、プロキシ・サービス、ビジネス・サービス、パイプライン・コンポーネント、分割-結合コンポーネント、Web Services Definition Language (WSDL)オペレーションなどのサービス・レベル・リソース、エンドポイントURIなどがあります。

- 集約機能: 集約機能は、1つの管理対象サーバーにのみ存在します。この機能が存在するサーバーは、構成ウィザードを使用してドメインを生成する際に任意に選択されます。それは、クラスタ内のすべての管理対象サーバーを対象に、すべての管理対象サーバーから収集された統計をすべて集約します。
Service Busランタイムは、コレクタがデータを収集して集約機能に送信できるように、毎分25秒経過するたびに集約機能を呼び出します。システム定義のチェックポイント間隔ごとに、クラスタ内の各管理対象サーバーは統計のスナップショットを集約機能に送信します。集約機能のデータ構造は、データの集約および取得用に最適化されています。

- 取得機能: 取得機能は、メモリーに格納された統計を取得します。この機能は、集約機能を含む管理対象サーバーのみに存在します。

- アラート・マネージャ: アラート・マネージャは、集約統計に基づいてアラートを起動します。この機能は、集約機能を含む管理対象サーバーのみに存在します。

コレクタは、更新された統計をService Busランタイムから収集して、集約機能に送信します。集約機能は、集約間隔の間に統計を集約します。それらの統計はアラート・マネージャにプッシュされ、アラート・マネージャは統計に基づいてアラートをトリガーします。また、集約統計は格納され、取得機能によって取得できます。

2.2.3 JMX APIを使用した統計へのアクセス

サービスの統計情報には、Fusion Middleware Controlを使用してアクセスするか、Java Management Extensions (JMX)モニタリングAPIを使用して直接アクセスできます。JMXモニタリングAPIを使用する場合は、集計カウント統計のみにアクセスできます。JMXモニタリングAPIは、バルク操作のための効率的な下位サポートを提供します。JMXモニタリングAPIの使用方法の詳細は、「JMXモニタリングAPI」を参照してください。

2.2.4 クラスタにおける統計へのアクセス

クラスタ環境では、管理対象サーバーで収集されたすべての統計が集約機能にプッシュされます。統計は、個々の管理対象サーバー・レベルおよびクラスタ・レベルで使用できます。クラスタまたは個々の管理対象サーバーの統計を表示するには、「サービス・ヘルス」ページで「クラスタ」を選択するか、「サーバー」リストから管理対象サーバーの名前を選択します。

2.3 Oracle Service Busの実行時モニター

Service Busでは、ランタイム統計を集約することにより、システム操作に必要な実行時の情報をモニターおよび収集できます。

管理者は、リアルタイムに統計を表示して、システムの操作状態をモニターし、メッセージ・サービスにおける問題にフラグを付けることができます。これにより、問題が発生したら、それらをすばやく分離および診断することが可能になります。さらに、サービス・レベル・アグリーメント(SLA)のアラート、パイプライン・アラートおよびメッセージ・レポートを構成して、一定の条件のもとでアラートまたはイベント・ログをトリガーすることができます。Fusion Middleware Controlには、ログ出力およびログ・レベルのための構成ツールに加えて、コンソールで直接ログ・エントリを表示できる機能があります。次の各項では、Service Busのモニター機能について説明します。

2.3.1 サービス・ヘルスのモニター

システムの操作状態に関する情報を、サーバー、プロジェクトおよび個々のサービス・レベルで表示できます。Service BusドメインおよびService Busプロジェクトの「サービス・ヘルス」ページに、ドメインまたはプロジェクトの各サービスに対して集約された統計が表示されます。個別のサービス・ダッシュボードには、よりきめ細かい分析のために、操作レベルのパフォーマンス統計も表示されます。パイプラインおよび分割-結合のために、メッセージ・フロー内のコンポーネントについてパフォーマンス統計を収集できます。

統計は、すべてのService Busサービスに対して収集されます。モニター・システムでは、次のタイプの統計がサポートされています。

- カウンタ: 受信メッセージの数、生成されたエラーの数、フェイルオーバーの数など、実行時のイベントの数を追跡します。整数値を使用するスカラーです。

- Interval: 適切に定義された2つのイベント間の経過時間を追跡します。これは、こうしたイベントの実行時の合計、平均、最小値および最大値を追跡します。整数値および非整数値を使用します。

- ステータス・タイプ: ステータス統計でサービスのステータスを追跡します。これにより、オブジェクトの初期ステータスと現在のステータスを追跡できます。

収集される様々な統計のタイプの詳細は、「JMXモニタリングAPIの使用」を参照してください。サービス・ヘルスのモニターの詳細は、「Oracle Service Busのサービス・ヘルスのモニター」を参照してください。

2.3.1.1 メトリックの集約

表示される状態統計は、システム処理時に収集されるデータの非同期集約に基づきます。本番クラスタ・ドメインでは、データ集約機能はクラスタ内のいずれかの管理対象サーバー上でシングルトン・サービスとして実行されます。サーバー固有のデータ集約は、ドメインの各管理対象サーバーで実行されます。集約機能は、一定間隔(構成可能)ですべての管理対象サーバーからデータを収集および集約します。これらのメトリックは、構成された集約間隔でクラスタ全体で集約され、Fusion Middleware ControlのService Busのページに表示されます。

2.3.1.2 名前が変更されたサービスまたは移動されたサービスのモニター

サービスの名前を変更またはサービスを移動すると、収集されたすべてのモニター統計は失われます。現在の集約間隔と累積のメトリックはすべてリセットされ、サービスは最初からモニターされます。サービスのエンドポイントURIがオフラインとしてマークされている場合、そのサービスに対して名前変更または移動を行うと、URIは再びオンラインとしてマークされ、URIの状態はオンラインとして表示されます。

2.3.2 SLAアラートおよびパイプライン・アラートのモニター

サービス・レベル・アグリーメント(SLA)のアラートおよびパイプライン・アラートは、特定のサービスに対して構成されます。その目的は、それらのサービスを通じてメッセージがどのように処理されるかに関する情報を生成することです。SLAアラートは、サービス・レベル・アグリーメントに対する違反の可能性を示すために発生します。SLAアラートの一般的な使用方法のいくつかを次に示します。

- WS-Securityエラーをモニターし、電子メール通知を生成します。

- 特定のパイプラインを通過するメッセージ数をモニターします。

- サード・パーティ製品によるサービス・レベル・アグリーメントの違反を検出します。

- 応答していないエンドポイントを検出します。

パイプライン・アラートは、アラート・アクションを使用してパイプラインで直接定義されます。パイプライン・アラートは通常、メッセージ・フロー内のエラーを検出したり、ビジネス・イベントを示したりするために使用されます。アラートの作成およびモニターの詳細は、「Oracle Service Busのアラートのモニター」を参照してください。

2.3.2.1 SLAアラートの概要

サービス・レベル・アグリーメント(SLA)は、Service Bus内のサービスで予期される正確なサービス・レベルを定義します。SLAアラートは、SLAのルールと条件への違反に対するレスポンスを自動化したものです。Service Busは、集約されたモニター統計に対してSLAルールを実行し、ルール違反が見つかったらアラートを発生させます。それらのアラートをモニターした後、必要に応じてサービスを有効または無効にすることができます。管理者は、次の条件にサービス・レベル・アグリーメント(SLA)を設定できます。

- メッセージの処理回数。

- メッセージの処理ボリューム。

- エラー、セキュリティ違反、および検証エラーの数。

- 失敗率および成功率。

- ビジネス・サービスの場合のみ、エンドポイントURIのステータス。

SLAアラートは、Service BusダッシュボードとFusion Middleware Controlの「アラート履歴」ページの両方に表示されます。SLAアラートが発生すると、Service Busはまた、そのアラート・ルールに定義されているアラート宛先に通知を送信します。Service BusでSLAアラートを発生させるには、SLAアラートがサービス・レベルとグローバル・レベルの両方で有効になっている必要があります。

Oracle Service Busコンソールには、SLAアラート・ルールを作成し、アラートが発生する条件を定義するためのエディタがあります。アラート・ルールでは、ビジネスおよびパフォーマンスの要件に従って、許容できないサービス・パフォーマンスを指定します。アラート・ルールごとにそのルールの集約間隔を指定できます。この間隔は、サービスに設定された集約間隔の影響を受けません。

2.3.2.2 パイプライン・アラートの概要

Service Busでは、SLAアラートに加えて、パイプラインのメッセージ・フロー内で構成可能なアラート・アクションも提供されています。パイプライン・アラートは通常、メッセージ・パイプラインを通過するメッセージの数の記録、特定のビジネス・イベントのオカレンスの追跡、(システムの状態ではなく)エラーのレポートなど、ビジネス目的で使用されます。パイプライン・アラート・アクションは、パイプライン内のメッセージ・コンテキストに基づいてアラートを生成します。また、アラート名、説明(メッセージ要素を含めることが可能)、アラート宛先およびアラート重大度を含めるように構成できます。

Service Busは、パイプライン内でアラート・レポート・アクションに到達し、かつそのアクションに定義されている条件が満たされると、パイプライン・アラートを生成します。XQuery式などのパイプライン・エディタで使用できる条件構文やif-then-else構文を使用して、パイプライン・アラートをトリガーする条件を定義します。パイプライン・アラートが発生すると、Service Busは、そのアラート・アクションに定義されているアラート宛先に通知を送信します。

パイプライン・アラートは、Service BusダッシュボードとFusion Middleware Controlの「アラート履歴」ページの両方に表示されます。Oracle Service BusコンソールまたはJDeveloperのエディタを使用して、パイプライン・アラートを定義します。

2.3.3 リシーケンス・グループのモニター

Service Busパイプラインは、リシーケンサを使用するように構成できます。リシーケンサは、ランダムな順序で到着するメッセージを、使用されるリシーケンサのタイプに基づいて新しい順序に並べ替えます。「リシーケンス・メッセージ」ページに、リシーケンス・メッセージの状態に関する情報が表示されるので、実行時のリシーケンサのステータスをモニターおよび管理できます。グループ名、パイプラインの場所またはリシーケンス・グループのステータスに基づいて、表示するリシーケンス・グループを検索できます。検索結果でグループIDをクリックすると、そのグループに関する詳細情報が「リシーケンス・グループ」ダイアログに表示されます。

グループ・ダイアログに表示される情報は、グループのステータスによって異なります。グループでフォルトまたはタイムアウトが発生している場合、フォルトになったメッセージをリカバリするか、次に使用可能なメッセージにスキップすることができます。「リシーケンス・グループ」ダイアログには、グループに関する次の情報が表示されます。

- グループがタイムアウトになっているのか、フォルトになっているのか。

- グループ内のブロッキング・メッセージ(ある場合)。

- グループのロックが解除された後に処理される、次のメッセージ。

- グループ内のメッセージの処理が停止されてからの経過時間。

- グループのロックを解除するための手順説明。

フォールトまたはタイムアウトのためにグループ内のメッセージの処理が中断した場合、ダイアログには、中断したグループに関する情報が表示されます。リシーケンス済メッセージのモニターの詳細は、「リシーケンス・グループのモニター」を参照してください。

2.3.4 ログ・ファイルのモニター

Service Busコンポーネントは、すべてのタイプのイベントを記録するメッセージを含むログ・ファイルを生成します。これには、起動およびシャットダウン情報、エラー、警告メッセージ、HTTPリクエストに関するアクセス情報などの詳細情報が含まれます。Service Busは、Oracle Diagnostic Logging (ODL)を使用して、診断ログ・ファイルの標準フォーマット、コンテンツおよびファイル処理を定義します。ロギングの標準アクションに加えて、Service Busは、ログ・アクションがあり、かつロギングが有効である任意のパイプラインおよび分割-結合に対して、診断ログ・ファイルにエントリを追加します。管理者は、Fusion Middleware Controlの「ログ・メッセージ」ページにこの情報を表示できます。Fusion Middleware Controlには、構成ツールも用意されており、使用するログ出力および各ログ出力のログ・レベルを指定できます。

ロギングの詳細は、「ログ・ファイルの構成とモニター」を参照してください。

2.3.5 メッセージ・レポート

パイプライン内で構成されているレポート・アクションにより、メッセージがパイプラインを通過すると、メッセージ・データについてのレポートが生成されます。レポート・アクションは、リクエストまたはレスポンス・パイプライン、あるいはエラー・パイプライン・ステージ内の任意のポイントに配置でき、アクションによって生成される各レポート・エントリに書き込む各メッセージに関する情報を指定できます。レポート・アクションを使用して、メッセージがパイプラインを通過する際に、メッセージ情報をフィルタすることができます。レポート・アクションによって取得されたデータは、Fusion Middleware Controlでのモニターまたはレポート・プロバイダによるアクセスが可能です。レポート・アクションは、問題がメッセージの変換前と変換後のどちらにあるのか、ルーティング中にあるのかなどを判断する場合に役立ちます。

Fusion Middleware Controlの「メッセージ・レポート」ページには、サマリー情報も含めて、レポート・データ・ストアの情報が表示されます。サマリー情報を開いて、特定のメッセージに関する詳細情報を表示できます。Service Busには、組込みのJMSレポート・プロバイダや独自のレポート・プロバイダの作成に使用できるJava APIなど、追加のメッセージ・レポート用ツールが用意されています。JMSレポート・プロバイダによってレポートされたデータが取得され、レポート・データ・ストアの役割を果たすメッセージ・レポート・データベースに格納されます。

モニター、SLAアラートおよびレポート機能を組み合せて使用して、リアルタイムでサービス・インフラストラクチャの状態と可用性を管理すること、SLA準拠を評価すること、およびこの情報を効果的かつ効率的にレポートすることが可能になります。

メッセージ・レポートの詳細は、「メッセージおよびアラートのレポートの構成」を参照してください。

2.4 Oracle Service Busの実行時管理

実行時のService Busサービスのモニターに加えて、実行中のサービスを管理することもできます。管理タスクには、環境値のカスタマイズ、操作設定の構成、ビジネス・サービスのエンドポイントURIの管理、サービスのインポートとエクスポートなどがあります。

次の各項では、Fusion Middleware Controlを使用して実行できる管理タスクについて説明します。

2.4.1 環境のカスタマイズ

Service Busは、環境変数および環境値を使用して、あるドメインから別のドメインに(たとえば、テストから本番に)構成を移動する際に変更される可能性があるService Bus構成内のプロパティを表します。これらのプロパティを環境値として表すことで、各Service Busリソースで値を個別に変更することなく、サーバー名、ポート番号、ディレクトリ名、再試行構成などを変更できます。よい例は、プロキシ・サービスのURLです。これは、ドメインの物理的な場所によって変わります。環境値は、アラート宛先、プロキシ・サービス、ビジネス・サービス、SMTPサーバーとJNDIプロバイダのリソース、UDDIレジストリ・エントリおよびトランスポートに含まれます。

Service Busには、ドメイン内の環境値を更新するための2つの方法があります。Oracle Service Busコンソールの「検索置換」ダイアログを使用して環境値を更新するか、各環境値の値を定義する構成ファイルを作成して実行できます。「検索置換」を使用する場合、環境値全体の置換または値のサブ文字列のみの置換が可能です。後者は、小規模な変更を行う場合に役に立ちます。構成ファイルを使用して、すべての環境変数の直接変更、文字列またはサブ文字列の検索と置換、グローバル・レベルおよびサービス・レベルの操作設定の更新、およびリソース間のリファレンスの更新を行えます。

詳細は、「Oracle Service Bus環境のカスタマイズ」を参照してください。

2.4.2 ランタイム構成

操作設定では、サービスの状態、およびそれをFusion Middleware Controlでどのようにモニターできるかが制御されます。サービス・レベルまたはグローバル・レベルで次の機能を有効または無効にするように、操作設定を構成します。サービス・レベルの操作設定は、グローバル・レベルの設定によってオーバーライドされます。

- サービスの状態

- モニター、ロギングおよびレポート

- 集約間隔

- SLAアラートおよびパイプライン・アラート

- 実行およびメッセージ・トレース

- 応答しないエンドポイント

- スロットル

- 結果キャッシュ

- リシーケンサ処理

さらに、メッセージの同時処理を制限したり、スロットル・キュー内のメッセージの最大数を設定したり、メッセージがスロットル・キュー内にとどまることのできる最長時間を設定したりすることができます。

2.4.3 ビジネス・サービス・エンドポイントの管理

実行時、各ビジネス・サービス・エンドポイントURIのメトリックをモニターして、それらがすべて予期したとおりに実行されていることを確認できます。エンドポイントURIに問題があることがわかった場合、Service Busでは、URIエンドポイントをオフラインとしてマークすることで、そのエンドポイントURIへのアクセスが繰り返し試行されることを回避できます。また、応答しないURIを自動的にオフラインとしてマークするように、ビジネス・サービスを構成することもできます。

応答しないURIをオフラインとしてマークするようにビジネス・サービスを構成することで、応答しないURIにビジネス・サービスが繰り返しアクセスを試行することが回避され、その結果、応答しないURIへのアクセスの試行による通信エラーの発生を防ぐことができます。エンドポイントURIがオフラインとしてマークされた場合、Service Busは、指定された時間の経過後にオンラインに戻すことも、手動でステータスを変更するまでオフラインのままにしておくこともできます。

エンドポイントURIの管理の詳細は、「ビジネス・サービスのエンドポイントURIのモニターおよび管理」を参照してください。

2.4.4 エンドポイント・スロットルによるパフォーマンスのチューニング

Service Busには、ビジネス・サービスまたはビジネス・サービスのグループへのメッセージ・トラフィックを制限する機能があります。これにより、ビジネス・サービスに対する負荷を制御することが可能になります。スロットルは、トラフィックの多いビジネス・サービスでのメッセージの過負荷を防ぐことによって、パフォーマンスおよび安定性の向上に役立ちます。Service Busは、スロットル・キューを使用します。ビジネス・サービスによって処理されているメッセージの数が、許可されている同時メッセージの最大数に達すると、メッセージはスロットル・キューに格納されます。同時に処理できるメッセージの数、キュー内のメッセージの最大数、およびメッセージがキュー内にとどまることのできる時間を構成します。メッセージは、キューから優先度の順に処理されます。優先度は、ルーティング・オプションを使用して割り当てることができます。

個々のビジネス・サービスにスロットルを割り当てることができます。または、ビジネス・サービスのグループをスロットル・グループに割り当てることで、ビジネス・サービスのグループにスロットルを割り当てることができます。スロットル・グループは、複数のビジネス・サービスが同じサーバーにリクエストを送信する場合に役立ちます。スロットルを設定することで、そのサーバーへのメッセージのフローを制御し、メッセージのボリュームがサーバーの容量を超えないようにすることができます。グループの構成は、そのグループに割り当てられているすべてのサービスに適用されます。

詳細は、「メッセージ・スロットル用にビジネス・サービスを構成する方法」を参照してください。

2.4.5 リソースのインポートとエクスポート

Service Busのインポートおよびエクスポート機能により、異なるランタイム環境間で、プロジェクトとリソースを共有および更新できます。Fusion Middleware Controlで、構成JARファイル全体またはJARファイルに含まれているリソースのサブセットのみをインポートおよびエクスポートできます。構成JARファイルには、Service Busインスタンスから以前にエクスポートされたプロジェクトまたはリソースが含まれます。構成ファイルのインポートにより、既存のリソースを更新または削除したり、新しいリソースを構成に追加したりすることができます。

Service Busリソースをインポートする際、「環境のカスタマイズ」で説明されているとおり、作業しているドメイン固有の環境値を定義する構成ファイルもインポートできます。

詳細は、「Oracle Service Busリソースのインポートとエクスポート」を参照してください。

2.4.6 診断

Service Busは、Oracle WebLogic ServerおよびOracle Fusion Middlewareの診断およびレポート・ツールを活用して、実行時の問題の検出、診断および解決を支援します。WebLogic診断フレームワーク(WLDF)は、診断データを取得し、特定の条件が満たされた場合は、ログをモニターし、通知を送信できます。Oracle Fusion Middleware診断フレームワークは、コードの不具合、データの破損、デッドロックされたスレッド、一貫性のない状態など、クリティカル・エラーを対象としています。フレームワークによって関連する診断のダンプが取得され、管理者はそれを表示および分析できます。

自動診断リポジトリ(ADR)は、トレースやダンプなど、Oracle Fusion Middlewareコンポーネントのすべての診断データを格納します。Oracle Dynamic Monitoring Service (DMS)は、管理ツールにメトリック、トレース・イベントおよびシステム・パフォーマンス情報を提供します。

これらのツールをどのように連携して診断情報を提供するかについては、「診断フレームワークを使用した問題の診断」を参照してください。

2.5 Oracle Service Busの実行時セキュリティ

実行時のセキュリティ管理には、サービスのポリシー、ポリシー使用状況およびポリシー違反のモニターが含まれます。

Fusion Middleware Controlでは、Service Busユーザーおよびサービス・クライアントの認証および認可を定義することにより、管理セキュリティも定義できます。

2.5.1 セキュリティ・ポリシーの使用

Service Busは、標準のFusion Middleware Control機能を使用して、実行中のビジネス・サービスおよびプロキシ・サービスにアタッチされたセキュリティ・ポリシーをモニターおよび管理します。ポリシーは、それらのサービスを管理および保護するためのフレームワークを提供します。ポリシーのモニターおよび管理には、次のようなタスクがあります。

- サービスからのポリシーのアタッチとデタッチ。

- ポリシー・オーバーライドの更新。

- ポリシー・セットのグローバルなアタッチ。

- ポリシー使用状況のモニター。

- ポリシー違反のモニター。

Oracle Service BusコンソールとFusion Middleware Controlの両方で、個別のサービスのポリシーを構成できます。詳細は、「セキュリティ・ポリシーのモニターと管理」を参照してください。

2.5.2 セキュリティ管理の定義

認証と認可のために、Service Busは、Oracle Platform Security Services (OPSS)に基づいて構築されているOracle Application Development Framework (ADF)セキュリティを使用します。Service Busは、Fusion Middleware Controlのセキュリティ機能を使用して、ユーザー、ロールおよびグループを作成し、セキュリティ権限を割り当てます。Service Busには、デフォルトのアプリケーション・ロール・セットが用意されており、作成したユーザーにそれを割り当てることで、特定のリソースの作成、ランタイムのモニター、リソースのデプロイなど、Service Bus機能への標準的なアクセス権限セットをユーザーに付与できます。インバウンド・トランスポート・レベルのセキュリティおよびメッセージ・レベルのセキュリティでは、定義した条件に基づいてインバウンド・クライアント・リクエストを認証するためにService Busユーザー、グループ、およびロールのデータも使用されます。

詳細は、「Oracle Service Busのアクセス・セキュリティの定義」を参照してください。

2.6 集約間隔について

Service Busでは、モニター・サブシステムが集約間隔の間に統計を収集します。集約間隔とは、統計データが収集され、Fusion Middleware Controlに表示されるまでの時間です。

集約間隔に基づいていない統計には意味がありません。適切に定義された集約間隔中に収集される統計以外に、累積統計を収集することもできます。

2.6.1 モニター・データのリフレッシュ間隔

集約間隔とは、常に分、時間、または日単位の時間間隔を表す移動時間枠です。集約間隔は、無限レベル(精度)ではなく、サンプル間隔と呼ばれる一定の時間間隔で移動します。これにより、集約間隔の円滑な移動と正確な統計の生成が可能になります。

図2-2 集約間隔とサンプル間隔の説明

図2-2は、集約間隔の説明です。たとえば、集約間隔A1が5分に設定され、集約間隔A2が10分に設定されているとします。この場合、ランタイムでは、集約間隔A1を使用するサービスの統計が1分ごと(S1)に収集されます。統計は、集約間隔の最後に集約されます。

同様に、集約間隔A2の統計は5分ごと(S2)に収集されます。間隔S1およびS2は、この後説明するように、サンプル間隔と呼ばれます。

2.6.2 集約間隔におけるサンプル間隔

Service Busランタイムの統計は、各集約間隔において一定の間隔で計算されます。このような一定のサブ間隔は、サンプル間隔と呼ばれます。サンプル間隔の期間は、集約間隔によって異なります。表2-1は、様々な集約間隔に対するサンプル間隔の長さを示します。

表2-1 サンプル間隔

集約間隔

サンプル間隔

1、2、3、4および5分

1分

10、15、20、25および30分

5分

40、50、および60分

10分

90および120分

30分

3、4、5および6時間

1時間

8、10および12時間

2時間

16、20および24時間

4時間

2、3、4、5、6、および7日

1日

2.6.3 集約間隔のプロパティ

集約間隔には次のプロパティがあります。

- 1つの集約間隔中のサービスについてのみ統計を追跡できます。

- 集約間隔には任意の値を設定できません。リストに示された値を1つ選択する必要があります。

- サービス用の集約間隔およびアラート・ルール用の集約間隔を設定できます。

- 指定できる集約間隔は7日以下に制限されます。

サービスの集約間隔を変更すると、現在の集約間隔におけるサービスの統計がリセットされます。ただし、集約間隔を変更しても、サービスのエンドポイントURIのステータスに影響はありません。また、集約間隔を変更しても、サービスの実行数のメトリックはリセットされません。

2.6.4 統計のリセット

Oracle Service Busコンソールでサービスの統計をリセットすると、最後のリセット以降にサービスに対して収集された統計がすべて失われます。このアクションは、元に戻せません。エンドポイントURIのステータスは、統計をリセットしてもリセットされません。

2.7 サーバーのモニターと管理

Fusion Middleware Controlには、Service Busサーバーの状態に関する情報が表示されるため、Service Bus環境およびデプロイ済のアプリケーションのヘルスとパフォーマンスをモニターできます。

コンソールには、ドメイン、クラスタ、管理および管理対象サーバー、システム・コンポーネントおよびアプリケーションの状態に関する情報が表示されます。また、Fusion Middleware Controlからサーバーを起動および停止することもできます。詳細は、Oracle Fusion Middlewareの管理の「Oracle Fusion Middlewareのモニタリング」を参照してください。

2.8 Oracle Service BusとOracle Enterprise Scheduler

Oracle Enterprise Schedulerを使用して、ジョブを定義、スケジュールおよび実行できます。ジョブは、アプリケーションのために実行される作業の単位です。Oracle Enterprise SchedulerがService Busとともにインストールされる際、タスクを実行するためのジョブを作成し、スケジューラをトリガーする頻度を示すスケジュールを定義できます。

たとえば、Oracle Enterprise Schedulerを使用して、Webサービス・インタフェースでService Busプロキシ・サービスをスケジュールすることができます。Oracle Enterprise ScheduleをService Busとともに使用するために、次のテンプレートをService Busドメインにデプロイする必要があります。

- Oracle Enterprise Scheduler Service Basic

- Oracle Enterprise Manager Plugin for ESS

Fusion Middleware Controlでジョブを定義できます。詳細および手順については、次のドキュメントを参照してください。

- 『Oracle Enterprise Schedulerの管理』の「Oracle Enterprise Schedulerの概要」

- 『Oracle Enterprise Schedulerの管理』の「Oracle Enterprise Schedulerジョブの作業の管理」

- 『Oracle Enterprise Schedulerアプリケーションの開発』のWebサービス・ジョブ定義の作成に関する項

注意:

Service Busプロキシ・サービス用にジョブの定義またはスケジュールを作成する場合は、「パッケージ」フィールドに/oracle/apps/ess/custom/osbを指定する必要があります。

3 Oracle Service Bus管理のスタート・ガイド

この章では、Fusion Middleware Controlのメニューにログインし、メニュー内を移動して、Oracle Service Busの構成、モニターおよび管理タスクを実行する方法について説明します。また、コンソール内で使用できるService Bus管理ページについても説明します。

この章の内容は次のとおりです。

- 管理およびモニター・ページについて

- Oracle Enterprise Manager Fusion Middleware Controlへのログイン

- Oracle Service Bus管理ページへのナビゲート

- システムMBeanブラウザへのナビゲート

- アクセシビリティ・オプションの設定

- Oracle Enterprise Manager Fusion Middleware Controlからのログアウト

- Oracle Service Busサーバーの起動

Fusion Middleware Controlの標準的な機能およびタスクの詳細は、Oracle Fusion Middlewareの管理を参照してください。

3.1 管理およびモニター・ページについて

Fusion Middleware Controlで、Service Busアプリケーションとそのライフサイクルをモニターおよび管理できます。Oracle JDeveloperまたはOracle Service Busコンソールで設計されたService BusアプリケーションをService Busドメインにデプロイします。Fusion Middleware Controlは、デプロイされたアプリケーションについて収集された情報にアクセスします。

Service Busでは、ランタイム統計が集約され、「ダッシュボード」、「アラート履歴」および「サービス・ヘルス」ページで表示できます。ダッシュボードでは、システムの状態をモニターし、サービスでアラートが生成された場合に通知を受けることができます。この情報を使用すると、時間をかけずに簡単に、発生した問題を特定し、診断できます。

Service Busのモニターおよび管理機能は、サービス・レベル、プロジェクト・レベルおよびドメイン・レベルの情報とタスクに分類されます。Fusion Middleware ControlのService Busドメイン・ページでは、ドメイン・レベルの情報が表示され、サービス・レベルとグローバル・レベルの両方で操作設定を設定できます。Service Busプロジェクト・ページでは、プロジェクト内のすべてのサービスのヘルスが表示され、サービス・レベルで操作設定を設定できます。サービス・コンポーネント・ページでは、選択したサービスの状態に関する情報が表示され、そのサービスの操作設定を更新できます。また、ポリシーのアタッチとデタッチ、ビジネス・サービスとプロキシ・サービスのためのポリシー・オーバーライド値の定義、およびビジネス・サービスのためのエンドポイントURIの管理も行うことができます。

3.1.1 Service Busのドメイン・レベルのモニター・ページ

Service Busホーム・ページでは、パイプライン・アラートおよびSLAアラートのモニター、個別のサービスのヘルスのモニター、リシーケンス済メッセージのフォルトの表示、グローバル設定および操作設定の更新など、管理タスクを実行できます。フォルト・リカバリなどの修正処理も実行できます。Fusion Middleware Controlには、プロキシ・サービス、ビジネス・サービス、パイプライン、分割-結合など、デプロイされているすべてのサービスに関する情報が表示されます。表示される情報のレベルは、各サービスに対して操作設定がどのように構成されているか、およびグローバル・レベルで構成されているかどうかによって異なります。

3.1.1.1 ダッシュボード(ドメイン・レベル)

Service Busダッシュボードには、SLA違反またはパイプライン・アラートの結果として、Service Busランタイムでトリガーされたすべてのアラートが表示されます。サービス・レベル・アグリーメント(SLA)は、Service Bus内のビジネス・サービスやプロキシ・サービスで予期されるサービス・レベルを定義します。パイプライン・アラートは、メッセージ・パイプラインを通過するメッセージの数を記録するなど、特定のビジネス・イベントの発生の追跡や(システムの状態ではなく)エラーの報告のために、ビジネス目的のメッセージ・フローに定義されます。

アラート履歴表の各行には、重大度、タイムスタンプ、関連サービスなど、アラート・ルールに対して構成されている情報が表示されます。「アラート名」リンクをクリックすると、「アラート詳細」ダイアログが表示され、SLAアラートに関する詳細情報が示されます。「アラート・サマリー」リンクをクリックすると、パイプライン・アラートの「アラート詳細」ダイアログが表示されます。これは、SLAアラートまたはパイプライン・アラートの原因を分析する際に役立ちます。また、各アラートを生成したアラート・ルールの構成が読取り専用で表示されます。

ダッシュボードには、最も多くのアラートが発生したService Busサービスおよび最も多くのエラーがあるサービスがリストされます。アラートまたはエラーをクリックすると、アラートやエラーの原因の分析および修正に役立つ詳細情報が表示されます。エラーのあるサービスの場合、ダッシュボードには、サービスの平均レスポンス時間、処理されたメッセージの数、エラーの数などの詳細情報が表示されます。

次のイメージは、Service Busダッシュボードを示しています。詳細は、「Oracle Service Busのアラートのモニター」を参照してください。

図3-1 Fusion Middleware Controlの「Service Bus」の「ダッシュボード」ページ

3.1.1.2 アラート履歴

「アラート履歴」ページには、検索機能が用意されており、アラート・タイプ、アラート・ルールまたはアラート重大度に基づいてアラートを検索することができます。特定のサービスまたは特定の日付範囲のアラートを検索することもできます。「アラート履歴」ページに表示される情報は、ダッシュボードで提供される情報と似ていますが、検索機能により、興味のあるアラートまたはサービスのみを表示することが可能になります。検索結果リストには追加のリンクがあります。それらを使用して、アラートに関する詳細情報を表示したり、アラートが生成されたサービスの「ダッシュボード」ページにナビゲートしたり、アラートを生成したアラート・ルールを表示したりすることができます。

「アラート履歴」ページのパージおよび削除機能を使用して、アラート・ストアのサイズを管理します。すべてのアラートをパージしたり、特定の期間内に生成されたアラートのみをパージしたりすることができます。

次の図は、「アラート履歴」ページを示しています。詳細は、「Oracle Service Busのアラートのモニター」を参照してください。

図3-2 「Service Bus」の「アラート履歴」ページ

3.1.1.3 サービス・ヘルス

現在の集約間隔の統計を表示すると、Service Busの「サービス・ヘルス」ページに、デプロイ済の各サービスについて収集された統計データの動的ビューが表示されます。この表示は一定の間隔で更新されて、集約間隔のアラートのみが表示されます。たとえば、特定のサービスの集約間隔が20分である場合、このページには、直前20分間に収集されたそのサービスのデータが表示されます。

表示する特定のサービスまたはサービスのグループを検索できます。サービス表には、アラート、メッセージおよびエラーの数や平均レスポンス時間など、検索で返される各サービスの統計が表示されます。集約間隔はサービスに対して個別に構成できるので、表には各サービスの集約間隔も表示されます。

次の図はドメインレベルの「サービス・ヘルス」ページを示しています。詳細は、「Oracle Service Busのサービス・ヘルスのモニター」を参照してください。

図3-3 「サービス・ヘルス」ページ

3.1.1.4 リシーケンス・メッセージ

デプロイ済のパイプラインのいずれかで、メッセージを並べ替えるためにリシーケンサを使用している場合、リシーケンス・メッセージ・ページにそれらのメッセージの処理状態に関する情報が表示されます。これにより、リシーケンス・グループの現在の状態をモニターすることができます。グループは、実行中、フォルト、完了のいずれでもかまいせん。検索機能により、特定のリシーケンサ・グループ内のメッセージ、特定の状態のグループ、または特定のサービスに関連付けられているメッセージを検索できます。

リシーケンス・グループでメッセージ処理が中断した場合、リシーケンス・メッセージ・ページの手順を実行して、メッセージの処理を修正、再試行または中止することができます。修正処理はフォルトのタイプによって異なりますが、メッセージ処理のキャンセル、スタック・メッセージのスキップ、ペイロードの変更とメッセージの再試行などが含まれています。これらはすべて、リシーケンス・メッセージ・ページから実行できます。

次の図は「リシーケンス・メッセージ」ページを示しています。詳細は、「リシーケンス・グループの監視」を参照してください。

図3-4 「リシーケンス・メッセージ」ページ

3.1.1.5 操作

Service Busの「操作」ページには、デプロイされているサービスの現在の操作設定が表示されます。リストされているサービスの設定を、個別にまたはまとめて更新できます。Service Busの「操作」ページには、使用可能な操作設定のサブセットのみが含まれ、設定の有効化と無効化しか実行できません。サービス固有の「操作」ページで、それらの設定の詳細を構成したり、追加の設定を構成したりすることができます。Service Busページから構成できる設定には、モニター、アラート、メッセージ・トレース、実行トレース、アラート、レポート、ロギング、ビジネス・サービスのパフォーマンス・チューニングなどがあります。操作設定には、サービス・レベルで設定されるものや、グローバル・レベルで設定されるものがあります。一部の操作設定は、有効にするためにサービス・レベルとグローバル・レベルの両方で設定される必要があります。「操作」ページでは、サービス・レベルの設定のみを構成します。

次の図は「操作」ページを示しています。詳細は、「操作設定とグローバル設定の構成」を参照してください。

図3-5 「操作」ページ

3.1.1.6 グローバル設定

Service Busの「グローバル設定」ページでは、モニター、ロギング、アラートなどの操作設定をグローバルに有効化できます。ランタイムの特定のリシーケンス・プロパティも構成できます。

設定を効果的に有効または無効にするには、サービス・レベルの設定とともにグローバル・レベルの設定を有効または無効にする必要があります。特定のサービスに対して有効にするには、次の設定をグローバル・レベルで有効にする必要があります。

- モニター

- SLAアラート

- パイプライン・アラート

- レポート

- ロギング

- 結果キャッシュ

次の図は「グローバル設定」ページを示しています。詳細は、「操作設定とグローバル設定の構成」を参照してください。

図3-6 「グローバル設定」ページ

3.1.2 Service Busのプロジェクト・モニター・ページ

「Service Busプロジェクト」ページには、選択したプロジェクト内のサービスに関する情報が表示され、「サービス・ヘルス」ページと「操作」ページがあります。これらのページは、「Service Busのドメイン・レベルのモニター・ページ」で説明したドメイン・レベルのページに似ていますが、これらのページは、選択したプロジェクトに含まれているサービスに関する情報のみが表示されます。「サービス・ヘルス」ページには、選択したプロジェクト内のサービスのサービス・ヘルス・メトリックが表示されます。「操作」ページには、選択したプロジェクト内のサービスの操作設定が表示されます。これらの設定は、個別に更新することも、プロジェクト内のすべてのサービスに対して更新することもできます。

3.1.3 Service Busサービスのモニター・ページ

サービスのモニター・ページを使用して特定のサービスをモニターすることができます。サービス固有のページには、ダッシュボード、「ポリシー」ページおよび「プロパティ」ページなどがあります。

3.1.3.1 ダッシュボード(サービス・レベル)

ダッシュボードには、アラート数、メッセージ数、レスポンス時間、エラー数など、選択したサービスのサービス・ヘルス・メトリックが表示されます。さらに、該当する場合は、WSDL操作の統計も表示されます。(ビジネス・サービスの場合のみ)他の統計とともに、エンドポイントの状態に関する情報を表示できます。また、エンドポイントURIをオンラインまたはオフラインにすることによって、エンドポイントURIを管理します。(パイプラインおよび分割-結合の場合のみ)ダッシュボードには、追加の統計が、ブランチおよびアクティビティ・レベルに至るまで表示されます。

3.1.3.2 プロパティ

「プロパティ」ページには、サービスの現在の操作設定が表示されます。設定の有効化または無効化、モニターおよびロギング・レベルの指定、アラート重大度の指定、および集約間隔の定義を行うことによって、設定を更新できます。使用可能な設定は、モニターしているService Busサービスのタイプによって異なります。詳細は、「操作設定とグローバル設定の構成」を参照してください。

3.1.3.3 ポリシー

「ポリシー」ページには、グローバル・レベルでサービスにアタッチされているすべてのセキュリティ・ポリシーのリスト、およびサービスに直接アタッチされているセキュリティ・ポリシーのリストが表示されます。このページでは、ポリシーをアタッチおよびデタッチしたり、オーバーライドをサポートしているポリシーに対してオーバーライド値を指定したりすることができます。グローバル・ポリシーは、このページでは変更できません。Fusion Middleware Controlでは、ポリシー使用状況およびポリシー違反をモニターし、グローバル・ポリシー・セットを作成する機能が用意されています。詳細は、「セキュリティ・ポリシーのモニターと管理」を参照してください。

3.2 Oracle Enterprise Manager Fusion Middleware Controlへのログイン

ブラウザのURLまたはOracle Service BusコンソールからFusion Middleware Controlにアクセスできます。

Oracle Service BusコンソールからFusion Middleware Controlにアクセスするには、「リンク」、「EMコンソール」の順にクリックします。この場合、ログイン手順はバイパスされます。

ブラウザからOracle Enterprise Manager Fusion Middleware Controlにログインする手順は、次のとおりです。

1. ブラウザに次のURLを入力します。

http://host_name:port/em

ここで、host_nameはFusion Middleware Controlがインストールされているホストの名前、portは管理サーバーのポート番号(デフォルトでは7001)です。ポート番号は、次のファイルにリストされています。

DOMAIN_HOME/config/config.xml

2. 管理者ユーザー名とパスワードを入力し、「ログイン」をクリックします。

注意:

デフォルトの管理者ユーザー名はweblogicです。これはインストール中に変更できます。

最初にログインしたときに、アクセシビリティ・プリファレンス・ダイアログが表示されます。必要な場合は、このダイアログを再度表示しないことを選択できます。

3. 適切なアクションを選択し、「続行」をクリックします。

ホーム・ページが表示されます。このページから、次の項で説明されているとおり、いくつかの異なる方法でOracle Service Busにナビゲートできます。

3.3 Oracle Service Bus管理ページへのナビゲート

Service Busホーム・ページおよびメニューを使用して、Service Bus管理タスクにナビゲートできます。

Service Busホーム・ページでは、デプロイ済のService Busサービスおよびサービス・コンポーネントのすべてにアクセスできます。いくつかの異なる方法およびメニューを使用して、Service Busページをナビゲートできます。

3.3.1 Service Busホーム・ページおよびメニューを使用したナビゲート

Service Busホーム・ページおよびメニューによって、すべてのSLAアラートとパイプライン・アラート、ヘルス統計およびService Busサービスにアクセスできます。

Service Busホーム・ページおよびメニューを使用してナビゲートするには:

1. ターゲット・ナビゲータで、「SOA」を開き、「service-bus」をクリックします。

Service Busホーム・ページの「ダッシュボード」ページが表示されます。

このページの上部にはSLAアラートのグラフが表示されますが、パイプライン・アラートが表示されるように選択することもできます。また、最も多くのアラートが発生したサービス、アラートに関する情報、および最も多くのエラーがあるサービスのリストも表示されます。

2. 任意のセクションにリストされているサービスに関する詳細情報にアクセスするには、サービス名をクリックします。

3. セクション内のすべての項目の詳細情報にアクセスするには、そのセクションの下部にある「詳細の表示」をクリックします。

4. ナビゲーション・メニューにアクセスするには、次の手順のいずれかを実行します。

- ページの左上で、「service-bus」の下の「Service Bus」メニューをクリックします。

- ターゲット・ナビゲータで「service-bus」を右クリックします。

注意:

現在の場所に応じて、このメニューのコンテキストが変わり、関連する管理オプションが表示されます。たとえば、プロジェクトまたはサービスのページ内で作業している場合は、かわりに「Service Busプロジェクト」メニューが表示されます。

5. 「Service Bus」メニューから、次のオプションにアクセスできます。

オプション

説明

ホーム

表示する別のService Busページを選択するには、このオプションを選択します。

ログ

ログ・ファイルを表示または構成するには、このオプションを選択し、次のオプションのいずれかを選択します。

- ログ・メッセージの表示: ターゲットのログ・ファイルに記録されているエントリを表示するには、これを選択します。

- ログ構成: 様々なService Busログ出力のログ・ファイルおよびログ・レベルを定義するには、これを選択します。

メッセージ・レポート

パイプライン・レポート・アクションによって生成されたメッセージ・レポートを表示するには、このオプションを選択します。

インポート

Service Busの構成JARファイル(およびオプションで、環境値を定義する構成ファイル)をインポートするには、このオプションを選択します。

エクスポート

Service Busプロジェクトおよびリソースを構成JARファイルにエクスポートするには、このオプションを選択します。

セキュリティ

セキュリティ・ポリシーまたはロールを構成するには、このオプションを選択し、次のオプションのいずれかを選択します。

- アプリケーション・ポリシー: リソースへのアクセスを制御するためにアプリケーションが使用するアプリケーション・ポリシーを作成するには、これを選択します。

- アプリケーション・ロール: アプリケーションのアプリケーション・ロールを作成するには、これを選択します。

これらのオプションは、Service Busサービスのセキュリティ・ポリシーを構成するものではありません。

システムMBeanブラウザ

MBeanブラウザを起動するには、このオプションを選択します。MBeanブラウザでは、このドメインで設定されているMBeanプロパティに関する情報を表示できます。

ターゲット情報

バージョン、ドメインおよびFusion Middlewareホーム・ディレクトリの場所、サーバー・ホスト名など、ターゲット・サーバーに関する情報を表示するには、このオプションを選択します。

6. Service Busホーム・ページで、次のタブのいずれかを選択して、詳細情報を検索および表示します。

- ダッシュボード: アラートおよびエラーに関する情報が表示されます。詳細は、「Oracle Service Busのアラートのモニター」を参照してください。

- アラート履歴: アラートの履歴が表示されます。指定した基準を満たすアラートを検索できます。詳細は、「Oracle Service Busのアラートのモニター」を参照してください。

- サービス・ヘルス: サービス・ヘルス統計が表示されます。表示する実行中のサービスを検索できます。詳細は、「Oracle Service Busのサービス・ヘルスのモニター」を参照してください。

- リシーケンス・メッセージ: リシーケンス・メッセージのステータスが表示されます。フォルトをリカバリしたり、グループをブロックしているメッセージをスキップしたりできます。詳細は、「リシーケンス・グループの監視」を参照してください。

- 操作: 実行中のサービスの現在の操作設定が表示されます。サービスを検索し、その操作設定を更新することができます。詳細は、「操作設定とグローバル設定の構成」を参照してください。

- グローバル設定: グローバル操作設定が表示されます。操作設定を有効または無効にすることができます。詳細は、「操作設定とグローバル設定の構成」を参照してください。

3.3.2 Service Busプロジェクト・ホーム・ページおよびメニューを使用したナビゲート

「Service Busプロジェクト」メニューを使用して、特定のService BusプロジェクトのService Busタスクに直接ナビゲートできます。このメニューは、Service Busのプロジェクトとサービスの両方で同じです。

Service Busプロジェクト・ホーム・ページおよびメニューを使用してナビゲートするには:

1. ターゲット・ナビゲータで、「SOA」を開き、「service-bus」を開きます。

実行中のすべてのService Busプロジェクトが「service-bus」の下のリストに表示されます。

2. 特定のService Busプロジェクトを選択します。

選択したプロジェクトの「サービス・ヘルス」ページが表示されます。

3. ナビゲーション・メニューにアクセスするには、次の手順のいずれかを実行します。

- ページの左上で、「service-bus」の下の「Service Busプロジェクト」をクリックします。

- ターゲット・ナビゲータでプロジェクトの名前を右クリックします。

「Service Busプロジェクト」メニューに、現在のService Busアプリケーション固有の管理タスクが表示されます。

4. 「Service Busプロジェクト」メニューから、次のオプションにアクセスできます。

オプション

説明

ホーム

Service Busプロジェクト・ホーム・ページに戻り、タブ・ページのいずれかに直接ナビゲートするには、このオプションを選択します。

メッセージ・レポート

パイプライン・レポート・アクションによって生成されたメッセージ・レポートを表示するには、このオプションを選択します。

インポート

Service Busの構成JARファイル、または環境値を定義する構成ファイルをインポートするには、このオプションを選択します。

エクスポート

Service Busリソースを構成JARファイルにエクスポートするには、このオプションを選択します。

ターゲット情報

バージョン、ドメインおよびFusion Middlewareホーム・ディレクトリの場所、サーバー・ホスト名など、ターゲット・サーバーに関する情報を表示するには、このオプションを選択します。

5. Service Busプロジェクト・ホーム・ページで、次のタブのいずれかを選択して、詳細情報を検索および表示します。

- サービス・ヘルス: サービス・ヘルス統計が表示されます。表示する現在のプロジェクト内の実行中のサービスを検索できます。詳細は、「Oracle Service Busのサービス・ヘルスのモニター」を参照してください。

- 操作: プロジェクト内のサービスの操作設定が表示されます。現在のプロジェクト内のサービスを検索して、その操作設定を更新することができます。詳細は、「操作設定とグローバル設定の構成」を参照してください。

3.3.3 ホーム・ページからのOracle Service Busページへのナビゲート

Fusion Middleware Controlのホーム・ページは「WebLogicドメイン」ページで、コンソールに最初にログインしたときに表示されるページです。「WebLogicドメイン」ページから、Service Busのホーム・ページまたは特定のService Busプロジェクトのホーム・ページにアクセスできます。

Service BusまたはService Busプロジェクト・ホーム・ページにナビゲートするには:

- ホーム・ページの「デプロイメント」セクションで、デプロイ済のアプリケーションのリストをスクロールし、service-busまたは特定のService Busプロジェクトの名前を選択します。
選択内容に応じたホーム・ページが表示されます。

3.4 システムMBeanブラウザへのナビゲート

Oracle Service Busの一部の構成パラメータは、Fusion Middleware Controlのどのプロパティ・ページにも公開されません。それらのパラメータは、システムMBeanブラウザを使用して表示できます。

マネージドBean (MBean)は、アプリケーション、サービス、コンポーネント、デバイスなど、分散環境内のJava Management Extensions (JMX)管理可能リソースを表すJavaオブジェクトです。Fusion Middleware Controlでは、特定のモニターおよび構成タスクを実行するMBeanを管理するためのシステムMBeanブラウザが用意されています。システムMBeanブラウザに関する一般的な情報は、Oracle Fusion Middlewareの管理のFusion Middleware Control MBeanブラウザの使用のスタート・ガイドを参照してください。

ターゲット・ナビゲータから、メインの「システムMBeanブラウザ」ページに直接アクセスできます。メイン・ページでは、システムMBeanブラウザ内のすべてのプロパティにアクセスできます。管理対象のセクションまでナビゲーション・ツリーを移動する必要があります。

システムMBeanブラウザにアクセスするには:

1. ターゲット・ナビゲータで、「service-bus」を右クリックします。

2. 「システムMBeanブラウザ」を選択します。

システムMBeanブラウザが表示され、Service Busのアプリケーション定義MBeanのリストが示されます。

3.5 アクセシビリティ・オプションの設定

Fusion Middleware Controlでは、Service Busサービスをモニターおよび管理するページのためのアクセシビリティ・オプションが用意されています。Fusion Middleware Controlは、スクリーン・リーダーをサポートしており、キーボード・ナビゲーションをサポートするための標準のショートカット・キーを提供しています。読みやすくするために、コンソール・ページを高コントラストで表示したり、大きなフォントで表示したりすることもできます。

Fusion Middleware Controlにおけるアクセシビリティの構成の詳細および手順は、Oracle Fusion Middlewareの管理の「Oracle Fusion Middlewareのアクセシビリティ・オプションの使用」を参照してください。

3.6 Oracle Enterprise Manager Fusion Middleware Controlからのログアウト

Oracle Enterprise Manager Fusion Middleware Controlは、どのページからでもログアウトできます。

ページの右上にある「ログアウト」」リンクを使用します。

3.7 Oracle Service Busサーバーの起動

Service Busサービスは、実行中のOracle WebLogic Serverにデプロイする必要があります。Oracle WebLogic Serverは様々な方法で起動できます。

コマンド行、起動スクリプトまたは管理コンソールを使用してサーバーを起動する方法の詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』を参照してください。

第II部 Oracle Service Busのモニター

この部では、アラート、サービス・ヘルス、リシーケンス・グループ・ステータス、ログ・ファイルなど、Service Busサービスおよびコンポーネントのモニター方法について説明します。

この部は、次の章で構成されています。

- Oracle Service Busのアラートのモニター

- Oracle Service Busのサービス・ヘルスのモニター

- リシーケンス・グループのモニター

- ログ・ファイルの構成とモニター

4 Oracle Service Busのアラートのモニター

この章では、Service Busのサービス・レベル・アグリーメント(SLA)のアラートとパイプライン・アラートをモニターおよび管理する方法について説明します。 Oracle Service Busコンソールで、実行時にモニターできるようにアラートをトリガーする条件を定義して、SLAアラート・ルールを作成および構成します。アラート・アクションでパイプライン内のメッセージ・フローを定義する際、パイプライン・アラートを定義します。

この章の内容は次のとおりです。

- Oracle Service Busのアラートについて

- サービス・レベル・アグリーメントのアラートについて

- パイプライン・アラートについて

- アラートの有効化と無効化

- サービス・レベル・アグリーメントのアラート・ルールの作成

- SLAアラート・ルールの更新

- SLAアラートおよびパイプライン・アラートのモニター

4.1 Oracle Service Busのアラートについて

Oracle Service Busでは、サービス・コンポーネントに対して、サービス・レベル・アグリーメント(SLA)のアラートとパイプライン・アラートという2つの異なるタイプのアラートを定義します。どちらのタイプのアラートでも、電子メール・アドレスやJMSキューなどのアラート宛先を指定できます。

SLAアラート・ルールはOracle Service Busコンソールで定義し、パイプライン・アラート・ルールはOracle Service BusコンソールまたはJDeveloperで定義します。次の図は、Service Busの「サービス・ヘルス」ページを示し、アラートを生成したサービスのリストが表示されています。

4.1.1 Service Busダッシュボード上のアラート

Fusion Middleware Controlでは、Service Busの「ダッシュボード」ページでドメイン全体のSLAアラートおよびパイプライン・アラートをモニターできます。このページには、指定された間隔内に、または統計が最後にリセットされて以降、ドメインで発生したすべてのアラートに関する情報が表示されます。ダッシュボードには次の情報が含まれています。

- 指定された期間のアラートを重大度別に示した円グラフ。

- 現在の集約間隔内に、指定されたタイプのアラートが発生した上位10件のサービス(降順に表示されます)。

- 円グラフで示されているアラートとその説明が表示された表。

- 最も多くのエラーが発生したサービスが表示された表。

このページに表示されるアラートは、円グラフに示されているアラートです。このページのどの表でも、アラートまたはサービスの名前をクリックすると、詳細情報を表示できます。または、円グラフのセクションをクリックすると、指定された重大度のアラートに関する詳細情報が表示されます。

アラートは、電子メール・アドレス、JMSキュー、SNMPトラップなど、複数のアラート宛先に送信できます。アラートの宛先はアラート宛先リソースで定義され、このリソースがService Busでアラートに関連付けられます。アラート宛先の詳細は、『Oracle Service Busでのサービスの開発』のアラート宛先の操作に関する項を参照してください。

4.1.2 アラートおよび操作設定

アラートが生成されるのは、Service Busドメインでアラートおよびモニターが有効化されている場合のみです。SLAアラートの場合、個別のサービスとドメインの両方でSLAアラートを有効にする必要があります。パイプライン・アラートの場合、個別のパイプラインとドメインの両方でパイプライン・アラートを有効にする必要があります。操作設定の詳細は、「操作設定とグローバル設定の構成」を参照してください。

4.2 サービス・レベル・アグリーメントのアラートについて

SLAアラートの目的は、Service Busサービスのヘルスや提供されているサービスの品質に関連する問題を運用チームに知らせることです。

SLAアラート・ルールは、各サービスで定義されている条件に基づいて、プロキシ・サービス、ビジネス・サービス、パイプラインおよび分割-結合に対するアラートをトリガーします。プロジェクトのService Busリソースを作成する際に、これらのアラートを構成できます。アラート・ルールの作成時に、アラート・ルールの名前、説明、概要、期間、重大度、頻度および状態を定義します。ルールに基づいてアラートをトリガーする1つ以上の条件を定義することもできます。条件には、メッセージ数またはエラー数、レスポンス時間、失敗率または成功率、およびエンドポイントURIのステータスを含めることができます。

SLAアラートは、SLAアラート・ルールへの違反に対するレスポンスを自動化したもので、ダッシュボードおよび「アラート履歴」ページに表示されます。ビジネスおよびパフォーマンスの要件に従い、許容できないサービス・パフォーマンスを指定するアラート・ルールを定義します。SLAアラート・ルールの作成時に、アラートの日次作動時間帯およびアラート・ルールが失効する日付を指定できます。ルールによって生成されるアラートの集約間隔も指定できます。アラートに設定された集約間隔は、サービスに設定された集約間隔の影響を受けません。集約間隔の詳細は、「集約間隔」を参照してください。

モニターが有効になっているサービスでは、アラート・ルールは個々の間隔で評価されます。作成したアラート・ルールは、まず集約間隔の最後に評価され、その後は各サンプル間隔の最後に評価されます。たとえば、アラート・ルールの集約間隔が5分である場合、それは作成してから5分後に評価され、その後は1分ごとに評価されます(5分に対するサンプル間隔は1分であるため)。

ルールがfalseと評価された場合は、アラートは生成されません。ルールがtrueと評価された場合は、アラートの生成はアラート間隔の頻度によって制御されます。頻度が毎回である場合は、アラート・ルールがtrueと評価されるたびにアラートが生成されます。頻度が1回通知である場合は、前回の評価でアラートが生成されなかったときのみアラートが生成されます。つまり、アラートはアラート・ルールが最初にtrueと評価されたときに生成され、条件がリセットされ、再びTrueと評価されるまで、通知は生成されません。

4.2.1 SLAアラートの重大度レベル

SLAまたはパイプライン・アラート・ルールを作成する際、アラートの重大度を指定します。それらのレベルは、Service Bus内では具体的な意味を持ちませんが、特定の実装に対してアラートがどのような意味を持つのかを定義します。アラートには、次の重大度レベルを設定できます。

- 通常

- 警告

- 軽度

- 重度

- クリティカル

- 致命的

4.2.2 集約間隔

集約間隔により、モニター・システムがアラート条件をテストする頻度が決定されます。1つの集約間隔を構成するのに十分なデータのサンプルがモニター・サブシステムで収集されるたびに、条件がテストされます。たとえば、1時間の集約間隔を選択した場合、1時間分のデータが利用可能になると条件がテストされます。条件が最初にテストされるのは、1時間後です。1時間の集約間隔のサンプル間隔が10分に設定されているため、条件はそれ以降10分ごとにテストされます。

アラート・ルールの作成および構成時に、そのルールの集約間隔を指定します。この集約間隔は、サービスに設定された集約間隔の影響を受けません。

4.2.3 SLAアラートの間隔

アラート・ルールの条件が満たされるたびにアラートを生成するか、最初に条件が満たされたときにのみアラートを生成するかを指定できます。条件が満たされるとアラート・ルールによってアラートが生成され、アラート・ルールの評価がtrueになるたびに、アラート・ルールに含まれているアクションが実行されます。たとえば、平均レスポンス時間が300ミリ秒を超えるという条件を定義した場合、この条件の評価がtrueになるたびにアラートが送信されます。

アラート・ルールが評価される回数は、集約間隔と、そのルールに関連付けられたサンプル間隔によって異なります。集約間隔が5分に設定されている場合は、サンプル間隔が1分になります。5つのデータ・サンプルが利用可能になると、ルールが評価されます。したがって、ルールは作成されてから約5分後に初めて評価され、それ以降は1分ごとに評価されます。

アラートを1回だけ生成するようにアラート・ルールが構成されている場合、ルールの評価が初めてtrueとなったときにルールに含まれているアクションが実行されて、条件がリセットされ、評価が再びtrueとなるまでそれ以外のアラートは生成されません。たとえば、平均レスポンス時間が300ミリ秒未満という条件を定義した場合、この条件の評価が初めてtrueとなったときにアラートが送信されます。ただし、条件の評価がfalseとなり、再びtrueとなるまでそれ以外のアラートは送信されません。アラートのタイムスタンプは更新され、ダッシュボードに表示されます。

4.2.4 SLAアラートの統計

SLAアラート・ルールのアラート条件を定義する際、複数のメジャーから、アラートの評価に使用するものを選択できます。評価する特定のカウント、最小、最大、平均、ステータスなどが含まれます。選択可能な統計のリストは、選択内容によって異なります。たとえば、「最小」、「最大」または「平均」を選択すると、「レスポンス時間」統計が使用できるようになります。また、使用できる統計は、サービス自体の構成によっても異なります。統計の数は、パイプライン、ルート・ノード、処理などがサービスにあるかどうかによって異なります。

次の各項では、各メジャーに使用できる統計のリストと説明を示します。

4.2.4.1 カウント統計の詳細

次の表では、カウント統計の詳細について説明します。

表4-1 カウント統計の詳細

統計

説明

キャッシュのヒット数

結果キャッシュを使用するビジネス・サービスの場合、キャッシュを使用してレスポンスがクライアントに返されるたびに、この統計が増分されます。

エラー数

エラーの数。メッセージの処理が失敗するたびに、この数が増分されます。

フェイルオーバー数

(ビジネス・サービスの場合のみ)フェイルオーバーが発生した回数。

失敗率(%)

指定された集約間隔で、発生したエラー数と正しく処理されたメッセージ数の比率。

メッセージ数

処理されたメッセージの合計数。

成功率(%)

指定された集約間隔で、正しく処理されたメッセージ数と発生したメッセージ数の比率。

Request Pipeline.Error Count

(パイプラインの場合のみ)リクエスト・パイプラインにより処理されたエラー・メッセージの数。

リクエスト・パイプライン.メッセージ数

(パイプラインの場合のみ)リクエスト・パイプラインにより処理されたメッセージの数。

Response Pipeline.Error Count

(パイプラインの場合のみ)レスポンス・パイプラインにより処理されたエラー・メッセージの数。

Response Pipeline.Message Count

(パイプラインの場合のみ)レスポンス・パイプラインにより処理されたメッセージの数。

検証エラー数

(パイプラインに検証アクションのあるプロキシ・サービスの場合)検証エラー数。パイプラインの場合、この統計はvalidation-errorsという名前です。

WSSエラー数

サービスのトランスポート(HTTPを使用など)によっては、このオペランドが使用できます。処理されたWebサービス・セキュリティ(WSS)のエラー・メッセージの数です。このカウンタはWSDLベースのサービスだけに使用でき、WSSエラーが発生するとインクリメントされます。

URI:パス.メッセージ数およびURI:パス.エラー数

これらのオペランドは、ビジネス・プロセスのエンドポイントURIのアラートを設定します。エンドポイントURIに基づいてアラートを生成する方法の詳細は、「ビジネス・サービスのエンドポイントURIのモニターおよび管理」を参照してください。

4.2.4.2 最大、最小および平均の統計の詳細

次の表では、最大、最小および平均の統計の詳細について説明します。

表4-2 最大、最小および平均の統計の詳細

統計

説明

Request Pipeline.Elapsed Time

(パイプラインの場合のみ)リクエスト・パイプラインが各メッセージを処理するためにかかった時間。

Response Pipeline.Elapsed Time

(パイプラインの場合のみ)レスポンス・パイプラインが各メッセージを処理するためにかかった時間。

経過時間

(パイプラインおよび分割-結合の場合のみ)各リクエストまたはレスポンスを処理するためにかかった時間。

レスポンス時間

各リクエストまたはレスポンスを処理するためにかかった時間(ミリ秒)。

スロットル時間

(ビジネス・サービスの場合のみ)スロットルで構成されているビジネス・サービスによって処理されたメッセージがスロットル・キュー内に存在していた時間。

URI:パス.レスポンス時間

このオペランドは、ビジネス・プロセスのエンドポイントURIのアラートを設定します。エンドポイントURIに基づいてアラートを生成する方法については、「ビジネス・サービスのエンドポイントURIのモニターおよび管理」を参照してください。

4.2.4.3 ステータス統計の詳細

ステータス統計は、ビジネス・サービスにのみ適用され、ビジネス・サービスのエンドポイントURIがオンラインであるかオフラインであるかを条件の基準として使用できます。

次の表では、ステータス統計の詳細について説明します。

表4-3 ステータス統計の詳細

統計

説明

オフラインのすべてのURI

クラスタ内のすべてのURIがオフラインである場合、trueに評価します。

オンラインのすべてのURI

クラスタ内のすべてのURIがオンラインである場合、trueに評価します。

オフラインの特定のURI

クラスタ内の任意のURIがオフラインである場合、trueに評価します。

オンラインの特定のURI

クラスタ内の任意のURIがオンラインである場合、trueに評価します。

4.3 パイプライン・アラートについて

パイプライン・アラートは、事前定義された条件セットではなく、メッセージのコンテキストに基づいてトリガーされます。

アラート・アクションを追加および構成することで、パイプライン・メッセージ・フローに直接パイプライン・アラートを定義します。パイプライン・アラート・アクションは、パイプライン内のメッセージ・コンテキストに基づいてアラートを生成します。また、アラート名、説明($orderなどのメッセージ要素を含めることが可能)、アラート宛先およびアラート重大度を含めるように構成できます。SLAアラートと異なり、パイプライン・アラート・アクションで生成された通知は、主にビジネスでの使用、またはエラーの報告を目的とし、システムの状態を監視するものではありません。

パイプライン・アラートをトリガーする条件を定義するには、XQueryエディタなどのパイプライン・エディタで使用できる条件構文やif-then-else構文を使用します。アラート本文(コンテキスト変数を含みます)を完全に制御し、メッセージの一部を抽出してアラートに含めることができます。Fusion Middleware Controlでパイプライン・アラートを表示するだけでなく、電子メールによる通知の送信先のアラート宛先またはJMS宛先を選択することもできます。

詳細は、『Oracle Service Busでのサービスの開発』のアラート・アクションの追加に関する項を参照してください。

4.3.1 パイプライン・アラートの使用例

パイプライン・アラートの使用例として、メッセージ・フローに特殊なビジネス条件が見つかった場合に通知を受け取る必要があるとします。このような定義済条件が見つかった場合にアラートを発生させるように、パイプラインのアラート・アクションを構成できます。また、アラートの通知を受け取るように電子メールおよびJMSアラート宛先を構成し、アラート受信者にペイロードの形式で詳細を送信することもできます。

たとえば、購入注文のWebサイトに注文をルーティングするパイプラインに、1000万ドルを超える注文がルーティングされたときに通知を受け取るようにすることが考えられます。パイプラインの適切な場所に、1000万ドルを超えるという条件を定義するアラート・アクションを作成し、そのアラート・アクションでターゲット宛先として電子メール・アラート宛先を構成することができます。アラートのコンテンツを構成したり、ペイロード形式で注文の詳細を含めたりすることができます。

また、パイプライン・アラートを使用してメッセージ・フローのエラーを検出することもできます。たとえば、プロキシ・サービスが入力ドキュメントを検証する際、クライアントに連絡して問題を修正できるように、検証が失敗したときには通知を受け取るようにすることが考えられます。その場合、パイプラインのエラー・ハンドラ内にアラート・アクションを構成する必要があります。このアクションでは、ペイロードとして送信するために、実際のエラー・メッセージをfault変数に、その他の詳細情報をSOAPヘッダーに含めることができます。アラート・アクション内でアラート宛先リソースを使用することにより、追加のアラート宛先を構成することもできます。

4.4 アラートの有効化と無効化

SLAアラートまたはパイプライン・アラートを発生させるには、まずアラート・ルールを定義し、サービス・レベルとグローバル・レベルの両方でアラートおよびモニターを有効にする必要があります。

たとえば、プロキシ・サービスに対してSLAアラートを有効にするには、Oracle Service Busコンソールでそのサービスのアラート・ルールを定義し、そのプロキシ・サービスに対してSLAアラートおよびモニターを有効にして、サービス・バス・ドメインに対してグローバルにSLAアラートおよびモニターを有効にする必要があります。後者の2つの手順は、Fusion Middleware Controlで実行します。パイプライン・アラートを有効にする場合も、同じ手順を実行します。

サービスの操作設定の構成方法の詳細は、「操作設定の表示と構成」を参照してください。「アラート履歴」パネルには、システムにおける違反またはイベントの発生に関する情報を表示する、カスタマイズ可能なテーブルがあります。

4.5 サービス・レベル・アグリーメントのアラート・ルールの作成

SLAアラート・ルールの作成は、2つの手順があるプロセスです。まず、ルールを評価する方法とタイミング、ルールから生成されるアラートの電子メールまたはJMS宛先、生成されるアラートの重大度など、アラート・ルールのプロパティを構成します。プロパティが構成されたら、アラートを生成する条件(条件が満たされると、アラートが生成されます)を指定することができます。

注意:

サービスが別のサービスから作成された場合、アラート・ルールは次のようにして管理されます。

- プロキシ・サービスがビジネス・サービスから、またはビジネス・サービスがプロキシ・サービスから作成された場合、アラート・ルール(ある場合)は削除されます。

- プロキシ・サービスが別のプロキシ・サービスから、またはビジネス・サービスが別のビジネス・サービスから作成された場合、アラート・ルール(ある場合)は保持されます。

4.5.1 始める前に

SLAアラート・ルールによってアラートを生成して、電子メール・アドレスまたはJMSキューに通知を送信する場合、それらの宛先を定義するアラート宛先を作成する必要があります。詳細は、『Oracle Service Busでのサービスの開発』のアラート宛先の操作に関する項を参照してください。

4.5.2 SLAアラート・ルールのプロパティの構成

SLAアラートを作成し、そのプロパティを構成するには:

1. Oracle Service Busコンソールを起動します。詳細は、『Oracle Service Busでのサービスの開発』のスタート・ガイドに関する項を参照してください。

2. 現在セッションに参加していない場合は、「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションに参加します。

3. プロジェクト・ナビゲータで、SLAアラートを追加するプロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合をクリックします。

4. エディタで、「SLAアラート・ルール」タブをクリックします。

5. サマリー表の上で、「新しいアラート・ルールの追加」をクリックします。

次に示すように、「SLAアラート・ルールの作成」ウィザードが表示されます。

図4-1 「SLAアラート・ルールの作成」ウィザード - ルール構成

6. ルールの名前、説明および簡単なサマリーを入力します。

アラート・サマリーは、電子メール通知の件名行のテキストになります。80文字以内で入力してください。アラート・サマリーが未指定の場合、「Oracle Service Busアラート」というデフォルト・テキストが使用されます。

7. ルールを有効にするには、「ルール状態」を選択します。

8. 「アラート宛先」フィールドに、アラートの宛先リソース名を入力するか、「参照」をクリックし、「検索と選択」ダイアログでリソースを選択します。リストからアラートの宛先を選択し、「OK」をクリックします。

デフォルトでは、すべてのアラートはFusion Middleware Controlに表示されます。

9. ルールがアクティブになる毎日の時間範囲を指定するには、「開始時間」および「終了時間」フィールドに開始時間と終了時間をHH:MM [AM/PM]という形式で入力します。

アラート・ルールは、ルールが有効期限切れになるまで、指定した開始時刻から指定した終了時刻の間毎日アクティブになります。

10. 「有効期限」フィールドに、MM/DD/YYYYという形式で有効期限を入力します。

ルールは、指定日の午後11時59分に期限切れになります。日付を指定しない場合、ルールは無期限になります。

11. 「アラート重大度」フィールドで、オプションのリストから重大度を選択します。

12. 「アラート間隔」フィールドで、「毎回」または「1回通知」を選択します。

詳細は、「SLAアラートの間隔」を参照してください。

13. サービスに関連付けられたいずれかのルールの評価がtrueとなった後に、それ以降のルールの実行を停止するには、「次のルールの処理」フィールドで、「停止」を選択します。以降もルールの実行を続行するには、「続行」を選択します。

このオプションを使用すると、特定のサービスに複数のルールが関連付けられている場合に後続のルールの評価を停止できます。ルールの処理を続行する場合は、デフォルトの「いいえ」を選択したままにします。

14. 「次」をクリックし、「SLAアラート・ルールの条件の定義」に進みます。

4.5.3 SLAアラート・ルールの条件の定義

単純な式で構成される、少なくとも1つの条件を定義する必要があります。複数の条件を指定する場合は、And/Or演算子を使用して結合します。条件の定義に使用できるメジャーおよび統計の詳細は、「SLAアラートの統計」を参照してください。

図4-2 「SLAアラート・ルールの作成」ウィザード - ルール条件

この手順では、「SLAアラート・ルールのプロパティの構成」を完了し、「SLAアラート・ルールの作成」ウィザードの「ルール条件」ページを表示していることを前提としています。

SLAアラート・ルールの条件を定義するには:

1. 「SLAアラート・ルールの作成」ウィザードの「ルール条件」ページで、「条件の集約間隔」の時間間隔を選択します。
詳細は、「集約間隔」を参照してください。

2. 条件を定義するには、次の手順を実行します。

a. 表にテンプレート行がない場合は、条件ビルダー表の上の「新しい条件の追加」をクリックします。
表に新しい行が表示されます。

b. 最初のオプション・リストから、統計の評価に使用するメジャーのタイプを選択します。
「カウント」、「最小」、「最大」、「平均」または「ステータス」のいずれかを選択します。

注意:

ステータスはビジネス・サービスでのみ使用可能であり、エンドポイントURIがオンラインであるかオフラインであるかを条件の基準にすることができます。

c. 2番目のオプション・リストから、エラー数、フェイルオーバー率(%)、レスポンス時間など、評価する統計を選択します。
使用可能な統計は、選択したメジャーのタイプによって異なります。詳細は、「SLAアラートの統計」を参照してください。

d. 3番目のオプション・リストから、比較演算子(=、!=、>または<)を選択します。

e. 比較演算子の後のフィールドに、実際の統計と比較する値を入力します。条件がエンドポイントURIのステータスに基づいている場合は、「True」または「False」を選択します。

f. 条件がエンドポイントURIのステータスに基づいている場合は、すべてのサーバーに対してルールを評価するか、任意のサーバーでルールを評価するかを選択します。

g. 行の右にある「条件の更新」をクリックします。

3. アラート・ルールに含める必要のあるすべての条件が追加されるまで、前述の手順を繰り返します。

4. 定義した条件を結合するには、結合する条件を選択し、「選択した条件を結合します」をクリックして、AndまたはOr演算子を選択します。
選択した条件が1つの複雑な式に結合されます。

注意:

複数の条件が同じレベルにあり、同じ演算子で結合される場合は、それらの条件を一度に結合できます。条件のグループを結合する場合、結合により作成された複雑な式をさらに別の条件と結合すると、その複雑な式は、最終的な複雑な式ではカッコ内にネストされます。

5. 複雑な式を元の別々の条件に戻すには、複雑な式を選択し、「選択した条件を分割します」をクリックします。

6. プロパティの構成および条件の作成を行ったら、「作成」をクリックします。
次の図に示すように、サマリー表に新しいアラート・ルールが表示されます。

図4-3 アラート・ルールが定義された「SLAアラート・ルール」タブ

4.6 SLAアラート・ルールの更新

サービスのSLAアラートを作成したら、ルールのプロパティと条件を変更できます。SLAアラートを削除することもできます。

- アラート・ルールの編集

- アラート・ルールの削除

4.6.1 アラート・ルールの編集

アラート・ルールを編集するには:

1. Oracle Service Busコンソールを起動します。詳細は、『Oracle Service Busでのサービスの開発』のスタート・ガイドに関する項を参照してください。

2. 現在セッションに参加していない場合は、「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションに参加します。

3. プロジェクト・ナビゲータで、変更するSLAアラートを含むプロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合をクリックします。

4. 「SLAアラート・ルール」タブをクリックします。

5. 使用可能なオプションのリストから新しい値を選択することによって、アラート・ルールの次のフィールドのいずれかを変更します。

- 重大度

- 次のルールの処理

- 頻度

6. ルールを無効にするには、「有効」チェック・ボックスを選択解除します。ルールを有効にするには、チェック・ボックスを選択します。

7. 有効期限を入力または変更するには、「有効期限日」列の「日付の選択」をクリックし、有効期限を選択します。

8. アラート・ルールのその他のプロパティと条件を更新するには、更新するルールを選択し、サマリー表の上の「編集」アイコンをクリックします。オンライン・ヘルプまたは「サービス・レベル・アグリーメントのアラート・ルールの作成」で説明されているフィールドのいずれかを更新します。

9. 変更の終了後、「保存」アイコンをクリックします。

10. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

4.6.2 アラート・ルールの削除

アラート・ルールを削除するには:

1. Oracle Service Busコンソールを起動します。詳細は、『Oracle Service Busでのサービスの開発』のスタート・ガイドに関する項を参照してください。

2. 現在セッションに参加していない場合は、「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションに参加します。

3. プロジェクト・ナビゲータで、削除するSLAアラートを含むプロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合をクリックします。

4. 「SLAアラート・ルール」タブをクリックします。

5. 削除するアラート・ルールを選択し、サマリー表の上の「削除」をクリックします。

アラート・ルールは現在のセッションで削除されます。

6. 変更の終了後、「保存」アイコンをクリックします。

7. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

4.7 SLAアラートおよびパイプライン・アラートのモニター

Fusion Middleware ControlでSLAアラートおよびパイプライン・アラートをモニターしているとき、ドメイン内のすべてのアラートまたはアラートのサブセットの統計を表示したり、特定のアラートに関する詳細情報を表示したり、アラートを削除またはパージしたりできます。特定のアラートに対してアラート・ルールがどのように構成されているかを表示することもできます。

図4-4 「Service Bus」の「アラート履歴」ページ

4.7.1 アラートのレポートの有効化

SLAアラートをモニターするためには、モニターとSLAアラートの両方をグローバル・レベルで有効にする必要があります。グローバル設定の構成の詳細は、「グローバル・レベルの操作設定の構成」を参照してください。

グローバル設定が構成されたら、SLAアラートをモニターする各サービスに対してモニターとSLAアラートを有効にすることも必要になります。アラート・レベルを指定することもできます。手順は、次のトピックを参照してください。

- 単一のサービスに対する操作設定の有効化と無効化

- サービスのSLAアラート・レベルの構成

4.7.2 ドメイン内のすべてのSLAアラートおよびパイプライン・アラートの表示

ドメイン内のすべてのアラートを表示するには:

1. ターゲットのナビゲータで、「SOA」を展開し、「service-bus」を選択します。

Service Busの「ダッシュボード」ページがデフォルトの選択肢とともに表示されて、過去30分間のSLAアラートが示されます。

2. アラート・タイプについては、「SLAアラート」または「パイプライン・アラート」を選択します。

3. 「アラート履歴期間」フィールドで、アラートを表示する時間(現時点からさかのぼる時間)の長さを選択します。

ページが更新されて、指定したタイプおよび期間のアラートのみが表示されます。

4. 次のいずれかの操作を実行します。

- 特定の重大度のアラートに関する詳細を表示するには、円グラフの該当するセクションをクリックします。

- アラートの履歴をさらに表示するには、アラート履歴表の上の「詳細の表示」をクリックします。

- 特定のアラートに関する詳細を表示するには、アラートの名前をクリックします。アラートの名前の近くに情報アイコンがある場合は、アイコンにカーソルを移動すると、注釈が表示されます。

- 別のサーバーで実行されているサービスの状態を表示するには、サービス・ヘルス・スナップショット表の上の「サーバー」フィールドで新しいサーバー名を選択します。

- 最後の統計リセット以降に取得された情報に基づいてサービスの状態を表示するには、サービス・ヘルス・スナップショットの横のフィールドで「最後のリセット以降」を選択します。

- 特定のサーバーで実行されているサービスの状態に関する詳細を表示するには、サービス・ヘルス・スナップショット表の上の「詳細の表示」をクリックします。

- このページの任意の表で特定のサービスに関する詳細を表示するには、そのサービスの名前をクリックします。

4.7.3 SLAアラートおよびパイプライン・アラートのフィルタ

Service Busの「アラート履歴」ページでは、表示する特定のアラートを検索できます。アラートはWebLogic診断フレームワークを使用して格納されます。このフレームワークには、ワイルドカード文字などの独自の問合せ言語が含まれています。アラート履歴のアラートをフィルタするには、『Oracle WebLogic Server診断フレームワークの構成と使用』の「WLDF問合せ言語」に記載されている構文を使用してください。

「ダッシュボード」ページで、SLAアラートおよびパイプライン・アラートの円グラフの特定の領域をクリックして、選択した重大度レベルおよびアラート履歴期間のアラートに関する「アラート履歴」ページを表示することもできます。

注意:

このページは、「ダッシュボード」ページでアラートを選択したときも表示されます。

Service Busホーム・ページからアラートの検索を実行するには:

1. ターゲットのナビゲータで、「SOA」を展開し、「service-bus」を選択します。

Service Busの「ダッシュボード」ページが表示されます。

2. 「アラート履歴」タブをクリックします。

3. ページの上部に、検索するアラートの基準を入力します。

次の検索基準を入力できます。これらのフィールドの詳細は、Fusion Middleware Controlで提供されているオンライン・ヘルプを参照してください。

- アラート・タイプ

- SLAアラートのアラート・ルール名またはパイプライン・アラートのアラート・サマリー
アラート・サマリー・テキストなしで設計されたパイプライン・アラート・アクションを検索するには、Oracle Service Bus Alertと入力します。

- アラート重大度
指定された重大度レベルまたはそれ以上に検索を制限するには、「またはそれ以上」チェック・ボックスを選択します。

- アラート・ルールが定義されているサービスの名前

- 日付範囲

4. 検索基準を入力したら、「検索」をクリックします。

基準に一致するアラートがすべて、アラート表に表示されます。

5. アラート履歴表での検索結果の表示を調整するには、表の上の「表示」メニューを使用して、次のいずれかの手順を実行します。

- 列: 表内で表示する列を選択するには、このオプションを使用します。「列の管理」をクリックすると、非表示にする列および表示する列を選択できるダイアログが開きます。

- ソート: 列を昇順でソートするか、降順でソートするかを指定するには、このオプションを使用します。「拡張ソート」を選択すると、結果をソートする列および順序を選択できるダイアログが開きます。

- 列の並替え: 表示される列の順序を変更できるダイアログを開くには、このオプションを使用します。

6. 入力したすべての基準をクリアするには、「リセット」をクリックします。

4.7.4 SLAアラートおよびパイプライン・アラートの詳細の表示

Service Busダッシュボードの「アラート履歴」表または「アラート履歴」ページにアラートが表示されたら、アラートの名前をクリックして、そのアラートに関する詳細を表示できます。

4.7.4.1 Service Busダッシュボードでのアラートの詳細の表示

Service Busダッシュボードでアラートの詳細を表示できます。

ダッシュボードでアラートの詳細を表示するには:

1. ターゲットのナビゲータで、「SOA」を展開し、「service-bus」を選択します。

Service Busの「ダッシュボード」ページが表示されます。

2. アラートの名前の横に情報アイコンがある場合は、そのアラートに注釈が追加されていることを意味します。注釈テキストを表示するには、このアイコンにカーソルを移動します。

3. アラート履歴表で、アラートの名前またはサマリーをクリックします。

「アラート詳細」ダイアログが表示されます。

4. 注釈を更新するには、テキスト・ボックスに新しいテキストを入力し、「適用」をクリックします。

5. 前へまたは次へのボタンをクリックして、表内の他のアラートの情報を表示します。

6. 情報を確認したら、「閉じる」をクリックします。

4.7.4.2 「アラート履歴」ページでのアラートの詳細の表示

「アラート履歴」ページでアラートの詳細を表示できます。

「アラート履歴」ページでアラートの詳細を表示するには:

1. ターゲットのナビゲータで、「SOA」を展開し、「service-bus」を選択します。

Service Busの「ダッシュボード」ページが表示されます。

2. 「アラート履歴」タブをクリックします。

3. 「SLAアラートおよびパイプライン・アラートのフィルタ」の説明に従って、表示するアラートを検索します。

4. アラート履歴表で、アラートの名前またはサマリーをクリックします。

「アラート詳細」ダイアログが表示されます。

5. 注釈を更新するには、テキスト・ボックスに新しいテキストを入力し、「適用」をクリックします。

6. 前へまたは次へのボタンをクリックして、表内の他のアラートの情報を表示します。

7. 情報を確認したら、「閉じる」をクリックします。

4.7.5 アラート・ルール構成の表示

アラートをトリガーする実際のルールの構成を表示できます。「アラート・ルール」ダイアログには、ルールに関する次の構成情報が表示されます。

- アラート・ルールの名前(SLAアラートの場合のみ)

- ルールの名前と説明

- ルールの有効期限

- ルールが有効か無効か

- アラートの重大度

- アラートの間隔

- アラートの生成後、ルールの処理が停止されるかどうか

- 集約間隔

- 条件式

4.7.5.1 Service Busダッシュボードでのアラート・ルール構成の表示

Service Busダッシュボードでアラート・ルール構成を表示できます。

ダッシュボードでアラート・ルール構成を表示するには:

1. ターゲットのナビゲータで、「SOA」を展開し、「service-bus」を選択します。

Service Busの「ダッシュボード」ページが表示されます。

2. アラート履歴表で、表示するアラートの行の「情報」列にあるアイコンをクリックします。

「アラート・ルール」ダイアログが表示されます。

3. 情報を確認したら、「閉じる」をクリックします。

4.7.5.2 「アラート履歴」ページでのアラート・ルール構成の表示

「アラート履歴」ページでアラート・ルール構成を表示できます。

「アラート履歴」ページでアラート・ルール構成を表示するには:

1. ターゲットのナビゲータで、「SOA」を展開し、「service-bus」を選択します。

Service Busの「ダッシュボード」ページが表示されます。

2. 「アラート履歴」タブをクリックします。

3. 「SLAアラートおよびパイプライン・アラートのフィルタ」の説明に従って、表示するアラートを検索します。

4. アラート履歴表で、表示するアラートの行の「アクション」列にあるアイコンをクリックします。

「アラート・ルール」ダイアログが表示されます。

5. 情報を確認したら、「閉じる」をクリックします。

4.7.6 SLAアラートおよびパイプライン・アラートの削除

Service Busの「アラート履歴」ページにアラートが表示されたら、それらのアラートを個別に削除できます。

アラートを削除するには:

1. ターゲットのナビゲータで、「SOA」を展開し、「service-bus」を選択します。

Service Busの「ダッシュボード」ページが表示されます。

2. 「アラート履歴」タブをクリックします。

3. 「SLAアラートおよびパイプライン・アラートのフィルタ」の説明に従って、削除するアラートを検索します。

4. 削除するアラートが「アラート履歴」ページに表示されている場合は、アラートを選択し、「削除」をクリックします。

削除するアラートを複数選択するには、[Ctrl]キーを使用します。

4.7.7 SLAアラートおよびパイプライン・アラートのパージ

Service Busの「アラート履歴」ページにアラートが表示されたら、選択したタイプのアラート(SLAまたはパイプライン)をすべてパージしたり、特定の時間枠内にトリガーされたアラートのみをパージしたりすることができます。

注意:

このアクションは元に戻すことができません。

1. ターゲットのナビゲータで、「SOA」を展開し、「service-bus」を選択します。

Service Busの「ダッシュボード」ページが表示されます。

2. 「アラート履歴」タブをクリックします。

3. 「SLAアラートおよびパイプライン・アラートのフィルタ」の説明に従って、アラートを検索します。

4. アラートがアラート履歴表に表示されている場合は、「パージ」をクリックします。

「アラート履歴のパージ」ダイアログが表示されます。

5. 次のいずれかを行います。

- すべてのSLAアラートを完全に削除するには、「すべて」を選択します。

- 特定の日付範囲内にトリガーされたSLAアラートを完全に削除するには、「パージ開始日時」/「パージ終了日時」を選択し、パージ開始日付とパージ終了日付を入力するか、カレンダ・アイコンを使用して日付を選択します。
日付を手動で入力する場合は、MM/DD/YY HH:MM AM|PMという形式を使用してください。

6. 「パージ」をクリックします。

注意:

アラートのパージ元のサーバーが使用可能でない場合、ロギング・フレームワークでパージのレコードを保持し、30分ごとにサーバーをポーリングして、使用可能かどうかを確認します。ロギング・フレームワークによってサーバーが使用可能であることが確認されると、アラートがパージされます。

5 Oracle Service Busのサービス・ヘルスのモニター

この章では、サービス・ヘルス統計を使用して、Service Busプロジェクトおよびサービスのヘルスをモニターする方法について説明します。レスポンス時間やメッセージ、エラーおよびアラートの数などの統計は、問題の検出、分析および修正に役立ちます。

この章の内容は次のとおりです。

- サービス・ヘルスのメトリックについて

- サービス・ヘルス統計のモニター

- サービス・モニターの統計のリセット

5.1 サービス・ヘルスのメトリックについて

Service Busは、Fusion Middleware Controlを使用して、実行中のサービスおよびプロジェクトのヘルスのモニターに役立てるため、統計を収集します。「サービス・ヘルス」ページを使用して、ドメイン内のすべてのサービスを表示したり、特定のサービスを検索して表示できます。そして、「サービス」リストからサービスを選択して、そのサービス独自の「ダッシュボード」ページにサービスの状態に関する詳細情報を表示することができます。

現在の集約間隔に基づいて統計をモニターしたり、統計が最後にリセットされて以降の累積統計をモニターしたりすることができます。ドメイン、プロジェクトまたはサービスに対して、いつでも統計をリセットできます。

集約間隔に基づいて統計を表示する場合、各サービスによって収集された統計データの動的ビューが提供されます。このとき、表示される統計は集約間隔によって決まります。たとえば、特定のサービスの集約間隔が20分である場合、そのサービスの行には最後の20分間に収集されたデータが表示されます。集約間隔の詳細は、「集約間隔について」を参照してください。

5.1.1 ドメインとプロジェクトのサービス・ヘルス・メトリック

ドメインまたはプロジェクトのメトリックを表示する際、表示される統計は、各サービスに対して収集された一般メトリックのサブセットのみです。この統計には、集計間隔、平均レスポンス時間、メッセージ数、エラー数およびアラート数が含まれます。サービス・ヘルス・メトリックは、モニターが有効なサービスにのみ表示されます。

次の表に、それぞれの種類のサービスに表示されるメトリックを示します。収集される統計の詳細リストは、「Oracle Service Busについて収集される統計」を参照してください。

表5-1 Oracle Service Busサービスのメトリック

メトリック

説明

平均実行時間

プロキシ・サービスの場合、トランスポートにおけるメッセージの受信時から例外処理時またはレスポンス送信時までの時間の平均を示します。

ビジネス・サービスの場合、アウトバウンド・トランスポートにおけるメッセージの送信時から例外受信時またはレスポンス受信時までの時間の平均を示します。

メッセージの総数

サービスに送信されたメッセージの数です。JMSプロキシ・サービスで、例外によってトランザクションが中断され、メッセージが失われないようにキューに戻された場合、デキューが再試行されるたびに別々のメッセージとしてカウントされます。同様に、アウトバウンド・トランザクションの場合、再試行またはフェイルオーバーのたびに別々のメッセージとしてカウントされます。

エラーがあるメッセージ

エラー・レスポンスを伴うメッセージの数です。

プロキシ・サービスの場合、システム・エラー・ハンドラまたは返信失敗アクションによって終了される原因となったメッセージの数を示します。エラーがサービス内で処理され、返信が成功するか再開アクションが行われる場合、エラーとして扱われません。

ビジネス・サービスの場合、トランスポート・エラーまたはタイムアウトの原因となったメッセージの数を示します。再試行およびフェイルオーバーは別々のメッセージとして扱われます。

成功/失敗率

(メッセージの総数 - エラーが発生したメッセージの数)/エラーが発生したメッセージの数

セキュリティ

WS-Securityエラーを伴うメッセージの数です。このメトリックは、プロキシ・サービスおよびビジネス・サービスの両方で計算されます。

検証

フロー内の検証アクションで失敗した数です。このメトリックは、プロキシ・サービスとパイプラインにのみ適用されます。

5.1.2 プロキシ・サービスのメトリック

プロキシ・サービスの「ダッシュボード」ページでは、サービスについて次のタイプのメトリックを表示できます。

- 全般: 現在の集約間隔または最後のリセット以降のプロキシ・サービス・ステータスのスナップショットを表示します。これには、アラート、レスポンス時間、メッセージ数、エラー数、失敗率と成功率などが含まれます。

- 操作: WSDLベースのサービスで定義されている操作の統計を表示します。サービスで定義されているWSDL操作がない場合、この表は空になります。

5.1.3 ビジネス・サービスのメトリック

ビジネス・サービスの「ダッシュボード」ページでは、サービスについて次のタイプのメトリックを表示できます。

- 全般: 現在の集約間隔または最後のリセット以降のビジネス・サービス・ステータスのスナップショットを表示します。これには、アラート、レスポンス時間、メッセージ数、エラー数、失敗率と成功率などが含まれます。

- 結果キャッシュ: サービスに対して結果キャッシュがどのように使用されているかに関する情報を表示します(結果キャッシュが有効な場合)。

- スロットル: ビジネス・サービスのスロットル統計を表示します(スロットルが有効な場合)。これには、最小、最大および平均スロットル時間(ミリ秒単位)などが含まれます。

- 操作: WSDLベースのサービスで定義されている操作の統計を表示します。サービスで定義されているWSDL操作がない場合、この表は空になります。

- エンドポイントURI: ビジネス・サービスに対して構成されている様々なエンドポイントURIの統計を表示します。これには、状態、メッセージ数、エラー数、レスポンス時間などが含まれます。このビューからURIをオンラインにしたり、オフラインにしたりすることもできます。詳細は、「ビジネス・サービスに対するエンドポイントURIのメトリックの表示」」および「エンドポイントURIをモニターするためのメトリック」を参照してください。

5.1.4 パイプライン・サービスのメトリック

パイプラインの「ダッシュボード」ページでは、パイプラインについて次のタイプのメトリックを表示できます。

- 全般: 現在の集約間隔または最後のリセット以降のパイプライン・ステータスのスナップショットを表示します。これには、アラート、レスポンス時間、メッセージ数、エラー数などが含まれます。

- 操作: WSDLベースのサービスで定義されている操作の統計を表示します。サービスで定義されているWSDL操作がない場合、この表は空になります。

- フロー・メトリック: パイプライン・サービス・レベル、パイプライン(ペア)・レベルまたはアクション・レベルのメッセージ・フローの統計を表示します。これは、パイプラインのモニター・レベルに応じて異なります。統計には、メッセージ数、エラー数およびレスポンス時間が含まれます。アクション・レベルの統計を選択すると、表には、パイプライン内のアクションに関する情報がノードとアクションの階層として表示されます。

5.1.5 分割-結合サービスのメトリック

分割-結合の「ダッシュボード」ページでは、分割-結合について次のタイプのメトリックを表示できます。

- 全般: 現在の集約間隔または最後のリセット以降の分割-結合ステータスのスナップショットを表示します。これには、アラート、レスポンス時間、メッセージ数、エラー数などが含まれます。

- フロー・メトリック: 分割-結合レベル、ブランチ・レベルまたはアクティビティ・レベルのメッセージ・フローの統計を表示します。これは、分割-結合のモニタリング・レベルに応じて異なります。統計には、メッセージ数、エラー数およびレスポンス時間が含まれます。アクション・レベルの統計を選択すると、表には、分割-結合内のアクションに関する情報がノードとアクションの階層として表示されます。

5.2 サービス・ヘルス統計のモニター

Service Busドメインおよびプロジェクトの「サービス・ヘルス」ページには、モニターが有効化されているサービスの全般的なメトリックが表示されます。各サービスの「ダッシュボード」ページには、そのサービスに関するより詳細なメトリックが表示されます。

「現在の集約間隔」ビューには、サービス・メトリックの変動する統計が表示されます。「最後のリセット以降」ビューには、メトリックの集計カウントが表示されます。クラスタが存在する場合はクラスタ全体のメトリックがデフォルトで表示されます。管理対象サーバーを個別に選択してそのサーバーのメトリックを表示します。

サービスのモニターは、デフォルトでは有効化されていません。サービスのモニターを有効にする方法は、「操作設定の表示と構成」を参照してください。デフォルトでは、ダッシュボード・リフレッシュ間隔は、「リフレッシュなし」です。

5.2.1 最も多くのエラーがあるサービスの統計の表示

Service Busダッシュボードには、選択した期間に最も多くのエラーを生成したサービスの特定の統計が表示されます。統計には、平均レスポンス時間、処理されたメッセージの数、生成されたエラーの数、サービスに対して生成されたSLAアラートの数などが含まれます。これは統計の限定セットです。そのサービスの統計の完全なセットを表示するには、サービス名をクリックします。

このページに表示される統計の詳細は、Service Busで提供されているオンライン・ヘルプを参照してください。

最も多くのエラーがあるサービスの統計を表示するには:

1. Fusion Middleware Controlで、「SOA」を展開し、「service-bus」を選択します。

2. Service Busダッシュボードで、「最多エラーのサービス」セクションにスクロールします。

3. 「サービス・ヘルス・スナップショット表」で、現在の集約間隔の統計を表示するか、統計がリセットされて以降の統計を表示するかを選択します。

4. 「サーバー」フィールドで、統計の表示対象のサーバーを選択します。

5. サービスのその他の統計を表示するには、表内のサービス名をクリックします。

選択したサービスの「ダッシュボード」が表示されます。

5.2.2 ドメインのサービス・ヘルス統計の表示

「Service Bus」-「サービス・ヘルス」ページには、モニターが有効なドメイン内のすべてのサービスのヘルス統計が表示されます。これはすべての統計のサブセットです。そのサービスの統計の完全なセットを表示するには、サービス名をクリックします。サービス表内に表示されているサービスは、様々な基準でフィルタできます。次の図は「サービス・ヘルス」ページを示しています。

図5-1 「サービス・ヘルス」ページ

Service Busドメイン内のすべてのサービスの統計を表示するには:

1. Fusion Middleware Controlで、「SOA」を展開し、「service-bus」を選択します。

2. 「サービス・ヘルス」タブをクリックします。

3. 「統計の表示」フィールドで、次のいずれかを実行します。

- 現在の集約間隔のモニター統計を表示するには、「現在の集約間隔」を選択します。

- 統計の最後のリセット以降のサービスのモニター統計を表示するには、「最後のリセット以降」を選択します。

4. 「サーバー」フィールドで、オプションのリストからサーバーを選択して、そのサーバーのメトリックを表示します。

5. 特定のサービスのみをリストするには、次の検索基準のいずれかを入力します。

- 「サービス」フィールドで、検索するサービスのタイプを選択するか、「すべてのサービス」を選択して、すべてのサービス・タイプを表示します。

- 「名前」フィールドに、検索ターゲットの名前を入力します。このフィールドでは、アスタリスクと疑問符(*および?)をワイルドカード文字として使用できます。

- 「パス」フィールドに、検索ターゲットのパスを入力します。このフィールドでは、アスタリスクと疑問符(*および?)をワイルドカード文字として使用できます。
パスには次の形式を使用します。

project-name/root-folder/ . . ./parent-folder

サービスがプロジェクトの直下にある場合、次の形式を使用します。

project-name

- 「プロキシによる呼出し」フィールドで、検索アイコンをクリックし、検索対象のサービスを呼び出すプロキシ・サービスを選択します。

- メッセージのあるサービスのみを表示するには、「メッセージあり」を選択します。

- アラートのあるサービスのみを表示するには、「アラートあり」を選択します。

- エラーのあるサービスのみを表示するには、「エラーあり」を選択します。

- 「リセット」をクリックすると、検索フィルタが削除され、サービスがすべて表示されます。

6. 「検索」をクリックします。

基準に一致するサービスのリストが表示されます。

7. サービスのその他の統計を表示するには、表内のサービス名をクリックします。

選択したサービスの「ダッシュボード」が表示されます。

5.2.3 プロジェクトのサービス・ヘルス統計の表示

「Service Busプロジェクト」-「サービス・ヘルス」ページには、モニターが有効なプロジェクト内のすべてのサービスのヘルス統計が表示されます。これはすべての統計のサブセットです。そのサービスの統計の完全なセットを表示するには、サービス名をクリックします。サービス表内に表示されているサービスは、様々な基準でフィルタできます。次の図にプロキシ・サービスの「ダッシュボード」ページを示します。

図5-2 Service Busサービスの「ダッシュボード」

Service Busプロジェクト内のサービスの統計を表示するには:

1. Fusion Middleware Controlで、「SOA」、「service-bus」の順に開いて、統計を表示するプロジェクトの名前を選択します。

「Service Busプロジェクト」-「サービス・ヘルス」ページが表示されます。

2. 「統計の表示」フィールドで、次のいずれかを行います。

- 現在の集約間隔のモニター統計を表示するには、「現在の集約間隔」を選択します。

- 統計の最後のリセット以降のサービスのモニター統計を表示するには、「最後のリセット以降」を選択します。

3. 「サーバー」フィールドで、オプションのリストからサーバーを選択して、そのサーバーのメトリックを表示します。

4. 特定のサービスのみをリストするには、次の検索基準のいずれかを入力します。

- 「サービス」フィールドで、検索するサービスのタイプを選択するか、「すべてのサービス」を選択して、すべてのサービス・タイプを表示します。

- 「名前」フィールドに、検索ターゲットの名前を入力します。このフィールドでは、アスタリスクと疑問符(*および?)をワイルドカード文字として使用できます。

- 「パス」フィールドに、検索ターゲットのパスを入力します。このフィールドでは、アスタリスクと疑問符(*および?)をワイルドカード文字として使用できます。
パスには次の形式を使用します。

project-name/root-folder/ . . ./parent-folder

サービスがプロジェクトの直下にある場合、次の形式を使用します。

project-name

- 「プロキシによる呼出し」フィールドで、検索アイコンをクリックし、検索対象のサービスを呼び出すプロキシ・サービスを選択します。

- メッセージのあるサービスのみを表示するには、「メッセージあり」を選択します。

- アラートのあるサービスのみを表示するには、「アラートあり」を選択します。

- エラーのあるサービスのみを表示するには、「エラーあり」を選択します。

- 「リセット」をクリックすると、検索フィルタが削除され、サービスがすべて表示されます。

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

基準に一致するサービスのリストが表示されます。

6. サービスのその他の統計を表示するには、表内のサービス名をクリックします。

選択したサービスの「ダッシュボード」が表示されます。

5.2.4 サービスのすべてのサービス・ヘルス統計の表示

各Service Busサービスの「ダッシュボード」ページには、そのサービスのサービス・メトリックの完全なセットおよびサービス固有の統計が表示されますが、サービスでモニターが有効になっている場合に限ります。サービスの「ダッシュボード」ページには、いくつかの方法でアクセスできます。

サービスの状態統計の完全なセットを表示するには:

1. Fusion Middleware Controlで次のページのいずれかにナビゲートします。

- Service Busの「ダッシュボード」ページ。このページにアクセスするには、「SOA」を展開し、「service-bus」を選択します。

- 「Service Bus」-「サービス・ヘルス」ページ。このページにアクセスするには、「SOA」を展開し、「service-bus」を選択して、「サービス・ヘルス」タブをクリックします。

- 「Service Bus」-「アラート履歴」ページ。このページにアクセスするには、「SOA」を展開し、「service-bus」を選択して、「アラート履歴」タブをクリックします。

- 「Service Busプロジェクト」-「サービス・ヘルス」ページ。このページにアクセスするには、「SOA」を展開し、「service-bus」を展開して、プロジェクトの名前をクリックします。

2. 必要に応じて、統計を表示するサービスの検索を実行します。

3. 統計を表示するサービスの名前をクリックします。

5.3 サービス・モニターの統計のリセット

「サービス・ヘルス」ページでは、ドメインまたはプロジェクト内のすべてのサービスのモニター統計、または特定の1つのサービスのモニター統計のみをリセットできます。

統計をリセットすると、統計の最後のリセット以降にサービス、プロジェクトまたはドメインに対して収集されたモニター統計がすべて削除されます。ただし、サービスの現在の集約間隔において収集中の統計は削除されません。統計がリセットされると、サービスのモニター統計の収集がただちに再開されます。

注意:

ブランチまたはアクティビティ・レベルの統計を収集する分割-結合を再デプロイする場合、その統計をリセットして、表示される統計が現在のブランチおよびアクティビティと一致するようにします。

サービス・モニターの統計をリセットするには:

1. 次のいずれかを行います。

- ドメイン内のすべてのサービスの統計をリセットするには、「SOA」を展開し、「service-bus」を選択します。「サービス・ヘルス」タブをクリックします。

- プロジェクト内のすべてのサービスの統計をリセットするには、「SOA」を展開し、「service-bus」を展開して、プロジェクトの名前を選択します。

- 単一のサービスの統計をリセットするには、「サービスのすべてのサービス・ヘルス統計の表示」の説明に従って、サービスの「ダッシュボード」ページにナビゲートします。

2. 「統計の表示」フィールドで「最後のリセット以降」を選択します。

3. 「サーバー」フィールドの右にある「リセット」アイコンをクリックします。

表示されているレベルのすべての統計がリセットされます。

5.3.1 統計のリセットについて知っておくべきこと

サービスの統計をリセットすると、最後のリセット以降にサービスに対して収集された統計がすべて失われます。ドメインの統計をリセットすると、ページ上に表示されているかどうかにかかわらず、モニターされているすべてのサービスの統計がリセットされます。リセット・アクションは、元に戻せません。エンドポイントURIのステータスは、統計をリセットしてもリセットされません。

6 リシーケンス・グループのモニター

この章では、実行中のパイプラインのリシーケンス・グループをモニターする方法と、メッセージのリシーケンス中および処理中に発生したエラーからの回復方法について説明します。

この章の内容は次のとおりです。

- リシーケンス・グループについて

- リシーケンスの実行時の構成

- リシーケンス・グループおよびメッセージのモニター

- リシーケンス・グループの実行時の管理

6.1 リシーケンス・グループについて

Service Busパイプラインは、リシーケンサを使用して、ランダムな順序で到着するメッセージを、選択したリシーケンス方針に基づいて新しい順序に並べ替えるように構成できます。

リシーケンス方針には、ベスト・エフォート、標準およびFIFOがあります。メッセージは、そのメッセージのリシーケンス・グループIDとシーケンスIDに基づいてリシーケンスされます。これらのIDは、パイプライン構成で定義します。それぞれの方針でメッセージを順序付けする方法の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のリシーケンサの概要に関する項および順序のリシーケンスに関する項を参照してください。

Fusion Middleware ControlのService Busホーム・ページにある「リシーケンス・メッセージ」タブにはリシーケンス情報が表示されるため、リシーケンス・グループのヘルスをモニターできます。このページには、メッセージとグループのステータスが、各メッセージとグループに関連付けられたService Busのパイプラインおよびプロジェクトとともに示されます。このページからは、タイムアウトになったグループのロック解除、失敗したメッセージの再送信、グループの処理をブロックしているメッセージのスキップを実行できます。

ヘルスの統計は、リシーケンサには公開されません。そのかわりに、関連するサービス・コンポーネント(パイプライン・サービスやプロキシ・サービスなど)の統計をモニターできます。

6.1.1 Oracle Service Busリシーケンス・メッセージの状態

「リシーケンス・メッセージ」ページには、リシーケンス・グループおよびメッセージのメッセージ処理に関する実行ステータスが表示されます。リシーケンス・メッセージは、次のいずれかの状態になります。

- 実行中

- フォルト

- 完了

- 中止

グループが実行中状態のときには、すべてのメッセージが正常に処理されています。完了状態の場合は、すべての利用可能なメッセージの処理を完了しています。リシーケンス・グループは、リシーケンス・エラー、メッセージ・エラー、データベース・エラー、またはグループ・タイムアウトのためにフォルト状態になることがあります。「完了メッセージのパージ」グローバル設定が選択されていない場合、完了メッセージのみが結果に表示されます。それ以外の場合、完了メッセージはデータベースからパージされ、このページに表示できません。

6.1.2 リシーケンサのエラー処理

フォルトやタイムアウトが原因で、リシーケンス・グループにおけるメッセージ処理が中断されたときには、中断されたグループに関する追加情報を確認して、メッセージ処理の再開方法を指定できます。フォルトのタイプによっては、メッセージの処理をキャンセルすることも、ペイロードを変更してメッセージを再処理することもできます。グループがタイムアウトになったときには、その次に利用可能なインスタンスにスキップして処理を再開できます。

リシーケンス・エラーは、メッセージ永続性またはメッセージ実行の進行中に発生することがあります。永続性エラーには、グループIDまたはシーケンスIDの評価時に発生するものや、ペイロードおよびメッセージ・コンテキストの変数を永続化するときに発生するものがあります。実行エラーには、データベースへのアクセス時に発生するものや、パイプラインに送信されたときのメッセージの処理時に発生するものがあります。グループのタイムアウトは、到着しないメッセージをグループが予期して待機しているときに、標準リシーケンサで発生することがあります。

6.1.3 リシーケンサ・データベース

リシーケンサのメッセージ処理はデータベースに依存します。データベース表は、Service Busメインの作成時にリポジトリ作成ユーティリティ(RCU)を実行すると自動的に作成されます。メッセージは、リシーケンサのグローバル設定でデータベースからパージするように構成したときにのみ、データベースからパージされます。メッセージおよびメッセージのメタデータをパージする方法の詳細は、「完了リシーケンサ・メッセージの自動パージ」を参照してください。

Service Busには、データベース内のリシーケンサの表をパージおよび管理するためのスクリプトが用意されています。詳細は、「リシーケンサ表の管理」を参照してください。

6.1.4 デプロイメント・アクティビティがリシーケンスに与える影響

リシーケンサはアクティブ化した後で変更を加えると、実行時のメッセージ処理方法に影響を与えます。リシーケンサに影響するアクティビティとして、リシーケンサ構成の更新、リシーケンサの削除、またはリシーケンサに関連付けられたパイプラインの名前変更や移動があげられます。通常の処理時、リシーケンサはメッセージをデータベースに格納し、メッセージの並べ替えが完了すると、メッセージは別のスレッドで実行されます。メッセージの処理中にパイプラインからリシーケンサを削除すると、次の事項が発生します。

- データベースから処理のために取り出されていないメッセージは、データベースに維持されます。自動的にクリーンアップされることはありません。

- その時点で処理のためにデータベースから取り出されている(ただし、パイプラインには送信されていない)メッセージは、リシーケンサがアンデプロイされたことを示すエラー・メッセージを生成します。これらのメッセージもデータベースに維持されます。

- その時点でパイプラインで処理されているメッセージは、それまでのリシーケンサ構成を使用して実行されます。

リシーケンサに関連付けられたパイプラインを名前変更または移動すると、そのリシーケンサは停止し、新しいリシーケンサ・インスタンスが新しいパスを使用して作成されます。変更が行われた時点でメッセージの処理が完了している場合は、前述したようにメッセージが処理されます。

メッセージの処理中にリシーケンサ構成を更新すると、メッセージが処理されなくなる可能性があります。たとえば、グループIDを変更すると、元のグループIDでデータベースに格納されているメッセージは処理のために取り出されなくなり、手動で消去するまでデータベースに維持されます。

6.1.5 サーバーのシャットダウンがリシーケンスに与える影響

リシーケンサは、サーバーがシャットダウンされたときに、メッセージがプロセスのどの段階にあるかによって異なる方法でメッセージを処理します。ここでは、異なる3つのケースについて説明します。

6.1.5.1 Service Busからリシーケンサにメッセージが転送されているときのサーバー・シャットダウン

メッセージ永続性のために、リシーケンサは、その時点でトランザクションが存在する場合はそのトランザクションに加わります。トランザクションが存在しない場合は、リシーケンサが独自のトランザクションを開始します。プロキシ・サービスがトランザクションの場合、そのトランザクションはロールバックされ、メッセージはインバウンド・サービスのトランザクション設定に基づいて再配信されます。プロキシ・サービスがトランザクションでない場合は、メッセージが失われることがあります。これは、サーバーがシャットダウンされる前に、リシーケンサのトランザクションがコミットできたかどうかによって決まります。

6.1.5.2 ロッカー・スレッドによってグループがロックされているときのサーバー・シャットダウン

ロッカーがグループにロック済のマークを付けていて、そのグループのメッセージを処理する予定のサーバーがシャットダウンされると、リシーケンサは、このグループを処理するために別の管理対象サーバーに移動することを試行します。

6.1.5.3 メッセージがリシーケンサで処理されているときのサーバー・シャットダウン

メッセージの処理中にサーバーがシャットダウンされると、そのメッセージはリシーケンサで利用可能な状態を維持し、サーバーがオンラインになったときに処理されます。メッセージがリシーケンサからService Busに処理のために2回送信される状況がいくつか存在します。たとえば、リシーケンサがトランザクションを開始してからService Busのディスパッチを呼び出す場合は、その後でサーバーがシャットダウンされると、サーバーがオンラインに戻ったときにメッセージが処理のために再度送信されます。

6.2 リシーケンスの実行時の構成

リシーケンサを使用するサービスでは、実行時にリシーケンサがメッセージを処理する方法を制御するグローバル設定を構成できます。Service Busには、これらのリシーケンサの操作設定が用意されています。

これらは、グローバル設定専用であり、サービス・レベルでは適用できません。

- リシーケンサ・ロッカーのスレッドのスリープ: ロッカー・スレッドのスリープ間隔(秒単位)。処理できるメッセージを持つグループをリシーケンサが見つけられないときに、ロッカー・スレッドは指定した期間スリープ状態になります。処理可能なメッセージを持つグループが見つかった場合は、データベース・シークの各繰返しの間でロッカー・スレッドがスリープ状態になることはありません。

- リシーケンサ最大ロック済グループ数: データベース・シークの1回の繰り返しで処理のために取得できるリシーケンサ・グループの最大数。取得されたグループは、処理用のワーカー・スレッドに割り当てられます。

- 完了メッセージのパージ: このオプションを選択すると、Service Busは、処理が完了しているリシーケンス済メッセージをリシーケンサ・データベースからパージします。

グローバル設定の構成の詳細は、「操作設定の表示と構成」を参照してください。

注意:

リシーケンスに成功したインスタンスと失敗したインスタンスをモニターする場合は、パイプラインの実行トレースも有効にしてください。

6.3 リシーケンス・グループおよびメッセージのモニター

リシーケンス済メッセージは、Service Busホーム・ページから「リシーケンス・メッセージ」タブでモニターできます。

「リシーケンス・メッセージ」ページでは、モニターする特定のグループやコンポーネントを検索して、その結果にメッセージの状態によるフィルタを適用できます。このページを使用して、メッセージの失敗があったかどうか、またはすべてのグループがメッセージを正常に処理しているかを確認します。

6.3.1 リシーケンス・グループおよびメッセージのモニター

リシーケンス済メッセージについてモニターできる情報には、グループおよびメッセージID、メッセージとそれが属するプロジェクトを処理するサービス、現在のメッセージ・ステータス、およびWSDL操作がある場合はその名前が含まれます。次の図は「リシーケンス・メッセージ」ページを示しています。

図6-1 「リシーケンス・メッセージ」ページ

リシーケンス・グループおよびメッセージをモニターするには:

1. Fusion Middleware Controlで、「SOA」を開き、「service-bus」を選択します。

2. 「リシーケンス・メッセージ」タブをクリックします。

3. 特定のグループのみをリストするには、次の検索基準のいずれかを入力します。

- 「リシーケンス・グループ」フィールドに、モニターするメッセージのグループ名を入力します。

- 「名前」フィールドで「参照」アイコンをクリックして、モニターするリシーケンス・メッセージに関連するService Busパイプラインを検索し、選択します。

- 「状態」フィールドで、オプションのドロップダウン・リストから1つ以上の状態を選択します。

注意:

デフォルトでは、「フォルト」と「実行中」が両方選択されています。完了したメッセージは、「グローバル設定」ページで「完了メッセージのパージ」が選択されていない場合のみ表示できます。パージ・オプションが選択されているときに完了したメッセージは、ここには表示できません。

- 「リセット」をクリックすると、検索フィルタが削除され、リシーケンス・メッセージがすべて表示されます。

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

指定した基準と一致するリシーケンス・メッセージのリストが、「リシーケンス・メッセージ」表に表示されます。表示されるフィールドの詳細は、このページのオンライン・ヘルプを参照してください。メッセージの状態の詳細は、「Oracle Service Busリシーケンス・メッセージの状態」を参照してください。

5. 次の追加手順のいずれかを実行します。

- リシーケンス・グループに関する情報の表示

- メッセージのシーケンスIDのスキップ

- リシーケンス・グループがタイムアウトになった場合の回復方法

- リシーケンスのフォルトからの回復

6.3.2 リシーケンス・グループに関する情報の表示

「リシーケンス・メッセージ」表でグループIDをクリックすると、「リシーケンス・グループ」ダイアログが開きます。このダイアログには、そのグループがメッセージを正常に処理しているかどうかを示すメッセージが表示されます。「リシーケンス・グループ」ダイアログには、グループに関して次に示す情報が示されます。また、示される情報はグループの状態に応じて異なります。

- グループがタイムアウト状態またはフォルト状態であるかどうか

- グループ内のブロッキング・メッセージ(存在する場合)

- グループのロック解除後に処理される後続のメッセージ

- グループ内のメッセージ処理の停止後の時間

- グループのロック解除のための指示テキスト

リシーケンス・グループに関する情報を表示するには:

1. 「リシーケンス・メッセージ」タブを表示します(「リシーケンス・グループおよびメッセージのモニター」を参照)。

2. 表示するメッセージIDを持つグループの名前をクリックします。

「リシーケンス・グループ」ダイアログが表示されます。

3. リシーケンスの問題を処理するために、「リシーケンス・グループの実行時の管理」で説明されているタスクを実行します。選択したメッセージが処理中の場合、ダイアログには、そのグループが現在メッセージを処理していると簡単に表示されます。

6.4 リシーケンス・グループの実行時の管理

リシーケンス・グループにメッセージ・エラー、データベース・エラー、またはタイムアウトが発生したときに、Service Busには、その問題から回復する(場合によっては、問題を修正する)手段が用意されています。

グループ内でスタック状態になっていて、追加のメッセージの処理をブロックしているメッセージはスキップできます。また、フォルトが発生したメッセージのペイロードを変更して、そのメッセージの再処理を試行することもできます。次からの各項では、リシーケンスの問題を修正する方法と、その問題から回復する方法について説明します。

6.4.1 メッセージのシーケンスIDのスキップ

標準リシーケンサ・グループの場合は、「リシーケンス・グループ」ダイアログに、次順のシーケンスIDをスキップして、シーケンス内の後続メッセージの処理を再開するオプションが提供されます。これは、グループが実行中であっても、到着することのないメッセージを待機している可能性がある場合に役立ちます。標準リシーケンサは、それぞれのグループに正しいシーケンスを生成できるようになるまで、メッセージをデータベースに保留します。特定のグループの次順のシーケンスIDを持つメッセージがいつまでも到着しない場合、そのグループの保留中のメッセージは、グループのロックを手動で解除して後続メッセージにスキップするまで保留され続けます。

注意:

シーケンスIDを手動でスキップした後で、そのIDを持つ欠落メッセージが到着したときには、そのメッセージを処理する必要がある場合、Fusion Middleware Controlでそのメッセージを手動で実行する必要があります。このメッセージは、自動的には回復されません。

リシーケンス・グループ内のメッセージをスキップするには:

1. 「リシーケンス・メッセージ」タブを表示します(「リシーケンス・グループおよびメッセージのモニター」を参照)。

2. 標準リシーケンス・グループの名前をクリックします。

「リシーケンス・グループ」ダイアログが表示されます。

3. 現在のシーケンスIDをスキップして、グループ内で次に利用可能なインスタンスの処理を開始するには、「スキップ」をクリックします。

6.4.2 リシーケンス・グループがタイムアウトになった場合の回復方法

グループは、予期されるメッセージの待機中にグループの処理が停止するとタイムアウト状態になり、グループ内の残りのメッセージをブロックするようになります。次順のシーケンスIDにスキップすると、グループのブロックを解除できます。タイムアウトになったグループには、次の情報が表示されます。

- 最後に処理したメッセージのシーケンスID

- 次に処理されるメッセージのシーケンスIDと、そのメッセージのインスタンスID

注意:

シーケンスIDを手動でスキップした後で、そのIDを持つ欠落メッセージがタイムアウト後に到着したときには、Fusion Middleware Controlでそのメッセージを手動で実行する必要があります。これは、自動的には回復されません。

グループのタイムアウトから回復するには:

1. 「リシーケンス・メッセージ」タブを表示します(「リシーケンス・グループおよびメッセージのモニター」を参照)。

2. タイムアウトになったグループの名前をクリックします。

「リシーケンス・グループ」ダイアログが表示されます(図6-2を参照)。

図6-2 タイムアウト状態のリシーケンス・グループ

3. グループのロックを解除して、グループ内で次に利用可能なインスタンスの処理を開始するには、「スキップ」をクリックします。

6.4.3 リシーケンスのフォルトからの回復

グループは、グループ内のいずれかのメッセージが処理中にエラーをスローしたときに、フォルト状態になります。フォルトが発生したときには、メッセージを修正して再試行することも、メッセージの処理をキャンセルすることもできます。フォルトのあるリシーケンス・グループについては、フォルトが発生したグループの「リシーケンス・グループ」ダイアログに、次の情報が示されます。

- 最後にメッセージが処理された時間

- フォルトが発生したメッセージのシーケンスID

- 次に処理されるメッセージのシーケンスIDと、そのメッセージのインスタンスID

- ペイロード

リシーケンスのフォルトから回復するには:

1. 「リシーケンス・メッセージ」タブを表示します(「リシーケンス・グループおよびメッセージのモニター」を参照)。

2. ステータスが「フォルト」のグループの名前をクリックします。

「リシーケンス・グループ」ダイアログが表示されます(図6-3を参照)。

図6-3 フォルト状態のリシーケンス・グループ

3. 次のいずれかを行います。

- メッセージを回復するには、エラーを修正するためにペイロードのテキストを変更して、「リカバリ」をクリックします。

- メッセージの処理をキャンセルして次に進むには、「中止」をクリックします。

7 ログ・ファイルの構成とモニター

この章では、診断ログ・ファイルを使用した、Oracle Service Busサービスのモニター方法について説明します。Service Busのロギングは、Oracle Diagnostic Logging (ODL)に基づいています。

この章の内容は次のとおりです。

- Oracle Service Busのロギングについて

- Oracle Service Bus用のDiagnostic Loggingの構成

- Oracle Service Busの診断ログ・ファイルの表示

- Oracle Service Busのログ出力

- 11gからアップグレードした後のログ構成

ODLおよび診断ログ・ファイルについては、『Oracle Fusion Middlewareの管理』のログ・ファイルと診断データの管理に関する項を参照してください。

7.1 Oracle Service Busのロギングについて

Service Busコンポーネントは、すべてのタイプのイベントを記録するメッセージを含むログ・ファイルを生成します。これには、起動およびシャットダウン情報、エラー、警告メッセージ、HTTPリクエストに関するアクセス情報などの詳細情報が含まれます。

Service Busは、Oracle Diagnostic Logging (ODL)を使用して、診断ログ・ファイルの標準フォーマット、コンテンツおよびファイル処理を定義します。ロギングの標準アクションに加えて、Service Busは、ログ・アクションがあり、かつロギングが有効である任意のパイプラインおよび分割-結合に対して、診断ログ・ファイルにエントリを追加します。

ODLでは、最大ログ・ファイル・サイズなど、保存される診断情報の量を制限することができます。個別の製品コンポーネントのログ・メッセージを管理するためのいくつかのログ・ハンドラが用意されており、標準ログ・メッセージ書式も提供されます。

7.1.1 ODLログ・ファイル

ODLフレームワークは、domain_name/servers/server_name/logs/server_name-diagnostic.logに診断ログ・メッセージを書き込みます。このファイルは、すべてのODLログ出力のデフォルトのログ・ファイルです。新しいログ・ファイルを作成したり、ログ・ファイルの場所を変更したりすることができます。ログ・ファイルが指定したサイズになると、名前が変更され、新しいログ・ファイルが作成されます。ログ・ファイル・ストレージの合計が指定したサイズになると、最も古いログ・ファイルが削除されます。

7.1.2 ODLロギング・レベル

ログ・ハンドラに指定されているODLロギング・レベルによって、ログ・ファイルに書き込まれる情報の量が決まります。ログ・レベルには、メッセージ・タイプやメッセージ・レベルが含まれます。特定のレベルのロギングを有効にすると、それ以上のレベルのすべてのロギングも有効になります。

ODLで定義されるメッセージ・タイプは次のとおりです。

- INCIDENT_ERROR

- ERROR

- WARNING

- NOTIFICATION

- TRACE

メッセージ・レベルによって、メッセージ・タイプがさらに制限され、メッセージの重大度が示されます。値は、1(最も重大度が高いことを示します)から32(最も重大度が低いことを示します)までの整数です。メッセージ・タイプおよびレベルはともに、java.util.logging.Levelで定義されているレベルにマップされます。たとえば、TRACE:32はFINESTにマップされ、NOTIFICATION:1はINFOにマップされます。Fusion Middleware Controlでは、「ログ構成」ページにマッピングが表示されます。

ロギング・レベルの詳細は、Oracle Fusion Middlewareの管理のログ・ファイルに書き込まれる情報レベルの設定に関する項を参照してください。

7.1.3 ODLメッセージ書式

すべての製品は、可読性を向上させるため、標準の書式でODLログ・メッセージを書き込みます。書式は次のとおりです。

[timestamp] [component id] [messagetype:level] [message-id] [module id] ([field-name: field-value])* message-text [supplemental-detail]

すべてのメッセージ・コンポーネントの説明など、ログ・エントリの書式の詳細は、Oracle Fusion Middlewareの管理のODLメッセージおよびODLログ・ファイルの理解に関する項を参照してください。

7.1.4 ODLログ構成

ODLログ・ファイルおよびログ・レベルは、Fusion Middleware ControlやWLSTコマンドを使用して、またはlogging.xmlを直接変更して構成できます(後者の方法はお薦めしません)。ログ構成を更新すると、変更はただちに有効になり、サーバーの再起動は必要ありません。Fusion Middleware ControlまたはWSLTコマンドを使用して、ログ・ファイルの表示と検索、新しいログ・ファイルの作成、ログ・ファイルの場所の変更、各ログ出力の重大度の変更などを行うことができます。

logging.xmlファイルは、domain_name/config/fmwconfig/servers/server_nameにあります。デフォルトでは、Service Bus固有のこのファイルにはログ出力エントリがないため、この方法を使用してロギングを変更する場合は、Service Busのログ出力に手動で追加する必要があります。ログ出力のリストは、「Oracle Service Busのログ出力」を参照してください。

7.1.5 Oracle Service Busのログ出力

Service Busには、様々なモジュールのメッセージを処理するための様々なログ出力があります。これらのログ出力はすべて、親ログ出力であるoracle.osbにあります。oracle.osbログ出力を構成することはできません。これは、親ログ出力oracleから構成を継承します。Fusion Middleware Controlで、またはWLSTコマンドを使用して、これらのログ出力を表示および構成できます。

Service Busのログ出力の詳細リストは、「Oracle Service Busのログ出力」を参照してください。

注意:

Service Busでは、後方互換性のためにのみ、親ログ出力oracle.osbにデバッグ・ログ出力が提供されています。

7.2 Oracle Service Bus用のDiagnostic Loggingの構成

Service Busのログ出力を構成するための最も簡単な方法は、Fusion Middleware ControlまたはWLSTコマンドを使用することです。

- Fusion Middleware ControlでのService Busのロギングについて

- Service Busのログ・レベルとログ・ファイルの構成

- WLSTコマンドを使用したOracle Service Busのロギングの構成

- Fusion Middleware Controlでのデバッグのためのロギング・レベルの設定

- Oracle Service Busのエラー・メッセージ接頭辞の設定

- オフライン・ロギングのためのOracle Service Busの構成

7.2.1 Fusion Middleware ControlでのService Busのロギングについて

Fusion Middleware Controlの「ログ構成」ページの「ログ・レベル」タブには次の情報が表示されます。

- 情報を表示するログ出力のタイプを選択するための「表示」リスト。実行時または永続状態のログ出力から選択します。

- ログ出力名、ログ・ファイルに書き込む情報の量とタイプを設定するOracle Diagnostic Logging (ODL)レベル、ログ・ファイルおよびログ・レベルの状態が表示される表。

「ログ・ファイル」タブには、ログ・ハンドラ、ログ・ファイルのパスおよび名前、ログ・メッセージの書式、使用するローテーション・ポリシー、およびログ・ファイル構成クラスに基づくその他のパラメータが表示されます。

7.2.2 Service Busのログ・レベルとログ・ファイルの構成

Fusion Middleware Controlを使用して、Service Busのログ・レベルとログ・ファイルを構成します。

ログ・レベルとログ・ファイルを構成するには:

1. 次のいずれかを行います。

- Service Busメニューから、「ログ」→「ログ構成」を選択します。

- ターゲットのナビゲータのSOAフォルダで、「service-bus」を右クリックし、「ログ」をポイントして、「ログ構成」を選択します。

「ログ構成」ページが表示されます。

2. 「ログ・レベル」タブをクリックします。

3. 「ログ出力名」列で、「ルート・ログ出力」→「oracle」→「oracle.osb」を開きます。

4. 編集するService Busログ出力の「Oracle Diagnostic Loggingレベル(Javaレベル)」列で、ログ・ファイルに書き込む情報のレベルを選択します。

ODLログ・レベルの詳細は、Oracle Fusion Middlewareの管理のログ・ファイルに書き込まれる情報レベルの設定に関する項を参照してください。

5. Service Busの再起動後も変更が保持されるように、更新したログ・レベルを維持するには、「コンポーネントの再起動後もログ・レベル状態を維持」を選択します。

6. ログ・レベルの変更が終了したら、「適用」をクリックします。

7. ログ・ファイル構成を作成および編集するには、「ログ・ファイル」列でログ・ファイルの名前をクリックするか、「ログ・ファイル」タブをクリックします。

「ログ・ファイル」ページが表示されます。ここで行う変更は、Service Bus固有のものではありません。ログ・ファイル構成の編集の詳細は、Oracle Fusion Middlewareの管理のログ・ファイルの設定の構成に関する項を参照してください。

7.2.3 WLSTコマンドを使用したOracle Service Busのロギングの構成

WLSTには、単一のサーバーのロギング構成を更新するためのコマンドがあります。これらのコマンドとその使用方法の詳細は、Oracle Fusion Middlewareの管理のログ・ファイルの設定の構成に関する項を参照してください。WLSTロギング・コマンドのリファレンスは、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のカスタムWLSTコマンドのロギングに関する項に記載されています。

7.2.4 Fusion Middleware Controlでのデバッグのためのロギング・レベルの設定

デバッグは、通常のService Busの操作では無効にしておく必要がありますが、ソリューションの開発および検証時に特定のモジュールのデバッグ・ロギングを指定すると役に立つ場合があります。たとえば、アラートの開発中にアラート・エンジンの動作を確認する場合、アラートのデバッグ・フラグを有効にすることが考えられます。

Service Busサービスのデバッグの詳細は、『Oracle Service Busでのサービスの開発』のOracle Service Busデバッガの使用に関する項を参照してください。

デバッグのロギング・レベルを設定するには:

1. ターゲット・ナビゲータで、「SOA」を開き、「service-bus」を右クリックして、「ログ」をポイントし、「ログ構成」を選択します。

2. 「ログ構成」ページで、「ログ・レベル」タブを選択します(このタブが表示されていない場合)。

3. すべてのService Busモジュールをデバッグするには、「ルート・ログ出力」→「oracle」を開き、「Oracle Diagnostic Loggingレベル(Javaレベル)」列でoracle.osbログ出力をTRACE:32 FINESTに設定します。

4. 特定のService Busモジュールのみをデバッグするには、「oracle.osb」を開き、Service Busのログ出力を次のレベルのいずれかに設定します。

- TRACE:1 (詳細)

- TRACE:16 (より詳細)

- TRACE:32 (最も詳細) - 最も詳細なレベル(トラブルシューティングでのみ使用することをお薦めします)

5. 「適用」をクリックし、確認ダイアログで「閉じる」をクリックします。

変更はただちに有効になり、サーバーの再起動は必要ありません。使用可能なログ出力の詳細は、「ログ出力」を参照してください。

6. トラブルシューティングを行うときは、ログ・レベルを元の値に戻します。

7.2.5 Oracle Service Busのエラー・メッセージ接頭辞の設定

Service Busは、"OSB"という接頭辞の後にダッシュと6桁の数字が付いたメッセージID (例: OSB-381202)を生成します。Service Busの以前のバージョンでは、ログ・メッセージの接頭辞は"BEA"でした。ログ・メッセージおよびSOAPフォルトでBEAという文字列を検出することを想定しているサードパーティのツールを使用してログ・ファイルまたはサービスをモニターする場合、それらのツールが予想どおりに作動しないことがあります。

Service Busメッセージで引き続き"BEA"という接頭辞を使用するには、実行時に次のシステム・プロパティを設定します。

-Dcom.oracle.sb.MsgIdPrefixCompatibilityModeEnabled=true

WebLogic Server管理コンソールの、Service Busサーバーの「構成」→「サーバーの起動」ページで、このプロパティを設定できます。

7.2.6 オフライン・ロギングのためのOracle Service Busの構成

アプリケーション・サーバーで実行するのではなく、Service Busをオフラインで処理している場合、ロギング環境は自動的には構成されません。オフラインのロギングを構成するには、logging.xmlファイルを手動で構成し、次の2つのシステム・プロパティを設定する必要があります。

-Djava.util.logging.config.class=oracle.core.ojdl.logging.LoggingConfiguration
-Doracle.core.ojdl.logging.config.file=logging.xml

ここで、logging.xmlは、オフラインのロギング用に構成したlogging.xmlファイルのパスと名前です。

7.3 Oracle Service Busの診断ログ・ファイルの表示

Fusion Middleware ControlまたはWLSTのdisplayLogsコマンドを使用して、ログ・ファイルを表示できます。

ログ・ファイルをローカル・クライアントにダウンロードし、テキスト・エディタやファイル表示ユーティリティなどの別のツールを使用してそれらを表示できます。

7.3.1 Fusion Middleware ControlでのOracle Service Busのログ・ファイルの表示

Fusion Middleware Controlでのサーバーおよびドメインのログ・ファイルの表示の詳細は、Oracle Fusion Middlewareの管理のログ・ファイルの表示と検索に関する項を参照してください。

Service Busのログ・メッセージを表示するには:

1. 次のいずれかを行います。

- Service Busメニューから、「ログ」→「ログ・メッセージの表示」を選択します。

- ターゲットのナビゲータのSOAフォルダで、「service-bus」を右クリックし、「ログ」をポイントして、「ログ・メッセージの表示」を選択します。

「ログ・メッセージ」ページが表示されます。

2. 「検索」セクションで、表示するログ・メッセージを日付、メッセージ・タイプまたはメッセージ・コンテンツでフィルタし、「検索」をクリックします。

基準に一致するログ・メッセージのリストが表に表示されます。

このページの検索基準の詳細は、このページに関するオンライン・ヘルプおよびOracle Fusion Middlewareの管理のログ・ファイルの検索に関する項を参照してください。

3. 表内のメッセージを選択すると、ページの下部のパネルに詳細が表示されます。

4. 次のいずれかの操作を実行します。

- ECID、メッセージ・タイプ、ターゲットなどのメッセージ属性別にメッセージをグループ化するには、「表示」フィールドで属性の組合せを選択します。

- 処理された時間別にメッセージをグループ化するには、「関連メッセージの表示」をクリックし、「時間別」を選択します。

- ECID別にメッセージをグループ化するには、「関連メッセージの表示」をクリックし、「ECIDごと」を選択します。

- メッセージをファイルにエクスポートするには、「メッセージをファイルにエクスポート」をクリックし、ファイルのタイプ(テキスト、XMLまたはカンマ区切り)を選択します。

- メッセージのリフレッシュ間隔を変更するには、リフレッシュ・フィールドでクリックし、30秒のリフレッシュ間隔、1分のリフレッシュ間隔または手動リフレッシュを選択します。

7.3.2 ログ・メッセージ・ビューのカスタマイズ

ログ・ファイル・エントリの上の「表示」メニューでは、どの列をどの順番で表示するかを選択できます。表示されるメッセージのソート方法を定義することもできます。

ログ・メッセージの表示をカスタマイズするには:

1. 各メッセージで表示するその他の列を選択するには、次の手順を実行します。

a. 「表示」メニューをクリックし、「列」をポイントして、表示する列の名前を選択します。

b. 表示する各列について、この手順を繰り返します。

2. 表から列を削除するには、次の手順を実行します。

a. 「表示」メニューをクリックし、「列」をポイントして、削除する列の名前を選択解除します。

b. 削除する各列について、この手順を繰り返します。

3. リスト内でメッセージをどのようにソートするかを定義するには、次の手順を実行します。

a. 「表示」メニューをクリックし、「ソート」をポイントして、「詳細」を選択します。
「拡張ソート」ダイアログが表示され、最大3つの列でソートすることができます。

b. ソートする最初の列、および昇順でソートするか降順でソートするかを選択します。

c. ソートするその他の列についてこの手順を繰り返し、「OK」をクリックします。

4. 別の順序で列を表示するには、次の手順を実行します。

a. 「表示」メニューをクリックし、「並替え」を選択します。
「列の並替え」ダイアログが表示されます。

b. 並べ替える列を選択し、右の矢印ボタンを使用してリスト内で上または下に移動します。

c. 移動するその他の列についてこの手順を繰り返し、「OK」をクリックします。

7.3.3 WLSTコマンドを使用したOracle Service Busのログ・ファイルの表示

WLSTには、ログ・メッセージを検索および表示するためのコマンドがあります。これらのコマンドおよび、コマンドを使用してログ・ファイルを表示する方法の詳細は、Oracle Fusion Middlewareの管理のWLSTを使用したログ・ファイルおよびそのメッセージの表示に関する項を参照してください。WLSTロギング・コマンドのリファレンスについては、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のカスタムWLSTコマンドのロギングに関する項を参照してください。

7.4 Oracle Service Busのログ出力

ここでは、Service Busで提供されている標準のログ出力と、デバッグ・ログ出力およびそれに対応する前のバージョンのデバッグ・ログ出力のリストを示します。

この項の内容は次のとおりです。

- Service Busの標準のログ出力

- 11gおよび12cのService Busのデバッグ・ログ出力

7.4.1 Service Busの標準のログ出力

Service Busで提供されている標準のログ出力を次に示します。

- oracle.osb.configfwk

- oracle.osb.mgmt.view.resequencer.ServiceNamesLovModel

- oracle.osb.fmwemplugin.core

- oracle.osb.mgmt.view.resource.ResourceMetricsDetailsViewHandler

- oracle.osb.mgmt.base.OSBContext

- oracle.osb.mgmt.view.util.AdfUtil

- oracle.osb.mgmt.model.OSBModel

- oracle.osb.owsm.resource.owsm

- oracle.osb.mgmt.model.monitor.alerts.AlertsHistoryModel

- oracle.osb.resources.core.resourcemanagement

- oracle.osb.mgmt.model.monitor.metrics.ServiceMetricsHelper

- oracle.osb.security.api.security

- oracle.osb.mgmt.model.monitor.metrics.ServiceMetricsModel

- oracle.osb.services.core.initialization

- oracle.osb.mgmt.model.operations.global.GlobalOperationalSettingsModel

- oracle.osb.statistics.alsbstatistics

- oracle.osb.mgmt.model.resequencer.ResequencerModel

- oracle.osb.transports.dsp.dsptransportmessages

- oracle.osb.mgmt.model.resource.ResourceMetricsDetailsModel

- oracle.osb.transports.jca

- oracle.osb.mgmt.model.resource.ResourceOperationalSettingsModel

- oracle.osb.transports.mq.mqtransport

- oracle.osb.mgmt.model.resource.Service

- oracle.osb.uddi.services.uddiconfiguration

- oracle.osb.mgmt.model.resource.businessService.BusinessService

- oracle.soa.resequencer.OSB

- oracle.osb.mgmt.model.resource.pipeline.Pipeline

- oracle.soa.resequencer.OSB.container

- oracle.osb.mgmt.model.resource.proxyService.ProxyService

- oracle.soa.resequencer.OSB.dao.toplink.service

- oracle.osb.mgmt.model.resource.splitJoin.SplitJoin

- oracle.soa.resequencer.OSB.dao.toplink.sessi

- oracle.osb.mgmt.model.util.DateUtil

- oracle.soa.resequencer.OSB.infra.deployment

- oracle.osb.mgmt.model.util.JMXUtil

- oracle.soa.resequencer.OSB.management

- oracle.osb.mgmt.view.common.query.SavedSearchDefinition

- oracle.soa.resequencer.OSB.service

- oracle.osb.mgmt.view.monitor.alerts.AlertsHistoryViewHandler

- oracle.soa.resequencer.OSB.service.event

- oracle.osb.mgmt.view.monitor.metrics.ServiceMetricsViewHandler

- oracle.soa.resequencer.OSB.threadpool

- oracle.osb.mgmt.view.operations.global.GlobalOperationalSettingsViewHandler

- oracle.soa.resequencer.OSB.utils

- oracle.osb.mgmt.view.resequencer.ResequencerViewHandler

7.4.2 11gおよび12cのService Busのデバッグ・ログ出力

次の表は、以前にalsbdebug.xmlおよびconfigfwkdebug.xmlで構成されたデバッグ・ログ出力と、新しいODLデバッグ・ログ出力名とのマッピングを示しています。

注意:

次の表にリストされているデバッグ・ログ出力は、後方互換性のためにのみ含まれているもので、以降のリリースでは非推奨になる予定です。

表7-1 11gおよび12cのService Busのデバッグ・ログ出力

12cのログ・ハンドラ

11gのログ・ハンドラ

説明

oracle.osb.debug.alert-manager

alsb-alert-manager-debug

アラートの評価を出力します。

oracle.osb.debug.bpel

alsb-bpel-debug

oracle.osb.debug.codec

alsb-codec-debug

oracle.osb.debug.configfwk.component

config-fwk-component-debug

作成、更新、削除およびインポート操作に関する低レベルのデバッグ情報をログに記録します。

oracle.osb.debug.configfwk.core

config-fwk-debug

Service Busの構成に関する一般的な情報をログに記録します。

oracle.osb.debug.configfwk.deployment

config-fwk-deployment-debug

セッションの作成、アクティブ化およびクラスタ内の構成の配布に関するデバッグ情報をログに記録します。

oracle.osb.debug.configfwk.persistence

config-fwk-persistence-debug

oracle.osb.debug.configfwk.security

config-fwk-security-debug

インポートおよびエクスポート時の暗号化と復号化に関するデバッグ情報をログに記録します。

oracle.osb.debug.configfwk.transaction

config-fwk-transaction-debug

メモリー内のデータ構造とファイルの変更に関する低レベルのデバッグ情報をログに記録します。このデバッグ・フラグにより、サーバーの起動時の回復ログも生成されます。

oracle.osb.debug.configfwk.validation

config-fwk-validation-debug

oracle.osb.debug.console

alsb-console-debug

oracle.osb.debug.custom-resource

alsb-custom-resource-debug

カスタム・リソースに関する情報をログに記録します。

oracle.osb.debug.debugger

alsb-debugger-debug

oracle.osb.debug.flow-deployment

alsb-flow-deployment-debug

oracle.osb.debug.flow-resource

alsb-flow-resource-debug

分割-結合内で生成されるエラーに関する情報をログに記録します。

oracle.osb.debug.flow-transports

alsb-flow-transport-debug

oracle.osb.debug.jca-framework-adapter

alsb-jca-framework-adapter-debug

oracle.osb.debug.jms-reporting-provider

alsb-jms-reporting-provider-debug

即時利用可能なJMSベースのレポート・プロバイダに関する情報をログに記録します。

oracle.osb.debug.management

alsb-management-debug

コンソールでのユーザーとグループの管理に関する情報をログに記録します。

oracle.osb.debug.management-dashboard

alsb-management-dashboard-debug

oracle.osb.debug.message-tracing

alsb-message-tracing-debug

Logs message tracing information.

(12cにはありません)

alsb-monitoring-aggregator-debug

使用されなくなりました。

oracle.osb.debug.monitoring

alsb-monitoring-debug

統計システムに関する情報をログに記録します。

oracle.osb.debug.mqconnection

alsb-mqconnection-debug

MQ接続リソースに関する情報をログに記録します。

oracle.osb.debug.pipeline

alsb-pipeline-debug

パイプライン内で生成されるエラーに関する情報をログに記録します。

oracle.osb.debug.proxy-server-manager

alsb-proxy-server-manager-debug

プロキシ・サーバーに関する情報をログに記録します。

oracle.osb.debug.resequencer

メッセージのリシーケンスに関する情報をログに記録します。

oracle.osb.debug.result-caching

alsb-result-caching-debug

ビジネス・サービスの結果キャッシュに関する情報をログに記録します。

oracle.osb.debug.security-module

alsb-security-module-debug

oracle.osb.debug.security-wss

alsb-security-wss-debug

oracle.osb.debug.security-wss-owsm-debug

alsb-security-wss-owsm-agent-debug

oracle.osb.debug,security-wss-owsm

alsb-security-wss-owsm-debug

(12cにはありません)

alsb-security-wss-owsm-pm-debug

使用されなくなりました。

oracle.osb.debug.service-account-manager

alsb-service-account-manager-debug

サービス・アカウントに関する情報をログに記録します。

oracle.osb.debug.service-binding-layer

alsb-service-binding-layer-debug

oracle.osb.debug.service-provider-manager

alsb-service-provider-manager-debug

サービス・プロバイダに関する情報をログに記録します。

oracle.osb.debug.service-repository

alsb-service-repository-debug

サービス関連の様々な構成操作に関する情報をログに記録します。

oracle.osb.debug.service-security-manager

alsb-service-security-manager-debug

アクセス制御に関する情報をログに記録します。

(12cにはありません)

alsb-service-validation-debug

使用されなくなりました。

oracle.osb.debug.sources

alsb-sources-debug

oracle.osb.debug.stages-transform-runtime

alsb-stages-transform-runtime-debug

トランザクション関連のアクションに関する情報をログに記録します。

oracle.osb.debug.test-console

alsb-test-console-debug

テスト・コンソール・アクティビティに関する情報をログに記録します。

oracle.osb.debug.throttling

alsb-throttling-debug

スロットル機能に関する情報をログに記録します。

oracle.osb.debug.transports

alsb-transports-debug

トランスポート・ヘッダーなど、トランスポート関連のデバッグ情報をログに記録します。これは、メッセージ単位で出力されます。

oracle.osb.debug.uddi

alsb-uddi-debug

UDDIレジストリに関する情報をログに記録します。

oracle.osb.debug.wadl-repository

なし

WADL関連の構成操作に関する情報をログに記録します。

oracle.osb.debug.ws-policy

alsb-wspolicy-repository-debug

WSポリシーに関する情報をログに記録します。

oracle.osb.debug.wsdl-repository

alsb-wsdl-repository-debug

WSDL関連の構成操作に関する情報をログに記録します。

7.5 11gからアップグレードした後のログ構成

Oracle Service Bus 11gからアップグレードすると、アップグレード・プロセスによってalsbdebug.xmlファイルが削除されます。alsbdebug.xmlを使用して、デバッグ・ロギングを有効にするようにサーバーが構成されていた場合、デバッグ・ロギングを再度有効にするように再構成する必要があります。

表7-1に、使用する新しいログ出力が示されています。

さらに、Service Busでは、ログ・エントリをサーバー・ログ・ファイルではなく診断ログ・ファイルに書き込むようになったため、バージョン11gでログ・ファイルの検査に使用していたカスタム・ツールがある場合はそのツールを更新する必要があります。古いファイル名はserver_name.log、新しいファイル名はserver_name-diagnostic.logです。

7.5.1 ロギング・レベル

Service Busを11gからアップグレードすると、既存のService Busログ・メッセージのロギング・レベルが自動的に更新されます。次の表で、以前のログ・レベルが新しいログ・レベルにどのようにマップされるかについて説明します。

表7-2 11gログ・レベルの12cへのマッピング

WLSの重大度

ODLメッセージ・タイプ: メッセージ・レベル

整数値

trace

TRACE:32

295

debug

TRACE:1

500 (Level.FINE)

info

NOTIFICATION:1

800 (Level.INFO)

notice

WARNING:7

880

warning

WARNING:1

900 (Level.WARNING)

error

ERROR:1

1000 (Level.SEVERE)

critical

INCIDENT_ERROR:24

1030

alert

INCIDENT_ERROR:14

1060

emergency

INCIDENT_ERROR:4

1100

7.5.2 ログ・メッセージの書式

ODLでのロギングは、ログ・メッセージが前のバージョンとは異なる方法で書式設定されることを意味します。新しい書式は次のとおりです。

[timestamp] [component id] [messagetype:level] [message-id] [module id]
([field-name: field-value])* message-text [supplemental-detail

表7-3に、前のバージョンのService Busログ・メッセージが新しいODL書式にどのようにマップされるかを示します。ログ・メッセージの書式の詳細は、Oracle Fusion Middlewareの管理のODLメッセージおよびODLログ・ファイルの理解に関する項を参照してください。

表7-3 ODLへのメッセージ書式のマッピング

WebLogic Serverの書式

ODLの書式

タイムスタンプ

タイムスタンプ

重大度

メッセージ・タイプ:レベル

サブシステム

なし

ホスト名

Field-name:field-value (ホストID)

サーバー名

コンポーネントID

スレッド

Field-name:field-value (スレッドID)

ユーザーID

Field-name:field-value (ユーザーID)

トランザクションID

なし

診断コンテキストID

Field-name:field-value (実行コンテキストID)

生の時間値

なし

メッセージID

メッセージID

メッセージ・テキスト

メッセージ・テキスト

第III部 Oracle Service Busランタイムの管理

この部では、操作設定の更新、Service Bus構成のインポートとエクスポート、環境変数のカスタマイズ、セキュリティの定義など、実行中のService Busサービスの管理方法について説明します。

この部は、次の章で構成されています。

- 操作設定とグローバル設定の構成

- Oracle Service Bus環境のカスタマイズ

- Oracle Service Busリソースのインポートとエクスポート

- Oracle Service Busのアクセス・セキュリティの定義

8 操作設定とグローバル設定の構成

この章では、モニター、アラート、メッセージ・トレース、実行トレース、アラート、レポート、ロギング、ビジネス・サービスのパフォーマンス・チューニングなど、実行時のOracle Service Busサービスの操作を制御する設定について説明します。 操作設定には、サービス・レベルで設定されるものや、グローバル・レベルで設定されるものがあります。一部の操作設定は、有効にするためにサービス・レベルとグローバル・レベルの両方で設定される必要があります。

この章の内容は次のとおりです。

- 操作設定について

- 操作設定の表示と構成

- 操作設定の一括更新

- リソースのインポート時の操作設定の保持

8.1 操作設定について

Fusion Middleware Controlで操作設定を構成することによって、個別のサービスの状態を制御したり、すべてのサービスをグローバルに制御できます。ドメイン内の各サービスおよびすべてのサービスの状態を制御することに加えて、操作設定により、モニター、アラート、レポートおよびロギング機能を有効化および無効化できます。

オフラインのエンドポイントURIの処理方法を指定したり、メッセージ・フローを制限したり、結果キャッシュを有効にしたりすることで、ビジネス・サービスを管理することもできます。グローバルな操作設定は、サービス・レベルの設定をオーバーライドします。

8.1.1 使用可能な操作設定

操作設定により、モニター、アラート、レポート、ロギング、メッセージ・トレース、ビジネス・サービスの結果キャッシュなどを構成できます。すべてのサービスの操作設定をサービス・レベルおよびグローバル・レベルで指定し、グローバル設定を使用してモニター、SLAアラート、パイプライン・メッセージ・レポートおよびパイプライン・メッセージ・ロギングをオンにしたりオフにしたりすることができます。次の項で、使用可能な設定について説明します。

8.1.1.1 状態

この操作設定は、サービスを有効または無効にします。デフォルトでは、すべてのサービスの状態は有効です。

8.1.1.2 モニター

この操作設定は、サービスのモニターを有効または無効にします。パイプラインおよび分割-結合の場合、モニターを実行するレベルも構成できます。ロギングやアラートなど、他の特定の操作設定は、モニターの有効化に依存しています。デフォルトでは、すべてのサービスでモニターは無効です。

パイプラインの場合、モニターは次のレベルで有効にすることができます。

- アクション(A)

- パイプライン(P)

- サービス(S)

分割-結合の場合、モニターは次のレベルで有効にすることができます。

- アクティビティ(A)

- ブランチ(B)

- サービス(S)

パイプラインまたは分割-結合の「プロパティ」ページでレベルを構成します。レベル・インジケータがService BusおよびService Busプロジェクトの「操作」ページに表示されます。

8.1.1.3 集約間隔

この操作設定は、サービスの集約間隔を時間および分単位で定義します。集約間隔とは、統計データが収集され表示されるまでの時間です。デフォルトの間隔は10分です。

8.1.1.4 サービス・レベル・アグリーメントのアラート

この操作設定は、サービスに対する、特定の重大度レベル以上のサービス・レベル・アグリーメント(SLA)のアラートを有効にします。サービスのSLAアラートを無効にする場合にも使用します。デフォルトでは、すべてのサービスでSLAアラートが有効です。

SLAアラートは次のレベルで有効にすることができます。サービスの「プロパティ」ページでアラート・レベルを構成します。レベル・インジケータがService BusおよびService Busプロジェクトの「操作」ページに表示されます。

- 通常(N)

- 警告(W)

- 軽度(Mn)

- 重度(Mj)

- クリティカル(C)

- 致命的(F)

8.1.1.5 パイプライン・アラート

この操作設定は、特定の重大度レベル以上のパイプラインのアラートを有効にします。パイプライン・アラートを無効にする場合にも使用します。デフォルトでは、パイプライン・アラートは「通常」以上のレベルで有効化されています。パイプライン・アラートのモニターの詳細は、「Oracle Service Busのアラートのモニター」を参照してください。アラートの構成の詳細は、『Oracle Service Busでのサービスの開発』のレポート・アクションに関する項およびアラート・アクションの追加に関する項を参照してください。

パイプライン・アラートは次のレベルで有効にすることができます。パイプラインの「プロパティ」ページでレベルを構成します。レベル・インジケータがService BusおよびService Busプロジェクトの「操作」ページに表示されます。

- 通常(N)

- 警告(W)

- 軽度(Mn)

- 重度(Mj)

- クリティカル(C)

- 致命的(F)

8.1.1.6 レポート

この操作設定は、パイプラインのメッセージ・レポートを有効または無効にします。Service Busでは、メッセージ・データをメッセージ本文および他のメッセージ変数から取得できます。このデータは、1つまたは複数のレポート・プロバイダに配信されます。レポート・データには、SLA違反に関する情報も含まれます。デフォルトでは、レポートは「通常」以上のレベルで有効化されています。

8.1.1.7 ロギング

この操作設定は、特定の重大度レベル以上のパイプラインおよび分割-結合のロギングを有効にします。パイプラインまたは分割-結合内のログ・アクションの重大度レベルは、そのパイプラインまたは分割-結合の操作設定の「ロギング」重大度レベルに一致する必要があります。デフォルトでは、ロギングは「デバッグ」以上のレベルで有効化されています。

ロギングは次のレベルで有効にすることができます。パイプラインまたは分割-結合の「プロパティ」ページでレベルを構成します。レベル・インジケータがService BusおよびService Busプロジェクトの「操作」ページに表示されます。

- デバッグ(D)

- 情報(I)

- 警告(W)

- エラー(E)

ログ・ファイルまたは標準出力(サーバー・コンソール)にログ・データを表示するには、Oracle WebLogic Serverのロギングを特定の重大度レベルに設定する必要があります。詳細は、「サービスのメッセージ・トレースの構成」を参照してください。

8.1.1.8 実行トレース

この操作設定は、パイプラインおよび分割-結合の実行トレースを有効または無効にします。Service Busでは、サーバーをシャットダウンすることなく、メッセージをトレースできます。これにより、メッセージ・フローのトラブルシューティングと診断が簡単になります。デフォルトでは、実行トレースは無効にされています。実行トレースを有効にすると、パイプライン・コンテキストやメッセージ・コンテキストから選別された各種詳細がログに記録されます。これらの詳細には、ステージ名、パイプライン名またはルート・ノード名、現在のメッセージ・コンテキストなどが含まれます。

ログ・ファイルまたは標準出力(サーバー・コンソール)にトレースを表示するには、Oracle WebLogic Serverのロギングを「情報」重大度レベルに設定する必要があります。実行トレースの詳細は、「実行トレースを使用した問題の診断」を参照してください。

8.1.1.9 メッセージ・トレース

この操作設定は、特定の詳細レベル以上のサービスのメッセージ・トレースを有効または無効にします。ペイロード制限(キロ・バイト単位)および デフォルトのエンコーディングも設定できます。デフォルトでは、メッセージ・トレースは無効です。

ログ・ファイルまたは標準出力(サーバー・コンソール)にトレースを表示するには、Oracle WebLogic Serverのロギングを「情報」重大度レベルに設定する必要があります。メッセージ・トレースの構成手順は、「サービスのメッセージ・トレースの構成」を参照してください。さらに、ペイロードのデフォルト・エンコーディングを指定する必要があります。たとえば、ペイロードのエンコードがShift_JISの場合、「デフォルト・エンコーディング」フィールドでエンコードを指定して、ログ・ファイル内でバイトがUTF8に変換されるようにします。

8.1.1.10 オフラインのエンドポイントURI

この操作設定は、ビジネス・サービスの応答しないエンドポイントを有効または無効にします。このオプションを選択すると、ビジネス・サービスは、実行時に応答しないエンドポイントURIを削除し(オフラインにする)、再試行と以降のリクエストの処理には応答するURIのみが使用されます。

オフラインのエンドポイントURIを再試行するまでの時間間隔を指定できます。ビジネス・サービスについてのみ、オフラインのURIを有効または無効にできます。デフォルトでは、オフラインのエンドポイントURIは無効です。

オフラインのエンドポイントURIの詳細は、「ビジネス・サービスのエンドポイントURIのモニターおよび管理」を参照してください。エンドポイントURIをオフラインとマークする手順は、「応答しないエンドポイントURIをオフラインにするService Busの構成」を参照してください。

8.1.1.11 スロットル設定

サービスのスロットルを有効にし、同時実行性、スロットル・キュー、およびキューに入れられたメッセージの存続時間(TTL)を構成することにより、ビジネス・サービスを通過するメッセージのフローを制限できます。スロットルのプロパティには次のものがあります。

- スロットルの状態: この操作設定は、ビジネス・サービスのスロットルを有効または無効にします。デフォルトでは、スロットルは無効です。

- 最大同時実行性: この操作設定は、ビジネス・サービスによって同時に処理可能なメッセージの数を制限します。デフォルトのメッセージ数は0 (ゼロ)です。これは制限がないことを意味します。

- スロットル・キュー: この操作設定は、スロットル・キュー内のメッセージの最大数を制限します。デフォルトのメッセージ数は0 (ゼロ)です。これは制限がないことを意味します。

- メッセージの有効期限: メッセージをスロットル・キュー内に置くことができる最大時間間隔(ミリ秒単位)。デフォルトのメッセージ数は0 (ゼロ)です。これは制限がないことを意味します。

ビジネス・サービスのスロットルの詳細は、「メッセージ・スロットル用にビジネス・サービスを構成する方法」を参照してください。

8.1.1.12 結果キャッシュの状態

この操作設定は、ビジネス・サービスの結果キャッシュを有効または無効にします。デフォルトでは、結果キャッシュはグローバルに有効です。結果キャッシュの詳細は、『Oracle Service Busでのサービスの開発』のビジネス・サービスの結果のキャッシュによるパフォーマンスの改善に関する項を参照してください。

8.1.1.13 自動サービス移行

自動サービス移行(ASM)は、WebLogicサービス移行フレームワークを活用して、障害またはメンテナンスのために停止しているサーバーからクラスタ内の他の使用可能なサーバーにサービスを移行します。

注意:

このSOA Suite機能は、Oracle Integration Continuous Availabilityの一部です。Oracle SOA Suite for Middlewareオプションの詳細は、『Oracle Fusion Middlewareライセンス情報ユーザー・マニュアル』のOracle SOA Suite for Middlewareオプションに関する項を参照してください。

Service Busでは、次のASMがサポートされます。

- 集約機能およびSLAアラート・マネージャなどのシングルトン・サービス

- ファイル、FTP、SFTPおよび電子メール・ポーラー・トランスポート。これらのトランスポートは、クラスタ内の1つの管理対象サーバーでのみ実行されるクラスタ・シングルトン・サービスです。

注意:

ASMは、クラスタ・ドメインにのみ使用できます。単一ノード・ドメインに影響はありません。

ASMを有効にする前提条件は、「自動サービス移行を有効にする前提条件」を参照してください。ASMを有効にするには、「グローバル・レベルの操作設定の構成」を参照してください。

ASMオプションを有効にすると、Service Busは最初に優先管理対象サーバー、次にクラスタをターゲット指定した集約サービスのアプリケーション・スコープのシングルトン・サービスおよび各ポーラーのプロキシ・サービスをデプロイします。集約サービスとポーラーのプロキシ・サービスは、クラスタ内の任意のサーバーへの移行に対して適格です。サービスの移行に対してクラスタ内のサーバーのサブセットはありません。サービスのポーリングは、最初に優先管理対象サーバーで開始されます。優先管理対象サーバーが停止すると、サービスはクラスタ内で利用可能な管理対象サーバーを順次ターゲット指定します。優先管理対象サーバーが中間に存在しても、ポーリングがそのサーバーで開始されない可能性があります。メッセージを処理する前にASMを有効にした後にすべてのサーバーを再起動する必要があります。

ヒント:

ASMを有効にする前にすべての管理対象サーバーが実行されていないことを確認することをお薦めします。これにより、特にポーラーのトランスポートのメッセージ処理の曖昧な状況が回避されます。

ASMオプションを選択して管理対象サーバーが再起動した後、Service Bus Consoleのポーラーのプロキシ・サービスでこれらのアクションを実行すると、次の結果になります。

- 作成: 新しいアプリケーション・スコープのシングルトン・サービスが新しいサービス用に作成されます。

- 更新/名前変更/移動: 新しいアプリケーション・スコープのシングルトン・サービスがそのサービス用に作成され、古いシングルトンがアンデプロイされてファイルが削除されます。

- 削除: そのサービスのシングルトンがアンデプロイされてファイルが削除されます。

- クローン: 新しいアプリケーション・スコープのシングルトン・サービスがクローンされたサービスに作成され、元のサービスのシングルトンは引き続き存在します。

- 取消し: 最新の変更を元に戻します。

ASMオプションを無効にすると(前に有効にした後)、Service Busはポーラー・トランスポート用に作成されたシングルトン・サービスをアンデプロイし、関連付けられているすべてのファイルを削除します。これらの変更を有効にする前にASMを無効にした後にすべてのサーバーを再起動する必要があります。

ASMは、EJB、JEJBおよびHTTPサービスなどの非同期サービスに影響を与えません。このような場合、クライアントはサービスを使用できない場合に呼出し中に例外を受け取ります。クライアントはリクエストを再送信するか、使用できる場合に再試行オプションを構成する必要があります。

WebLogic Serverサービス移行フレームワークの詳細は、『Oracle WebLogic Serverクラスタの管理』のサービス移行に関する項を参照してください。

8.1.1.13.1 自動サービス移行を有効にする前提条件

Enterprise Managerの自動サービス移行を有効にする前に、サービスの移行基盤を更新し、アラート・ストアを構成してWLDF JDBCベースのストアを使用します。

そのためには、次の前提条件の手順を実行します。

1. 『Oracle WebLogic Serverクラスタの管理』の移行可能サービスのリースに関する項の説明に従って、WebLogic管理コンソールの移行基盤を更新します。本番環境の場合、データベース・リースをお薦めします。

2. アラート・ストアを構成して、ファイルベースのストアのかわりにWLDF JDBCベースのストアを使用します。

注意:

このストアが移行されない場合、SLAおよびパイプライン・アラートは集約機能が新しいサーバーに移行されると表示されません。たとえば、集約機能シングルトンをサーバー1からサーバー2に移行し、その後サーバー1に戻す場合、サーバー1のアラートが再表示されますが、サーバー2のアラートは表示されません。

8.1.1.14 JavaScriptタイムアウト

JavaScriptタイムアウトは、JavaScript実行がエラーで中断した後の時間間隔を定義する値です。デフォルト値は30秒です。

8.1.1.15 リシーケンサ設定

リシーケンサを使用してメッセージを順序どおりに並べるサービスの場合、リシーケンサの設定を構成できます。これには、処理するメッセージのあるグループが見つからないときにロッカー・スレッドが待機する時間の長さや、一度に取得するリシーケンサ・グループの最大数などが含まれます。リシーケンサ・データベースから処理済のメッセージをパージするように、リシーケンサを構成することもできます。

8.1.2 グローバル・レベルおよびサービス・レベルの操作設定

サービス・レベル設定の実行時の動作は、対応するグローバル設定によって異なります。実行時にサービスを完全に有効にするには、グローバル設定とサービス・レベル設定の両方を有効にする必要があります。サービス状態も有効にする必要があります。サービスが実行時に無効でも、モニター構成の設定を変更して保存することができます。たとえば、サービスのモニターが無効でも、集約間隔を変更して保存することができます。このように、設定を編集し、後で有効化することも可能です。

グローバル・レベルでモニターを有効または無効にすると、個別にモニターが有効にされているすべてのサービスでモニターが有効または無効になります。特定のサービスのモニターを有効にしていない場合、システムがそのサービスの統計の収集を開始する前に、そのサービスでモニターを有効にし、集約間隔を設定しておく必要があります。

グローバル・レベルの設定とサービス・レベルの設定を有効または無効にすると、これらの設定を効率的に有効または無効にできます。グローバル・レベルの操作設定は、サービス・レベルの操作設定に優先します。特定のサービスに対して有効にするには、次の設定をグローバル・レベルで有効にする必要があります。

- モニター

- SLAアラート

- パイプライン・アラート

- レポート

- ロギング

- 結果キャッシュ

- 自動サービス移行

- JavaScriptタイムアウト

8.2 操作設定の表示と構成

「操作」ページを使用して、プロキシ・サービス、ビジネス・サービス、パイプラインおよび分割-結合の場所を容易に検索したり、サービス固有の操作設定を指定したりできます。

Service BusまたはService Busプロジェクトの「操作」ページでは、複数のサービスの集約間隔の設定、設定の有効化および無効化を行うことができます。サービスの「プロパティ」ページで、単一のサービスの操作設定を構成できます。Service BusまたはService Busプロジェクトの「操作」ページから操作設定を更新する際、アラートまたはロギングの重大度レベルの指定、メッセージ・トレースのプロパティの構成、またはビジネス・サービスのスロットルまたはエンドポイントURIの構成を行うことはできません。

操作設定を構成する場合は、次のガイドラインに従ってください。

- 一般に、プロパティを有効にするには、それらをサービス・レベルとグローバル・レベルの両方で有効にする必要があります。

- SLAアラートをモニターとは独立して構成することも可能ですが、実行時にはこの2つの設定に関連が生じます。グローバル・モニターを有効にすると、SLAアラートを有効または無効にすることができます。ただし、SLAアラート・ルールの条件は評価するモニター統計によって決まるため、グローバル・モニターを無効にすると、SLAアラートも無効になります。

- すべてのサービスのモニターを無効にすると、それまでにそれらのサービスに対して収集された統計はすべて削除され、統計の削除を元に戻すことはできません。

サービス状態、モニター、SLAアラート、パイプライン・アラートなどの一部の操作設定は、パブリックAPIを使用して有効または無効にすることもできます。詳細は、Oracle Service Bus Java APIリファレンスを参照してください。

8.2.1 グローバル・レベルの操作設定の構成

グローバル・レベルの操作設定(グローバル設定とも呼ばれます)を構成すると、ドメイン内の適用可能なサービスすべてに影響します。ほとんどの設定は、実行時に有効にするためにはサービス・レベルとグローバル・レベルの両方で有効にする必要があります。Service Busホーム・ページの「グローバル設定」タブを使用して、設定をグローバル・レベルで更新します。次の図は「グローバル設定」タブを示しています。

図8-1 「グローバル設定」ページ

操作設定をグローバル・レベルで構成するには:

1. ターゲット・ナビゲータで、「SOA」を開き、「service-bus」を選択します。

Service Busダッシュボードが表示されます。

2. 「グローバル設定」タブをクリックします。

ドメインのService Bus設定が表示されます。

3. 設定を有効にするにはチェック・ボックスを選択し、設定を無効にするにはチェック・ボックスを選択解除します。

各グローバル設定は、表8-1に示します。

4. 適用されていない変更をすべて、保存された設定に戻すには、「元に戻す」をクリックします。

5. 操作設定を構成したら、「適用」をクリックしてランタイムに変更を保存します。

8.2.2 グローバル・レベルの操作設定

次の表では、グローバル・レベルの操作設定について説明します。

表8-1 グローバル・レベルの操作設定

操作設定

使用方法

モニタリング有効

ドメイン内のすべてのサービスのモニターを有効または無効にします。このオプションはまた、グローバル・レベルおよびサービス・レベルでSLAアラートを制御します。

SLAアラート有効

ドメイン内のすべてのサービスのSLAアラートを有効または無効にします。SLAアラートを有効にするには、グローバル・モニターも有効にする必要があります。

パイプライン・アラート有効

ドメイン内のパイプライン・アラートを有効または無効にします。

レポート有効

ドメイン内のすべてのパイプラインのメッセージ・レポートを有効または無効にします。

ロギング

ドメイン内のすべてのパイプラインおよび分割-結合のロギングを有効または無効にします。

結果キャッシュ

ドメイン内のビジネス・サービスの結果キャッシュを有効または無効にします。結果キャッシュを使用するようにビジネス・サービスを構成できますが、結果キャッシュが動作するためには、このグローバル・オプションを有効にする必要があります。結果キャッシュをグローバルに無効にした場合、結果キャッシュで有効にしたすべてのビジネス・サービスのキャッシュされた結果はフラッシュされます。

自動サービス移行有効

自動サービス移行(ASM)を有効にするには、このチェック・ボックスを選択します。選択した場合、Service Busは優先管理対象サーバーとクラスタをターゲット指定したアプリケーション・スコープのシングルトン・サービスをEARとして(各ポーラーのプロキシ・サービスとその集約サービスに1つずつ)作成およびデプロイします。優先管理対象サーバーが停止すると、ポーラーおよび集約サービスはクラスタ内で利用可能な任意のサーバーを順次ターゲット指定します。ASMを有効にした後で、すべてのサーバーを再起動する必要があります。

アプリケーション・スコープのシングルトン・サービスをすべてアンデプロイおよび削除するには、このチェック・ボックスを選択解除して変更を適用します。この変更を有効にするには、すべてのサーバーを再起動する必要があります。

JavaScriptタイムアウト

JavaScript実行がエラーで終了するまでの時間間隔(秒単位)を指定します。デフォルト値は30秒です。

リシーケンサ・ロッカーのスレッドのスリープ

ロッカー・スレッドのスリープ間隔を秒単位で指定します。処理できるメッセージを持つグループをリシーケンサが見つけられないときに、ロッカー・スレッドは指定した期間スリープ状態になります。処理可能なメッセージを持つグループが見つかった場合は、データベース・シークの各繰返しの間でロッカー・スレッドがスリープ状態になることはありません。デフォルト値は10です。

リシーケンサ最大ロック済グループ数

1回のデータベース検索で取得できる、処理対象のリシーケンサ・グループの最大数を指定します。取得されたグループは、処理用のワーカー・スレッドに割り当てられます。

完了メッセージのパージ

リシーケンサ・データベースから処理済のリシーケンス・メッセージをパージするには、このオプションを選択します。

8.2.3 操作設定を構成するサービスの検索

Fusion Middleware Controlには、操作設定を構成するためのオプションが複数ありますが、それらはすべて、構成するサービスの検索を実行することから始まります。

注意:

次の手順では、複数のサービスの操作設定を表示および更新する方法について説明します。サービスの「プロパティ」ページで、単一のサービスの設定を表示および更新することもできます。

操作設定を構成するサービスを検索するには:

1. 次のいずれかを行います。

- ドメイン全体でサービスを検索するには、ターゲット・ナビゲータで「SOA」を開き、「service-bus」を選択します。

- Service Busプロジェクト内のサービスを検索するには、ターゲット・ナビゲータで「SOA」→「service-bus」を開いて、検索するプロジェクトの名前を選択します。

2. 「操作」タブをクリックします。

3. 使用する検索基準を指定して、その設定を変更するサービスを検索します。

次の基準を指定できます。「タイプ」以外はすべてオプションです。

- タイプ: 使用可能なオプションのリストから選択します。これには、すべてのサービス、ビジネス・サービスとプロキシ・サービスの両方、ビジネス・サービス、プロキシ・サービス、パイプライン、分割-結合が含まれます。

- 名前: 検索するサービスの名前を入力します。

- パス: 検索するサービスのパス(プロジェクト名とフォルダ名、ある場合)。Service Busプロジェクトの「操作」タブの場合、パスにはすでに値が入力されています。

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

次に示すように、「操作」表に、基準に一致するサービスのリストが表示されます。これらの設定の詳細は、「使用可能な操作設定」およびFusion Middleware Controlで提供されているオンライン・ヘルプを参照してください。

図8-2 「操作」ページ

5. 操作設定を構成するには、「複数のサービスに対する操作設定の有効化と無効化」に進んでください。

8.2.4 複数のサービスに対する操作設定の有効化と無効化

サービスで構成できる設定は、構成しているのがビジネス・サービスであるか、プロキシ・サービスであるか、パイプラインであるか、分割-結合であるかによって異なります。複数のサービスに対して設定を構成する場合、Service Busの「操作」タブまたは「Service Busプロジェクト」ページで実行できます。これらのページの「操作」リストには、操作設定の有効化および無効化のみが含まれています。スロットルやオフラインのエンドポイントURI管理など、特定の構成が必要な設定は、特定のサービスの「プロパティ」ページでのみ構成できます。

特定の操作設定の構成は、「使用可能な操作設定」およびService Busで提供されているオンライン・ヘルプを参照してください。

複数のサービスに対して操作設定を構成するには:

1. 「操作設定を構成するサービスの検索」の説明に従って、サービスの検索を実行します。

2. 結果リストの任意のサービスについて、チェック・ボックスを選択して対応する操作設定を有効にするか、チェック・ボックスを選択解除して操作設定を無効にします。

3. リスト内のすべてのサービスに対して操作設定を有効または無効にするには、その設定の列ヘッダーにあるチェック・ボックスを選択または選択解除します。

「操作」リスト内の設定および注釈の詳細は、「使用可能な操作設定」およびFusion Middleware Controlで提供されているオンライン・ヘルプを参照してください。

4. 適用されていない変更をすべて、保存された設定に戻すには、「元に戻す」をクリックします。

5. 操作設定を構成したら、「適用」をクリックしてランタイムに変更を保存します。

8.2.5 単一のサービスに対する操作設定の有効化と無効化

Service Busの「操作」ページまたは「Service Busプロジェクト」ページで操作設定を有効または無効にすることに加えて、サービスの「プロパティ」ページでそのサービスの設定を有効または無効にすることもできます。ほとんどのサービスでは、ロギングやモニター・レベルの設定など、より詳細に操作設定を構成することもできます。

特定の操作設定の構成は、「使用可能な操作設定」およびService Busで提供されているオンライン・ヘルプを参照してください。次の図にサービスの「プロパティ」ページを示します。

図8-3 Service Busサービスの「プロパティ」

単一のサービスに対して操作設定を有効または無効にするには:

1. 「操作設定を構成するサービスの検索」の説明に従って、サービスの検索を実行します。

2. 操作表で、構成するサービスをクリックします。

そのサービスの「プロパティ」ページが表示されます。

3. 設定を有効にするには、その設定の「有効」チェック・ボックスを選択します。

4. 設定を無効にするには、その設定の「有効」チェック・ボックスを選択解除します。

5. 適用されていない変更をすべて、保存された設定に戻すには、「元に戻す」をクリックします。

6. 操作設定を構成したら、「適用」をクリックしてランタイムに変更を保存します。

8.2.6 サービスの集約間隔の設定

サービスの「プロパティ」ページを使用して、そのサービスの集約間隔を設定します。集約間隔は、Fusion Middleware Controlに表示される集約統計を計算する間隔です。デフォルトの集約間隔の設定は10分です。

サービスの集約間隔を設定するには:

1. 「操作設定を構成するサービスの検索」の説明に従って、サービスの検索を実行します。

2. 操作表で、構成するサービスをクリックします。

そのサービスの「プロパティ」ページが表示されます。

3. 「モニター」の下の「集約間隔」フィールドで、間隔の時間または分を選択します。

1時間を超える時間を選択した場合、分はデフォルトで常に0が選択されます。ただし、0または1時間を選択した場合には、分単位で間隔を構成することができます。

4. 操作設定を構成したら、「適用」をクリックしてランタイムに変更を保存します。

8.2.7 パイプラインまたは分割-結合のモニター・レベルの構成

パイプラインおよび分割-結合の場合、サービスをモニターするレベルを指定できます。詳細は、「モニター」およびService Busで提供されているオンライン・ヘルプを参照してください。

サービスのモニター・レベルを構成するには:

1. 「操作設定を構成するサービスの検索」の説明に従って、サービスの検索を実行します。

2. 「操作」表で、構成するパイプラインまたは分割-結合をクリックします。

そのサービスの「プロパティ」ページが表示されます。

3. 「モニタリング」の「監視レベル」フィールドで、次の操作を実行します。

- パイプラインの場合は、「サービス」、「パイプライン」または「アクション」を選択してレベルを指定します。

- パイプラインの場合は、「サービス」、「ブランチ」または「アクティビティ」を選択してレベルを指定します。

4. 適用されていない変更をすべて、保存された設定に戻すには、「元に戻す」をクリックします。

5. 操作設定を構成したら、「適用」をクリックしてランタイムに変更を保存します。

8.2.8 サービスのメッセージ・トレースの構成

プロキシ・サービスのメッセージ・トレースを有効にすると、パイプラインとプロキシ・サービス間でやり取りされたメッセージ(インバウンド・リクエストおよびレスポンス、アウトバウンド・リクエストおよびレスポンス・メッセージなど)がログに記録されます。ビジネス・サービスのメッセージ・トレースを有効にすると、パイプラインとビジネス・サービス間でやり取りされたメッセージ(アウトバウンド・リクエストおよびレスポンス・メッセージ)がログに記録されます。

ログに記録されたアウトバウンド・メッセージには、適用可能な場合、再試行回数、エラー・コード、およびエラー・メッセージを含めることもできます。トレース情報がサーバー・ログ・ファイルまたはサーバー・コンソールに記録されるようにするためには、Oracle WebLogic Serverロギングの重大度レベルも構成する必要があります。

Oracle WebLogic Serverのログ・レベルを設定するには:

ログ・ファイルまたは標準出力(サーバー・コンソール)にトレースを表示するには、Oracle WebLogic Serverのロギングを次の重大度に設定する必要があります。

- ログの最低の重大度: 情報

- ログ・ファイル: 情報

- 標準出力: 情報

ログの重大度の設定の詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』のログの重大度の使用に関する項を参照してください。

サービスのメッセージ・トレースを有効にするには:

1. 「操作設定を構成するサービスの検索」の説明に従って、サービスの検索を実行します。

2. 操作表で、構成するサービスをクリックします。

そのサービスの「プロパティ」ページが表示されます。

3. 「メッセージ・トレース」の横の「有効」を選択します。

4. 「トレース詳細レベル」リストで、次の中から詳細のレベルを選択します。

- 簡潔: 日付、時間、サービス・タイプ、サービス名、およびURIを表示します。

- ヘッダー: XMLのメッセージ・メタデータの表現とともに、簡潔な情報を表示します。

- すべて: アタッチメント(ある場合)を含む未加工のペイロードとともに、ヘッダー情報を表示します。

5. 「詳細レベル」リストで「すべて」を選択した場合は、次の手順を実行します。

- 「ペイロード・トレース単位」フィールドで、メッセージ・ペイロードの最大サイズ(キロバイト単位)を指定します。

- 「デフォルト・エンコーディング」フィールドで、ペイロードのロギング用のデフォルト・エンコーディングを指定します。
これは、バイナリ・ペイロードまたはバイナリ添付ファイルがあるSOAPメッセージをロギングする際に役立ちます。デフォルトのエンコーディング値には、Base64またはJavaでサポートされる任意のエンコードを設定できます。

注意:

「デフォルト・エンコーディング」フィールドを空のままにすると、Service Busは、ペイロードにホストのデフォルト・エンコーディングを使用します。デフォルトのエンコーディングは、JVM、基になるオペレーティング・システム(OS)、およびOSレベルのロケール設定の組合せに依存します。

「デフォルト・エンコーディング」フィールドで指定された設定が使用できない場合(たとえば、構成で無効なオプションである場合)、Service Busは、ペイロードにBase64エンコーディングを使用します。

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

8.2.9 サービスのSLAアラート・レベルの構成

サービスのSLAアラートのアラート・レベルを構成できます。詳細は、「サービス・レベル・アグリーメントのアラート」およびService Busで提供されているオンライン・ヘルプを参照してください。

サービスのSLAアラート・レベルを構成するには:

1. 「操作設定を構成するサービスの検索」の説明に従って、サービスの検索を実行します。

2. 操作表で、構成するサービスをクリックします。

そのサービスの「プロパティ」ページが表示されます。

3. 「SLAアラート」の下の「SLA重大度」フィールドで、アラートの生成を開始するレベルを選択します。

4. 適用されていない変更をすべて、保存された設定に戻すには、「元に戻す」をクリックします。

5. 操作設定を構成したら、「適用」をクリックしてランタイムに変更を保存します。

8.2.10 パイプライン・アラート・レベルの構成

サービスのパイプライン・アラートのアラート・レベルを構成できます。詳細は、「パイプライン・アラート」およびService Busで提供されているオンライン・ヘルプを参照してください。

サービスのパイプライン・アラート・レベルを構成するには:

1. 「操作設定を構成するサービスの検索」の説明に従って、サービスの検索を実行します。

2. 操作表で、構成するサービスをクリックします。

そのサービスの「プロパティ」ページが表示されます。

3. 「パイプライン・アラート」の下の「パイプライン重大度」フィールドで、アラートの生成を開始するレベルを選択します。

4. 適用されていない変更をすべて、保存された設定に戻すには、「元に戻す」をクリックします。

5. 操作設定を構成したら、「適用」をクリックしてランタイムに変更を保存します。

8.2.11 サービスのロギング・レベルの構成

パイプラインおよび分割-結合のロギング・レベルを構成できます。詳細は、「ロギング」およびService Busで提供されているオンライン・ヘルプを参照してください。

サービスのロギング・レベルを構成するには:

1. 「Oracle WebLogic Serverのログ・レベルを設定するには:」の説明に従って、Oracle WebLogic Serverのログ・レベルを設定します。

2. 「操作設定を構成するサービスの検索」の説明に従って、サービスの検索を実行します。

3. 操作表で、構成するサービスをクリックします。

そのサービスの「プロパティ」ページが表示されます。

4. 「ロギング」の下の「ロギング・レベル」フィールドで、ログ・エントリを生成するレベルを選択します。

5. 適用されていない変更をすべて、保存された設定に戻すには、「元に戻す」をクリックします。

6. 操作設定を構成したら、「適用」をクリックしてランタイムに変更を保存します。

8.2.12 ビジネス・サービスのスロットルの構成

ビジネス・サービスのスロットルの詳細は、「メッセージ・スロットル用にビジネス・サービスを構成する方法」を参照してください。スロットルの構成の詳細および手順は、「1つのビジネス・サービスに対するスロットルの構成」を参照してください。

8.2.13 ビジネス・サービスのオフライン・エンドポイントURI処理の構成

オフライン・エンドポイントURIの管理の詳細は、「ビジネス・サービスのエンドポイントURIのモニターおよび管理」を参照してください。エンドポイントURI処理の構成の詳細および手順は、「応答しないエンドポイントURIをオフラインにするService Busの構成」を参照してください。

8.3 操作設定の一括更新

Service Busでは、開発環境からテスト環境への移動など、あるドメインから別のドメインにプロジェクトを移動する際に変更される可能性がある特定の環境値の更新に使用可能な構成ファイルを作成できます。

これには、グローバル・レベルとサービス・レベルの両方の操作設定の更新が含まれます。構成ファイルの作成および実行の詳細は、「応答しないエンドポイントURIをオフラインにするService Busの構成」を参照してください。

8.4 リソースのインポート時の操作設定の保持

Oracle JDeveloper、Oracle Service BusコンソールまたはFusion Middleware ControlにService Bus構成JARファイルをインポートする場合、インポート中の構成にインポート元のドメインのグローバル設定も含まれていると、ドメイン・レベルの設定は上書きされます。

インポートされる構成でグローバル設定を保持するには、サービスのインポート時に操作設定の保持フラグを選択します。これは、既存のシステムのグローバル設定を上書きします。インポート・プロセスによってサービスが更新される際、個別のサービスの操作設定にも同じことが適用されます。

また、APIを使用してService Bus構成をインポートするときにも、操作設定を保持することができます。詳細は、Oracle Service Bus Java APIリファレンスのALSBConfigurationMBeanを参照してください。インポート時に設定を保持するには、次の例に示すようにMBeanを変更します。

例 - APIを使用したOracle Service Bus構成のインポート時の操作設定の保持

/**
// Imports a configuration jar file, applies customization, activates it and
exports the resources again
// @throws Exception
/
static private void simpleImportExport(String importFileName, String passphrase)
throws Exception {
SessionManagementMBean sm = ... // obtain the mbean to create a session;
// obtain the raw bytes that make up the configuration jar file
File importFile = new File(importFileName);
byte[] bytes = readBytes(importFile);
// create a session
String sessionName = "session." + System.currentTimeMillis();
sm.createSession(sessionName);
// obtain the ALSBConfigurationMBean that operates on the
// session that has just been created
ALSBConfigurationMBean alsbSession = getConfigMBean(sessionName);
// import configuration into the session. First we upload the
// jar file, which will stage it temporarily.
alsbSession.uploadJarFile(bytes);
// then get the default import plan and modify the plan if required
ALSBJarInfo jarInfo = getImportJarInf();
ALSBImportPlan importPlan = jarInfo.getDefaultImportPlan();
// preserve operational values
importPlan. setPreserveExistingOperationalValues(true);
// Modify the plan if required and pass it to importUploaeded method
ImportResult result = alsbSession.importUploaded(importPlan);
// Pass null to importUploaded method to mean the default import plan.
//ImportResult result = alsbSession.importUploaded(null);
// print out status
if (result.getImported().size() > 0) {
System.out.println("The following resources have been successfully
imported.");
for (Ref ref : result.getImported()) {
System.out.println("\t" + ref);
}
}
if (result.getFailed().size() > 0) {
System.out.println("The following resources have failed to be imported.");
for (Map.Entry e : result.getFailed().entrySet()) {
Ref ref = e.getKey();
// Diagnostics object contains validation errors
// that caused the failure to import this resource
Diagnostics d = e.getValue();
System.out.println("\t" + ref + ". reason: " + d);
}
// discard the changes to the session and exit
System.out.println("Discarding the session.");
sm.discardSession(sessionName);
System.exit(1);
}
// peform the customization to assign/replace environment values and
// to modify the references.
...
// activate the session
sm.activateSession(sessionName, "description");
// export information from the core data
ALSBConfigurationMBean alsbcore = getConfigMBean(null);
//export the information at project level, pass only a collection of project
refs to this method
byte[] contentsProj =
alsbcore.exportProjects(Collections.singleton(Ref.DEFAULT_PROJECT_REF),null);
// the byte contents can be saved as jar file
}

9 Oracle Service Bus環境のカスタマイズ

この章では、各種のリソースに関連付けられた環境変数の値を検索して置換したり、Service Bus構成を環境間で移動するときにリソースおよび環境値を自動的に変更する構成ファイルを作成することによる Service Bus環境のカスタマイズについて詳しく説明します。

この章の内容は次のとおりです。

- 環境値について

- Oracle Service Busコンソールを使用した環境値の検索と置換

- 環境値と操作設定を更新するための構成ファイルの使用

- 使用可能な環境値

- 操作設定の環境値

- サンプル構成ファイル

9.1 環境値について

環境値とは、Service Bus構成に含まれるデータのことで、あるドメインから別のドメインに(たとえば、テストから本番に)構成を移動する際に変更される可能性があります。これらの事前定義済のフィールドと環境値は、Service Busのサービスまたはリソースを作成するときに構成するプロパティと対応します。

環境値は、URL、URI、ファイル名、ディレクトリ名、サーバー名、電子メール・サーバーなどのエンティティを表します。よい例は、プロキシ・サービスのURLです。これは、ドメインの物理的な場所によって変わります。環境値は、アラート宛先、プロキシ・サービス、ビジネス・サービス、SMTPサーバーとJNDIプロバイダのリソース、UDDIレジストリ・エントリ、およびトランスポートに含まれます。デプロイメントの一部として、環境値を更新し、ターゲット・システムに関連する値を反映させる必要があります。

Oracle Service Busコンソールの「検索置換」ダイアログを使用してドメイン内の環境値を更新するか、構成ファイルを作成して実行できます。「検索置換」ダイアログを使用すると、完全一致する環境値を置換することも、環境値の部分文字列を置換することもできるようになります(これは、小規模な変更を行うときに役立ちます)。構成ファイルを使用して、すべての環境変数の直接変更、文字列またはサブ文字列の検索と置換、グローバル・レベルおよびサービス・レベルの操作設定の更新、およびリソース間のリファレンスの更新を行えます。

9.1.1 検索と置換

Oracle Service Busコンソールの「検索置換」ダイアログを使用すると、ドメイン内の環境値を検索して、一致する値のリストを表示できます。また、値または値の一部を置換することもできます。たとえば、すべての環境値に含まれるサーバー名とポート番号のみを変更する必要がある場合は、すべての環境値に含まれるold_hostname:old_portを検索して、それをnew_hostname:new_portに一度に置換できます。「検索置換」ダイアログでは、操作設定の値は検索されません。

一部の環境値は複合XMLオブジェクトであり、「検索置換」オプションでは検索と置換を実行できません。ただし、これらの環境値は構成ファイルを使用して設定することはできます。また、スクリプトからALSBConfigurationMBeanを使用して直接設定することもできます。ALSBConfigurationMBeanの詳細は、Oracle Service Bus Java APIリファレンスを参照してください。

9.1.2 構成ファイル

構成ファイルは、開発からステージングへのデプロイメントやステージングからプロダクションへのデプロイメントの実行時や、設計時に、環境を変更するのに便利です。構成ファイルは、Service Busで使用される環境値、操作設定、および参照マッピングを定義するXMLベースのファイルです。環境値はXMLベースであるため、XMLエディタを使用して生成済の構成ファイルを簡単に変更できます。Service Busインスタンスに対して構成ファイルを作成して実行すると、プロジェクトを実行している環境に固有のプロパティを簡単に更新できます(プロパティを1つずつ更新する必要はありません)。構成ファイルを使用すると、環境変数の値に対して次に示すアクションを実行できます。

- 置換: 環境値の置換時には、新しい値がNULLであっても、新しい環境値で既存の値が置換されます。これは、その他のアクションが指定されていない場合のデフォルトのアクションです。このアクションは、すべての環境値でサポートされています。
置換アクションを使用したサンプル構成ファイルは、「サンプル構成ファイル」の「例 - 置換アクションを使用したグローバル操作設定の更新」を参照してください。

- 更新: 環境値の更新時には、新しい値が指定されていない場合を除いて、新しい環境値で既存の値を更新します。新しい値が指定されていない場合は、既存の値が維持されます。更新アクションでは指定した値のみが置換されるため、1つの設定のみを変更し、それ以外の設定では現在の値を保持する場合、これを置換アクションのかわりに使用します。更新アクションは、操作設定の環境値(表9-2にリストされているもの)でのみサポートされます。
更新アクションを使用したサンプル構成ファイルは、「サンプル構成ファイル」の「例 - 更新アクションを使用した操作設定の更新」を参照してください。

- 追加: これにより、新しい環境値を追加します。通常は、ビジネス・サービス・エンドポイントURIなど、複数のエントリを含む環境値にのみ適用します。このアクションは、サービスSLAアラート・ルール値でサポートされています。
追加アクションを使用したサンプル構成ファイルは、「サンプル構成ファイル」の「例 - SLAアラート・ルールの追加および削除」を参照してください。

- 削除: これにより、既存の環境値を削除します。通常は、ビジネス・サービス・エンドポイントURIなど、複数のエントリを含む環境値にのみ適用します。このアクションは、サービスSLAアラート・ルール値でサポートされています。
削除アクションを使用したサンプル構成ファイルは、「サンプル構成ファイル」の「例 - SLAアラート・ルールの追加および削除」を参照してください。

- 検索置換: 完全一致する環境値または環境値の部分文字列を置換する検索置換の操作を定義します。
検索置換アクションを使用したサンプル構成ファイルは、「サンプル構成ファイル」の「例 - 検索置換アクションを使用した値の更新」を参照してください。

構成ファイルの参照の新しいマッピングを定義することもできます。たとえば、プロキシ・サービスを新しい環境の別のパイプラインにマップできます。例は、「サンプル構成ファイル」の「例 - リソース参照の更新」を参照してください。

9.1.2.1 スキーマ・ファイル

構成ファイルは、このファイルに必要な書式を定義する複数のスキーマ・ファイルに基づいています。メインのスキーマ・ファイル(Customization.xsd)では、構成ファイルの全般的な書式を定義します。Oracle Service Busコンソールで構成ファイルを作成すると、ほとんどの必要な構文は自動的に生成されます。ただし、構成ファイルを使用してアラート・ルールを追加する場合を除きます。この場合は、次のスキーマを参照してください。

- AlertRule.xsd

- AlertRuleCondition.xsd

次のファイルでは、サービスに対する操作設定を定義します。

- BusinessOperations.xsd

- FlowOperations.xsd

- PipelineOperations.xsd

- ProxyOperations.xsd

- DomainConfig.xsd: グローバル操作設定の書式を記述します。

- EnvValues.xsd

- JmsEnvValues.xsd

XMLスキーマは、Service Busインストールの次の場所から入手できます。

OSB_ORACLE_HOME\lib\servicebus-schemas.jar

9.1.2.2 操作設定

操作設定は、Service Busサービスの特定の動作を実行時にグローバルおよびサービス・レベルで制御します。操作設定には、管理機能(モニター、ロギング、レポート、アラートなど)の有効化および無効化が含まれます。さらに、サービスに固有の構成プロパティ(ビジネス・サービスの場合はスロットルや結果キャッシュなど)も含まれます。操作設定の詳細は、「操作設定とグローバル設定の構成」を参照してください。

操作設定は、2つの環境値で定義します。これらの環境値は、構成ファイルには含まれていますが、「検索置換」ダイアログには含まれていません。Global Operational Settings変数では、すべてのService Busサービスの設定を定義します。Service Operational Settings変数では、特定のサービスの設定を定義します。

9.1.2.3 環境値

構成ファイル内のEnvValueActionsCustomizationType要素では、各リソースに含まれる特定のプロパティに新しい値を定義します。構成可能な環境変数は、Service Bus環境に含まれるリソースのタイプに応じて異なります。

9.1.2.4 検索と置換

構成ファイル内のFindAndReplaceCustomizationType要素では、特定の環境値に対する置換と検索の操作を定義します。この要素では、環境値についての問合せを定義して、それらの値に対する置換文字列を指定します。検索には、変更されたリソースのみを含めるかどうかというフィルタに加え、検索対象にするリソースのタイプ、環境値および参照によるフィルタを追加できます。検索文字列を指定して、isCompletematchフラグをfalseに設定すると、既存の環境値の一致部分文字列が置換されます。検索文字列の指定を省略すると、環境値全体が置換されます。この要素は、単純型(ブールや文字列)のみをサポートします。

9.1.2.5 参照マッピング

構成ファイル内のReferenceCustomizationType要素では、特定のリソースへの参照を更新します。この要素では、既存の参照とその参照のパスをリストし、新しい参照とパスを指定して既存の参照が参照するリソースを更新します。

9.2 Oracle Service Busコンソールを使用した環境値の検索と置換

Oracle Service Busコンソールの「検索置換」機能を使用して、ドメイン内の環境値を検索し、その値を必要に応じて新しい値に置換します。

この機能の動作は、セッション内で作業を行う場合と、そうでない場合とで異なります。セッション内にいる場合、環境値の検索と置換を行うことができます。ただし、セッション外にいる場合には、環境値の検索のみを実行できます。つまり、「すべて置換」は無効になります。

注意:

一部の環境値は複合XMLオブジェクトであり、Oracle Service Busコンソールでは、これらの環境値の検索と置換を実行できません。ただし、スクリプトからALSBConfigurationMBeanを使用して、これらの環境値を直接設定できます。ALSBConfigurationMBeanの詳細は、Oracle Service Bus Java APIリファレンスを参照してください。操作設定についても、コンソールを使用した検索と置換は実行できません。

複合型の環境値はAPIで設定するほかにも、構成ファイルを使用して設定することもできます。「環境値と操作設定を更新するための構成ファイルの使用」を参照してください。

9.2.1 環境値の検索

環境値の検索は、セッション内またはセッション外のどちらからでも実行できます。検索には、様々な基準(実際の値、変数のタイプ、特定のプロジェクト、現在のセッション、すべてのセッションなど)のフィルタを適用できます。

Oracle Service Busコンソールで環境値を検索するには:

1. Oracle Service Busコンソールで、「管理」タブをクリックし、「検索置換」をクリックします。

「検索置換」ダイアログが表示されます。

図9-1 「検索置換」ダイアログ

2. 「検索する値」フィールドに、検索する環境値を入力します。

このフィールドには、部分的な値を入力できます。たとえば、"fal"と入力すると、falseに設定されているすべての環境値に加え、文字列"fal"が含まれている値が表示されます。

3. 現在のセッションで変更された項目のみを検索するには、「現在のセッションのみ」を選択します。

4. 「変数の型」リストで、検索対象にする環境値のタイプを選択します。

表9-1に、選択可能なタイプの一覧と説明を示します。

5. 特定のプロジェクト内にある環境値を検索するには、「プロジェクト」リストでプロジェクト名を選択します。

6. 「検索」をクリックします。

ページの下側にある「検索と置換の結果」タブに、一致する値のリストが表示されます。

9.2.2 環境値の置換

環境値の置換時に、Service Busは、「検索する値」フィールドに入力した値と完全に一致する検索結果の値を、「置換する値」フィールドに入力した値で置換します。

Oracle Service Busコンソールで環境値を置換するには:

1. Oracle Service Busコンソールを起動します。

2. 値を検索するだけでなく置換も必要な場合は、セッション内にいることを確認します。「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションに入ります。

3. 「管理」タブをクリックし、「検索置換」をクリックします。

「検索置換」ダイアログが表示されます。

4. 検索対象にする環境値の検索基準を入力します(「環境値の検索」を参照)。

「検索する値」フィールドに、置換対象と完全に一致する値を入力していることを確認します。

5. 「検索」をクリックすると、構成内で基準と一致する環境値のリストが表示されます。

ページの下側にある「検索と置換の結果」タブに、一致する値のリストが表示されます。

6. 「置換する値」フィールドに、新しい環境値を入力します。「検索する値」フィールドに入力した値は、この新しい値に置換されます。

図9-2 「検索置換」ダイアログと置換値

7. 「置換」をクリックして、すべての検索結果に含まれる元の環境値を新しい値に置換します。

「検索する値」フィールドに入力した値に一致するすべての値が、現在のセッションの「置換する値」フィールドに入力した環境値に置換されます。

8. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

9.3 環境値と操作設定を更新するための構成ファイルの使用

現在の構成に基づいて構成ファイルを生成するには、Oracle Service Busコンソールを使用します。

通常は、Service Busのリソースを新しいドメインにインポートして、このインポートしたリソースに基づいた構成ファイルを作成し、構成ファイル内の値を更新してから、新しいドメインに対して更新した構成ファイルを実行します。

構成ファイルには、選択したリソース内で使用されているすべての環境値に対するカスタマイズを含めることができます(たとえば、EnvValueTypesクラス内で定義された複合型の環境値)。実行可能なアクションは、EnvValueActionクラスに定義されています。さらに、構成ファイルには、リソース内での依存関係を持つリソース参照を変更するための、参照型のカスタマイズも含めることができます。

構成ファイルの詳細は、「構成ファイル」を参照してください。EnvValueTypesおよびEnvValueActionの詳細は、Oracle Service Bus Java APIリファレンスを参照してください。

9.3.1 構成ファイルの作成

Oracle Service Busコンソールは、選択するリソースまたはプロジェクトのセットの構成ファイルを生成するのに便利です。このファイルは、特定のService Bus環境に応じた実際の値を指定することで必要な変更を行うための出発点として使用できます。

Service Busで生成した構成ファイルには、置換アクションのみが含まれています。それ以外のアクション(更新、追加または削除)を実行する場合は、生成されたファイルを手動で更新して新しいアクションを実行するようにする必要があります。

構成ファイルを作成するには:

1. Oracle Service Busコンソールで、「管理」タブを選択して、「構成ファイルの作成」をクリックします。
「構成ファイルの作成」ページが表示され、構成に含まれるオブジェクトのリストが示されます。

2. 構成ファイルに含めるプロジェクトまたはリソースを選択します。

a. 右矢印をクリックして、プロジェクトのフォルダを開きます。プロジェクトに含まれる各リソースの名前と型が表示されます。

b. 構成ファイルに含めるプロジェクトまたはリソースに対応するチェック・ボックスを選択します。

c. 構成ファイルに含めないプロジェクトまたはリソースに対応するチェック・ボックスの選択を解除します。

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

4. 「ファイルのダウンロード」ダイアログ・ボックスで、「開く」をクリックしてファイルを開くか、「保存」をクリックしてファイルをローカル・マシンに保存します。

5. XMLエディタで、作成したベースの構成ファイルに関連したカスタマイズ・スキーマを使用して、リソースと環境変数に対して必要な変更を行います。
ベースの構成ファイルには、環境変数がすでに移入されている場合があります。表9-1に、各種リソースに自動的に含まれる環境変数を示します。

9.3.2 構成ファイルの実行

構成ファイルを作成し、新しいドメインに合せて値を更新しておくと、事前にシステムに保存したファイルを実行できます。構成ファイルを実行するには、セッション内にいる必要があります。

構成ファイルを実行するには:

1. 環境値の更新を適用する環境内で、Oracle Service Busコンソールを起動します。

2. セッションをまだ作成していない場合は、「作成」をクリックして新しいセッションを作成するか、「編集」をクリックして既存のセッションを入力します。

3. 「管理」タブをクリックし、「構成ファイルの実行」をクリックします。

4. 「参照」をクリックし、実行する構成ファイルの場所にナビゲートしてファイルを選択します。

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

構成ファイルの実行による変更内容のサマリーが表示されます。

6. 現在のセッションで変更されたリソース、サービス、プロジェクトまたはフォルダのみを構成するには、「現在のセッションで編集した項目のみ表示」を選択します。

構成の対象を現在のセッションで変更されたリソースのみに限定すると、「適用先」列が更新され、現在のセッションで変更されたリソースが表示されます。プロジェクトまたはフォルダのカスタマイズに限定すると、現在のセッションで変更された、そのプロジェクトまたはフォルダ内のリソースが「適用先」列に表示されます。

7. サマリーにリストされたすべての変更内容を見直して、それらの変更内容に間違いがないことを確認します。

8. 「終了」をクリックして、現在のセッションで更新をコミットします。

構成の詳細を表示するには、セッション内で、ページの下部にある「履歴」タブの「カスタマイズ」タスクをクリックします。

9. セッションを終了して構成をランタイムにデプロイするには、「アクティブ化」をクリックします。

9.4 使用可能な環境値

環境変数は、「検索置換」ダイアログと、環境プロパティを更新するために作成する構成ファイル内に示されます。

次の表は、環境内で検索、置換および更新できる環境値の一覧を示しています。構成ファイル内の一部の変数には、場所が含まれているものがあります。この場所は、その値への(値のリストでの)索引を表すゼロ以上の整数値になります。たとえば、URI値の場所には、複数のエンドポイントURIを持つビジネス・サービスに関連付けられている特定のURIを指定できます。

EnvValueTypesの詳細は、Oracle Service Bus Java APIリファレンスを参照してください。これらの環境値のJava型および場所の値は、APIリファレンスで説明されています。すべての環境値のタイプの値の詳細は、環境値が検索されたコンポーネントのオンライン・ヘルプを参照してください。

表9-1 リソースの環境値

環境値

場所

説明

SNMPトラップのアラート

アラート宛先

アラート宛先のSNMPトラップが有効化されているかどうかを示すインジケータ。

ログに記録するアラート

アラート宛先

アラート宛先のアラート・ロギングが有効化されているかどうかを示すインジケータ。

レポート・データへのアラート

アラート宛先

アラート宛先のアラート・レポートが有効化されているかどうかを示すインジケータ。

動的キュー・プーリング

MQ接続

電子メールのアーカイブ・ディレクトリ

電子メール・プロキシ・サービス

電子メール・プロキシ・サービスのアーカイブ・ディレクトリ。

電子メール宛先URI

アラート宛先

電子メール・アラート宛先のURI。この変数には、構成ファイル内での場所が含まれています。

電子メールのダウンロード・ディレクトリ

電子メール・プロキシ・サービス

電子メール・プロキシ・サービスのダウンロード・ディレクトリ。

電子メールのエラー・ディレクトリ

電子メール・プロキシ・サービス

電子メール・プロキシ・サービスのエラー・ディレクトリ。

ファイルのアーカイブ・ディレクトリ

ファイル・プロキシ・サービス

ファイル・プロキシ・サービスのアーカイブ・ディレクトリ。

ファイルのエラー・ディレクトリ

ファイル・プロキシ・サービス

ファイル・プロキシ・サービスのエラー・ディレクトリ。

ファイルのステージ・ディレクトリ

ファイル・プロキシ・サービス

ファイル・プロキシ・サービスのステージ・ディレクトリ。

FTPアーカイブ・ディレクトリ

FTPプロキシ・サービス

FTPプロキシ・サービスのアーカイブ・ディレクトリ。

FTPダウンロード・ディレクトリ

FTPプロキシ・サービス

FTPプロキシ・サービスのダウンロード・ディレクトリ。

FTPエラー・ディレクトリ

FTPプロキシ・サービス

FTPプロキシ・サービスのエラー・ディレクトリ。

HTTPアウトバウンド接続タイムアウト

HTTPビジネス・サービス

HTTPビジネス・サービスの接続タイムアウト間隔(秒単位)。

HTTPアウトバウンド・ソケット読取りタイムアウト

HTTPビジネス・サービス

HTTPビジネス・サービスの読取りタイムアウト間隔(秒単位)。

IMAP移動先フォルダ

電子メール・プロキシ・サービス

電子メール・プロキシ・サービスのIMAP移動先ディレクトリ。

JCAは常にWSDLフラグを使用

JCAプロキシ・サービスおよびビジネス・サービス

接続ファクトリ・プロパティ、アクティブ化仕様プロパティ(プロキシ・サービス)および対話仕様プロパティ(ビジネス・サービス)が、常にWSDLファイルから使用されるかどうかを示すインジケータ。

JCA接続モード

JCAプロキシ・サービスおよびビジネス・サービス

サービスが関連するJCAアダプタ(管理対象または非管理対象のモード)に接続する方法を指定するモード。有効な値は、managedまたはnon-managedです。

JCA上書き接続認証フラグ

JCAプロキシ・サービスおよびビジネス・サービス

JCAアダプタ接続ファクトリ内の認証資格証明が、開発環境またはテスト環境(非管理対象の接続モード)でオーバーライドされているかどうかを示すインジケータ。

JEJBプロキシ・リモート・クライアント・タイムアウト

JEJBプロキシ・サービス

JEJBプロキシ・サービスのRMIクライアント・タイムアウト間隔(秒単位)。

JMSアラート宛先URI

アラート宛先

JMSアラート宛先のURI。この変数には、構成ファイル内での場所が含まれています。

JMS管理対象サーバー

JMSビジネス・サービス

メッセージIDのレスポンス相関パターンを持つJMSビジネス・サービスの宛先に関連付けられた管理対象サーバー。この変数には、構成ファイル内での場所が含まれています。

JMSキュー接続ファクトリ

JMSプロキシ・サービスおよびビジネス・サービス

メッセージIDのレスポンス相関パターンを持つJMSプロキシ・サービスまたはビジネス・サービスのレスポンス・キュー接続ファクトリ。この変数には、構成ファイル内での場所が含まれています。プロキシ・サービスの場合、場所はNULLになります。

JMSレスポンス宛先

JMSビジネス・サービス

メッセージIDのレスポンス相関パターンを持つJMSビジネス・サービスの宛先。この変数には、構成ファイル内での場所が含まれています。

JMSレスポンスURI

JMSプロキシ・サービスおよびビジネス・サービス

JMS相関IDのレスポンス相関パターンを使用するJMSプロキシ・サービスまたはビジネス・サービスのレスポンス・キューのURI。この変数には、構成ファイル内での場所が含まれています。

JNDIプロバイダURL

JNDIプロバイダ

JNDIプロバイダのURL。

ポーリングの管理対象サーバー

クラスタ・ドメイン内の電子メール、ファイル、FTPまたはSFTPプロキシ・サービス

クラスタ・ドメイン内のポーリング用管理対象サーバー。

MQ接続リスト

MQ接続

マルチインスタンス・キュー・マネージャ・サポートが有効である場合に使用するMQ接続のリスト。

MQ接続プール・サイズ

MQ接続

MQ接続プール・サイズ

MQ接続タイムアウト

MQ接続

未使用の接続が破棄される時間間隔

MQ配信失敗メッセージURI

MQプロキシ・サービス

パイプラインがメッセージを指定された回数だけ送信を再試行した後、リクエスト・メッセージがリダイレクトされる配信失敗メッセージ・キューのURI 。

MQホスト名

MQ接続

MQキュー・マネージャをホストしているサーバーの名前。

QMが有効化されたMQマルチインスタンス

MQ接続

MQマルチインスタンス・キュー・マネージャ・サポートが有効かどうかを示すインジケータ。有効な場合、MQ接続リストの接続のリストが使用されます。

MQポート番号

MQ接続

MQキュー・マネージャ・リスナーのポート番号。

MQキュー・マネージャのチャネル名

MQ接続

MQキュー・マネージャのサーバー接続のチャネル名。

MQキュー・マネージャ名

MQ接続

MQキュー・マネージャ名。

MQレスポンスURI

MQプロキシおよびビジネス・サービス

プロキシ・サービス・レスポンスまたはビジネス・サービス・レスポンスのURI。

MQ認識できないレスポンスURI

MQビジネス・サービス

認識できないレスポンス・メッセージが送信されるキューのURI。

MQバージョン

MQ接続

使用されるWebSphere MQのバージョン。

MQ XA有効

MQ接続

MQ接続によって処理されるトランザクションが分散(XA)トランザクションであるかどうかを示すインジケータ。

プロキシ・サーバー・ホスト

プロキシ・サーバー

プロキシ・サーバー・リソース内のプロキシ・サーバーのホスト名。この変数には、構成ファイル内での場所が含まれています。

プロキシ・サーバー・ポート

プロキシ・サーバー

プロキシ・サーバー・リソース内のプロキシ・サーバーのポート番号。この値は、整数になります。この変数には、構成ファイル内での場所が含まれています。

JMSサーバーへのセキュアな接続

JMSプロキシ・サービスおよびビジネス・サービス

Service BusがSSLを使用してJMSサーバーに接続するかどうかを示すインジケータ。trueの場合、Service BusはSSL (t3s)を使用してJMSサーバーおよびJNDIツリーに接続します。そうでない場合、接続はクリア・テキスト(t3)チャネルで行われます。場所の値はNULLにする必要があります。

サービスの再試行回数

ビジネス・サービス

ビジネス・サービスのエンドポイントURIが再試行される回数、つまり、フェイルオーバーの試行数。

サービス再試行の反復間隔

ビジネス・サービス

URIセット全体の再試行を繰り返すまでにビジネス・サービスが待機する時間。

サービスURI

プロキシまたはビジネス・サービス

プロキシまたはビジネス・サービスのURI。この変数には、構成ファイル内での場所が含まれています。プロキシ・サービスの場合、場所は定義されません。

サービスURIの重み

ビジネス・サービス

ビジネス・サービスURIに割り当てられた個々の重み。この変数には、構成ファイル内での場所が含まれています。

SFTPアーカイブ・ディレクトリ

SFTPプロキシ・サービス

SFTPプロキシ・サービスのアーカイブ・ディレクトリ。ダイレクト・ストリーミングがオンの場合、このアーカイブ・ディレクトリはリモートSFTPサーバーに存在し、それ以外の場合はローカルに存在します。

SFTPダウンロード・ディレクトリ

SFTPプロキシ・サービス

SFTPプロキシ・サービスのダウンロード・ディレクトリ。

SFTPエラー・ディレクトリ

SFTPプロキシ・サービス

SFTPプロキシ・サービスのエラー・ディレクトリ。ダイレクト・ストリーミングがオンの場合、このエラー・ディレクトリはリモートSFTPサーバーに存在し、それ以外の場合はローカルに存在します。

SFTP優先暗号スイート

SFTPプロキシ・サービスおよびビジネス・サービス

SFTPプロキシ・サービスおよびビジネス・サービスでの認証と暗号化に使用する暗号スイート。

SFTP優先圧縮アルゴリズム

SFTPプロキシ・サービスおよびビジネス・サービス

SFTPプロキシ・サービスおよびビジネス・サービスで処理中のデータの圧縮に使用する圧縮ライブラリ。

SFTP優先データ整合性アルゴリズム

SFTPプロキシ・サービスおよびビジネス・サービス

SFTPプロキシ・サービスおよびビジネス・サービスでの整合性チェックに使用するバルク・ハッシュ・アルゴリズム。

SFTP優先鍵交換アルゴリズム

SFTPプロキシ・サービスおよびビジネス・サービス

SFTPプロキシ・サービスおよびビジネス・サービスでメッセージの暗号化に使用するセッション鍵をネゴシエートするためのデフォルトの鍵交換プロトコル。

SFTP優先公開鍵アルゴリズム

SFTPプロキシ・サービスおよびビジネス・サービス

SFTPプロキシ・サービスおよびビジネス・サービスでの公開鍵暗号化に使用する非対称鍵アルゴリズム。

SMTPサーバーURL

SMTPサーバー

SMTPサーバーのURL。

スロットル・グループ有効

スロットル・グループ

ビジネス・サービスのスロットル・グループが有効化されているかどうかを示すインジケータ。

スロットル・グループ最大同時実行性

スロットル・グループ

スロットル・グループで同時処理可能なメッセージの最大数。

スロットル・グループ最大キュー長

スロットル・グループ

キュー内のメッセージ数を制限するスロットル・キューに許容された最大メッセージ数。

スロットル・グループ存続時間

スロットル・グループ

スロットル・グループのスロットル・キューにメッセージが存在できる最長時間(ミリ秒単位)。

Tuxedoアクセス・ポイント・マップ

プロキシまたはビジネス・サービス

URIごとに1つの場所がある管理対象サーバーごとのローカル・アクセス・ポイントの名前とアドレス。

Tuxedoアクセス・ポイント名

ビジネス・サービス

URIに関連付けられたリモートWTCアクセス・ポイントの名前。

Tuxedoネットワーク・アドレス

ビジネス・サービス

URIに関連付けられたリモートWTCアクセス・ポイントのネットワーク・アドレス。

UDDI自動インポート

UDDIレジストリ

UDDIレジストリからインポートしたビジネス・サービスの自動同期が有効化されているかどうかを示すインジケータ。このプロパティは、レジストリごとに選択します。

UDDI自動パブリッシュ

プロキシ・サービス

プロキシ・サービスに対して、UDDIレジストリへの自動パブリッシュが有効化されているかどうかを示すインジケータ。

UDDI照会URL

UDDIレジストリ

UDDIレジストリの照会URL。

UDDIパブリッシュURL

UDDIレジストリ

UDDIレジストリのパブリッシュURL。

UDDIセキュリティURL

UDDIレジストリ

UDDIレジストリのセキュリティURL。

UDDIサブスクリプションURL

UDDIレジストリ

UDDIレジストリのサブスクリプションURL。

WSエラー・キューURI

WSビジネス・サービス

エラー・メッセージを格納するJMSキューのURI。

ワーク・マネージャ

プロキシ・サービスとビジネス・サービス

すべてのプロキシ・サービスおよびビジネス・サービスでのディスパッチ・ポリシーの名前。

9.5 操作設定の環境値

構成ファイル内にグローバル・レベルおよびサービス・レベルの両方で操作設定を定義すると、新しい環境に含まれるそれらの操作設定はスクリプトで更新できます。

次の表に示す値を使用すると、操作設定用の新しい値を定義できます。Service Bus環境から構成ファイルを生成すると、そのファイルには自動的に操作設定が含まれます。

表9-2 操作設定の環境値

環境値

場所

値

グローバル操作設定

プロキシ・サービスおよびビジネス・サービス、パイプライン、分割-結合

プロキシ・サービス、ビジネス・サービス、パイプラインおよび分割-結合のグローバル操作設定。次のグローバル設定に値を指定できます。

- モニタリング有効

- レポート有効

- ロギング有効

- SLAアラート有効

- パイプライン・アラート有効

- 結果キャッシュ有効

- 最大ロック・グループ数(リシーケンサ)

- ロッカー・スレッドのスリープ間隔(リシーケンサ)

- 完了済メッセージを削除するかどうか(リシーケンサ)

この値は、操作設定の置換および更新をサポートしています。

サービス操作設定

プロキシ・サービスおよびビジネス・サービス、パイプライン、分割-結合

プロキシ・サービスまたはビジネス・サービス、パイプライン、または分割-結合の操作設定。使用可能な操作設定は、サービス・タイプによって異なります。この値は、操作設定の置換および更新をサポートしています。

サービスSLAアラート・ルール

プロキシ・サービスおよびビジネス・サービス、パイプライン、分割-結合

プロキシ・サービスまたはビジネス・サービス、パイプライン、または分割-結合についてのすべてのアラート・ルール。この値は、置換アクションのみをサポートしていて、1つのリソースに対するすべてのアラート・ルールを置換するために使用できます。

サービスSLAアラート・ルール

プロキシ・サービスおよびビジネス・サービス、パイプライン、分割-結合

プロキシまたはビジネス・サービス、パイプライン、または分割-結合に対するアラート・ルールのプロパティ。この値は、ルールの置換、更新、追加および削除をサポートしています。場所も含まれており、新しいルールを挿入する場所を指定できます。ルールを追加する際は、次の場所のいずれかを指定します。

- Null: 新しいルールは、ルールのリストの末尾に挿入します。

- アラート・ルールの名前: 新しいルールは、入力したアラート・ルールの前に挿入します。

アラート・ルールを削除する際は、その場所で削除するルールの名前を指定します。

9.6 サンプル構成ファイル

ここでは、構成ファイルからの抜粋を示します。これらの抜粋部分は、Service Busドメインに対する各種の更新(操作設定、SLAアラート・ルールおよび参照の更新)を実行する方法を示しています。また、検索と置換の機能の使用法についても示しています。

例 - 置換アクションを使用したグローバル操作設定の更新

次の例では、操作設定を<xt:replace>要素の子<con:operations>で指定された値に置換します。値が指定されていない<xt:replace>要素内の項目にはnull値が割り当てられます。

<cus:customization xsi:type="cus:EnvValueActionsCustomizationType">
<cus:description/>
<cus:owners>
<xt:owner>
<xt:type>Operations</xt:type>
<xt:path>System/Operator Settings/GlobalOperationalSettings</xt:path>
</xt:owner>
</cus:owners>
<cus:actions>
<xt:replace>
<xt:envValueType>Global Operational Settings</xt:envValueType>
<xt:value>
<con:operations>
<con:monitoring>true</con:monitoring>
<con:reporting>false</con:reporting>
<con:logging>true</con:logging>
<con:sla-alerting>true</con:sla-alerting>
<con:pipeline-alerting>true</con:pipeline-alerting>
<con:result-caching>false</con:result-caching>
<con:resequencer-settings>
<con:maxGroupsLocked>15</con:maxGroupsLocked>
<con:lockerThreadSleep>10</con:lockerThreadSleep>
<con:deleteCompletedMessage>true</con:deleteCompletedMessage>
</con:resequencer-settings>
</con:operations>
</xt:value>
</xt:replace>
</cus:actions>
</cus:customization>

例 - 更新アクションを使用した操作設定の更新

次の例では、「モニター」操作設定をtrueに更新します。新しい値が指定されていないため、他の操作設定の値は更新されます。

<cus:customization xsi:type="cus:EnvValueActionsCustomizationType">
<cus:description/>
<cus:owners>
<xt:owner>
<xt:type>Operations</xt:type>
<xt:path>System/Operator Settings/GlobalOperationalSettings</xt:path>
</xt:owner>
</cus:owners>
<cus:actions>
<xt:update>
<xt:envValueType>Global Operational Settings</xt:envValueType>
<xt:value>
<con:operations xmlns:con="http://xmlns.oracle.com/servicebus/domain/config">
<con:monitoring>true</con:monitoring>
<con:reporting></con:reporting>
<con:logging></con:logging>
<con:sla-alerting></con:sla-alerting>
<con:pipeline-alerting></con:pipeline-alerting>
<con:result-caching></con:result-caching>
<con:resequencer-settings>
<con:maxGroupsLocked></con:maxGroupsLocked>
<con:lockerThreadSleep></con:lockerThreadSleep>
<con:deleteCompletedMessage></con:deleteCompletedMessage>
</con:resequencer-settings>
<con:javaScript-timeout></con:javaScript-timeout>
<con:automatic-service-migration></con:automatic-service-migration>
</con:operations>
</xt:value>
</xt:update>
</cus:actions>
</cus:customization>

例 - SLAアラート・ルールの追加および削除

この抜粋部分では、TicketProcessプロジェクトのbix_transferというビジネス・サービスに新しいSLAアラート・ルール(ErrorCount)を追加する方法を示しています。新しいルールは、AverageResponseルールの前に追加されます。この抜粋部分では、sj_transferという名前の分割-結合からSLAアラートを削除する方法も示しています。

<cus:customization xsi:type="cus:EnvValueActionsCustomizationType">
<cus:description>Add new alert rule to multiple services</cus:description>
<cus:owners>
<xt:owner>
<xt:type>BusinessService</xt:type>
<xt:path>TicketProcess/bix_transfer</xt:path>
</xt:owner>
<xt:ownerQuery>
<xt:resourceTypes>ProxyService</xt:resourceTypes>
</xt:ownerQuery>
</cus:owners>
<cus:actions>
<xt:add>
<xt:envValueType>Service SLA Alert Rule</xt:envValueType>
<xt:location>AverageResponse</xt:location>
<xt:value>
<aler:alertRule enabled="true" name="ErrorCount"
xmlns:con="http://xmlns.oracle.com/servicebus/business/config"
xmlns:oper1="http://xmlns.oracle.com/servicebus/operations"
xmlns:oper="http://xmlns.oracle.com/servicebus/business/operations">
<aler:description>Transport error count limit</aler:description>
<aler:frequency>every-time</aler:frequency>
<aler:severity>minor</aler:severity>
<aler:stopProcessing>true</aler:stopProcessing>
<aler:condition aggregation-interval="10">
<con1:monCondExpr xmlns:con1="http://xmlns.oracle.com/servicebus/monitoring/alert/condition">
<con1:function>count</con1:function>
<con1:lhs>Transport.error-count</con1:lhs>
<con1:operator>></con1:operator>
<con1:rhs>0</con1:rhs>
</con1:monCondExpr>
</aler:condition>
<aler:alertDestination ref="TicketProcess/dest"/>
<aler:summary>Transport error count exceeded.</aler:summary>
</aler:alertRule>
</xt:value>
</xt:add>
</cus:actions>
</cus:customization>
<cus:customization xsi:type="cus:EnvValueActionsCustomizationType">
<cus:description>Delete alert rule</cus:description>
<cus:owners>
<xt:owner>
<xt:type>FLOW</xt:type>
<xt:path>TicketProcess/sj_transfer</xt:path>
</xt:owner>
</cus:owners>
<cus:actions>
<xt:delete>
<xt:envValueType>Service SLA Alert Rule</xt:envValueType>
<xt:location>rule1</xt:location>
</xt:delete>
</cus:actions>
</cus:customization>

例 - 検索置換アクションを使用した値の更新

次の例では、プロキシ・サービスおよびビジネス・サービス内でlocalhost:7001を含んでいる環境値を検索して、その値または部分文字列をtest1500env:7101に置換します。

<cus:query>要素内の項目によって、検索するリソース、環境値およびパスが決まります。<xt:searchString>要素には、検索文字列を含めます。<cus:replacement>要素には、置換文字列を含めます。

<cus:customization xsi:type="cus:FindAndReplaceCustomizationType">
<cus:description/>
<cus:query>
<xt:resourceTypes>ProxyService</xt:resourceTypes>
<xt:resourceTypes>BusinessService</xt:resourceTypes>
<xt:envValueTypes>File Error Directory</xt:envValueTypes>
<xt:envValueTypes>Service Retry Iteration Interval</xt:envValueTypes>
<xt:envValueTypes>UDDI Auto Publish</xt:envValueTypes>
<xt:envValueTypes>Service URI Weight</xt:envValueTypes>
<xt:envValueTypes>File Stage Directory</xt:envValueTypes>
<xt:envValueTypes>Service Retry Count</xt:envValueTypes>
<xt:envValueTypes>Service URI</xt:envValueTypes>
<xt:envValueTypes>Managed Server for Polling</xt:envValueTypes>
<xt:envValueTypes>File Archive Directory</xt:envValueTypes>
<xt:refsToSearch xsi:type="xt:ResourceRefType">
<xt:type>ProxyService</xt:type>
<xt:path>Order/ps_order</xt:path>
</xt:refsToSearch>
<xt:refsToSearch xsi:type="xt:ResourceRefType">
<xt:type>BusinessService</xt:type>
<xt:path>Order/bs_order</xt:path>
</xt:refsToSearch>
<xt:includeOnlyModifiedResources>false</xt:includeOnlyModifiedResources>
<xt:searchString>localhost:7001</xt:searchString>
<xt:isCompleteMatch>false</xt:isCompleteMatch>
</cus:query>
<cus:replacement>test1500env:7101</cus:replacement>
</cus:customization>

例 - リソース参照の更新

次の抜粋部分では、Orderプロジェクトのbs_orderというビジネス・サービスへの参照を、OrderProcessプロジェクトのbs_orderへの参照に更新します。

<cus:customization xsi:type="cus:ReferenceCustomizationType">
<cus:description/>
<cus:refsToBeConsidered xsi:type="xt:ResourceRefType">
<xt:type>ProxyService</xt:type>
<xt:path>Order/order_proxy</xt:path>
</cus:refsToBeConsidered>
<cus:refsToBeConsidered xsi:type="xt:ResourceRefType">
<xt:type>Pipeline</xt:type>
<xt:path>Order/ps_orderPipeline</xt:path>
</cus:refsToBeConsidered>
<cus:externalReferenceMap>
<xt:oldRef>
<xt:type>BusinessService</xt:type>
<xt:path>Order/bs_order</xt:path>
</xt:oldRef>
<xt:newRef>
<xt:type>BusinessService</xt:type>
<xt:path>OrderProcess/bs_order</xt:path>
</xt:newRef>
</cus:externalReferenceMap>
</cus:customization>

10 Oracle Service Busリソースのインポートとエクスポート

この章では、Fusion Middleware Controlを使用して、Service Busのプロジェクトとリソースをインポートおよびエクスポートする手順について説明します。

この章の内容は次のとおりです。

- Oracle Service Busリソースのインポートとエクスポートについて

- Fusion Middleware Controlを使用したOracle Service Busリソースのエクスポート

- Fusion Middleware Controlを使用したService Busリソースのインポート

10.1 Oracle Service Busリソースのインポートとエクスポートについて

Fusion Middleware Controlでは、構成JARファイル全体をインポートすることも、JARファイルに含まれるリソースのサブセットのみをインポートすることもできます。また、このコンソールからは、構成JARファイル全体をエクスポートすることもできます。

構成JARファイルには、Service Busインスタンスから以前にエクスポートされたプロジェクトまたはリソースが含まれます。インポートするリソースが、すでにインポート先システムに存在する場合は、そのリソースが更新されます。リソースの削除は、インポートするJARファイルにプロジェクト全体が含まれていて、Fusion Middleware Controlの同じプロジェクトに配置されたリソースがあり、インポートするJARファイルにはそのリソースが存在しない場合にのみスケジュールされます。その他のプロジェクトに含まれるリソースは、削除されません。

Service Busリソースのインポートと同時に、作業対象のドメインに固有の環境値を定義する構成ファイルもインポートできます。環境値には、サービスのURL、特定のトランスポートのファイルの場所、ホスト名、ポート番号などを含めてもかまいません。また、グローバル・レベルおよびサービス・レベルの操作設定や、リソース参照への更新を含めることもできます。構成ファイルの詳細は、「Oracle Service Bus環境のカスタマイズ」を参照してください。

このインポートおよびエクスポートの機能は、Oracle JDeveloperとOracle Service Busコンソールにも適用されます。詳細および手順は、『Oracle Service Busでのサービスの開発』のリソースおよび構成のインポートとエクスポートに関する項を参照してください。この章では、インポートおよびエクスポートの処理についても説明します。これには、インポート時にリソースを作成、更新または削除する方法と、セキュリティ設定および操作設定の処理方法についての説明も含まれます。また、oracle.osb.config.parallelismシステム・プロパティの使用による大規模なインポートのパフォーマンスの向上についての情報も含まれています。

10.2 Fusion Middleware Controlを使用したOracle Service Busリソースのエクスポート

Service Busプロジェクトをエクスポートすることも、プロジェクトから個別のリソースをエクスポートすることもできます。エクスポート機能を使用すると、サーバー上のすべてのプロジェクトとリソースのリストから、エクスポートするプロジェクトまたはリソースを選択できます。

プロジェクト・レベルからエクスポートする場合は、リストを開いてすべてのリソースを表示することはできますが、プロジェクト・レベルでの選択のみが可能になります。リソース・レベルのエクスポートの場合、Service Busでは、選択したリソースが参照しているリソースを自動的にエクスポート・ファイルに含めることを選択できます。このようにすることで、ファイルを再インポートするときに、壊れた参照が原因になる競合を回避できます。

エクスポートするプロジェクトとリソースに関連付けられたユーザー、グループまたはロールのエクスポートはできません。また、WebLogic Server管理コンソールで作成した資格証明マップやその他のセキュリティ・プロバイダ・データもエクスポートできません。このデータをエクスポートするには、かわりにWebLogic Server管理コンソールを使用します。『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のセキュリティ・データの移行に関する項を参照してください。

プロジェクトまたはリソースをエクスポートするときには、サービス・アカウント、サービス・キー・プロバイダ、UDDIレジストリ、JNDIプロバイダ、またはSMTPプロバイダの各リソースに含まれるユーザー名およびパスワードを暗号化するパスフレーズを入力できます。JARファイルを再インポートするときに、パスフレーズを再度指定する必要があります。次の図は「リソースのエクスポート」ページを示しています。

図10-1 「リソースのエクスポート」ページ

Oracle Service Busのリソースをエクスポートするには:

1. Fusion Middleware Controlのターゲット・ナビゲータで、「SOA」を開き、リソースのエクスポート元になるService Busサーバーを開きます。

2. Service Busサーバー名またはサーバー内のプロジェクト名を右クリックして、「エクスポート」を選択します。

ヒント:

「Service Bus」または「Service Busプロジェクト」メニューから「エクスポート」を選択することもできます。

3. 「リソースのエクスポート」ページで、「プロジェクト」を選択してプロジェクト全体をエクスポートするか、「リソース」を選択して個別のリソースをエクスポートします。

4. リソース・レベル・エクスポートの場合、「リソースの依存関係を含める」を選択して、選択したリソースが参照する追加のリソースをエクスポートします。チェック・ボックスをクリアして、選択したリソースのみをエクスポートします。

5. リソースのリストを展開し、エクスポートするリソースのみが選択されていることを確認します。

6. エクスポートしたリソース内の機密データを暗号化するには、「パスフレーズ」フィールドと「パスフレーズの確認」フィールドに、ファイルのロックを解除するためのパスワードを入力します。

詳細は、『Oracle Service Busでのサービスの開発』のエクスポート時のデータ暗号化に関する項を参照してください。

7. 「エクスポート」をクリックします。

8. 「処理中: プロジェクトのエクスポート」ダイアログで、「保存」をクリックします。

9. 「ファイルのダウンロード」ダイアログで、「保存」をクリックし、構成JARファイルの場所とファイル名を指定し、「保存」を再度クリックします。

Service Busは、指定された場所に構成JARファイルを生成します。

10. 「処理中: プロジェクトのエクスポート」ダイアログを閉じるには、ダイアログ・ボックスの右上隅にある「X」をクリックします。

10.3 Fusion Middleware Controlを使用したService Busリソースのインポート

Fusion Middleware Controlのインポート機能を使用して、Service BusインスタンスからエクスポートしたService Busのプロジェクトまたはリソースをインポートします。適切なリソースのみが確実に更新または削除されるようにするために、インポート・サマリーを必ず確認してください。

インポートする構成JARファイルには、元のプロジェクトのユーザー、グループ、ロールおよび証明書が含まれていません。これらが元のプロジェクトに存在する場合は、エクスポートした構成をインポートするときに再作成してください。プロジェクトをインポートすることで、操作設定も更新できます。

インポートする構成JARファイルがパスフレーズ付きでエクスポートされている場合は、リソースに含まれるすべての認証情報が暗号化されていることを意味し、そのJARファイルのインポート時には同じパスフレーズの指定が必要になります。パスフレーズを知らない場合でも、暗号化されていないリソースはインポートできます。構成JARファイルをインポートするときには、インポートしたリソースの環境値を設定する構成ファイルをインポートするオプションも選択できます。詳細は、「環境値と操作設定を更新するための構成ファイルの使用」を参照してください。

次の図は「リソースのインポート」ページを示しています。

図10-2 「リソースのインポート」ページ

Oracle Service Busのリソースをインポートするには:

1. Fusion Middleware Controlのターゲット・ナビゲータで、「SOA」を開き、リソースのインポート先になるService Busサーバーを開きます。

2. 次のいずれかを行います。

- ドメイン・レベルでプロジェクトをインポートするには、Service Busサーバーの名前を右クリックし、「インポート」を選択します。

- Service BusリソースをService Busプロジェクトにインポートするには、プロジェクトの名前を右クリックし、「インポート」を選択します。

ヒント:

「Service Bus」または「Service Busプロジェクト」メニューから「インポート」を選択することもできます。

3. 「リソースのインポート」ページで、「Jarソース」フィールドの横にある「参照」をクリックし、インポートするJARファイルまで移動してファイルを選択します。

4. 必要に応じて、「構成ファイル」フィールドの横にある「参照」をクリックし、インポートする構成ファイルまで移動してファイルを選択します。

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

選択したソースに含まれるリソースのリストが、それぞれに対して実行される操作のタイプ(作成、更新または削除)とともに表示されます。

6. リソースのリストを展開し、インポートするリソースのみが選択されていることを確認します。

注意:

削除する必要のある既存のリソースに、リスト内で削除のマークが付いていることを確認してください。これらを削除しない場合、そのチェック・ボックスをクリアします。

7. あるリソースが別のリソースを参照している場合、参照の数が「参照」列に表示されます。数字をクリックすると、参照されるリソースの詳細を確認できます。

8. リソース・レベルのインポートの場合は、「依存関係を含める」を選択すると、すべての依存リソースが自動的にインポートされます。

9. インポートしたソースがパスワードで保護されている場合は、「パスフレーズ」フィールドにパスワードを入力します。

10. インポートされたリソースで保持する詳細設定のいずれかを選択します。

これらの設定の詳細は、オンライン・ヘルプおよび『Oracle Service Busでのサービスの開発』のインポート時のセキュリティ構成の保持に関する項を参照してください。

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

選択したリソースがインポートされ、インポート処理のサマリーが表示されます。

11 Oracle Service Busのアクセス・セキュリティの定義

この章では、Service Busのインバウンド・セキュリティおよび管理セキュリティで使用されるユーザー、グループおよびロールを作成する方法について説明します。インバウンド・トランスポートレベルのセキュリティとメッセージレベルのセキュリティは、ユーザー、グループ、およびロールのデータを使用して、インバウンドのクライアント・リクエストを認証し、アクセス制御ポリシーを適用して、プロキシ・サービスとビジネス・サービスの使用が許可されている認証済ユーザーを判断します。管理セキュリティでは、ユーザー、グループおよびロールのデータを使用して、どの認証ユーザーに対して、Service Busのリソースの作成または変更や、Service Busのパフォーマンスのモニターを許可するかを決定します。

この章の内容は次のとおりです。

- Oracle Service Busのアプリケーション・セキュリティの理解

- エクスポート時のセキュリティ構成

- Oracle Service Bus管理セキュリティの構成

- プロダクション環境でのOracle Service Busのセキュリティ

11.1 Oracle Service Busのアプリケーション・セキュリティの理解

認証と認可のために、Service Busは、Oracle Application Development Framework (ADF)セキュリティを使用します。これは、Oracle Platform Security Services (OPSS)に基づいて構築されています。

OPSSの詳細は、『Oracle Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護』のOracle Platform Security Servicesの概要に関する項を参照してください。ADFセキュリティの詳細は、Oracle Application Development Frameworkの理解のADFセキュリティ・フレームワークに関する項を参照してください。

Service Busコンポーネントのセキュリティを構成し、各ユーザーに特定の権限を付与するために、ユーザー・アカウント、グループ、アプリケーション・ロールおよびポリシーを定義します。プロキシ・サービスの作成などの管理機能にユーザーがアクセスできるようにするには、事前定義済のアクセス権限を持つ、事前定義済のアプリケーション・ロールにユーザーを割り当てます。さらに、ユーザー・グループを作成して、そのグループを事前定義済のロールに割り当てることで、ユーザーのグループに同一のアクセス権を付与することもできます。アプリケーション・ロールのアクセス権は変更できませんが、ユーザーとグループに対して、デフォルトのロールとともに個別のアクセス権を付与することは可能です。

11.1.1 ユーザー

ユーザーは、Service Busで認証できる唯一のエンティティであり、人物またはソフトウェア・エンティティ(Webサービスのクライアントなど)になります。各ユーザーには、セキュリティ・レルム内でユニークなID (名前)を割り当てる必要があります。一般的に、作成するユーザーは次の2つのカテゴリのいずれかに分類されます。

- クライアント・ユーザー。このユーザーは、プロキシ・サービスまたはビジネス・サービスにアクセスできます。多数のクライアント・ユーザーを作成する場合は、ユーザーをセキュリティ・グループに整理することを考慮してください。

- 管理ユーザー。Oracle Service Busコンソールを使用して、プロキシ・サービスやビジネス・サービスなどのService Busリソースを作成、変更します。管理ユーザーは、ランタイム・コンポーネントのモニターと管理に、Fusion Middleware Controlも使用します。
Service Busの管理機能には、ロール・ベースのセキュリティをお薦めします。ユーザーまたはグループに個別のアクセス権を直接付与することもできますが、管理権限はアプリケーション・ロールに割り当てることでのみ付与するようにしてください。

11.1.2 グループ

多数のユーザーの管理を効率化するためには、名前を付けたグループにユーザーを整理することができます。そのようにして、各ユーザーに一度に1つずつアクセス権を付与するかわりに、グループ内のすべてのユーザーに権限またはIDを付与します。カスタムのセキュリティ・グループを作成すると、管理機能(プロキシ・サービスの作成など)へのアクセス権を複数のユーザーに簡単に付与できるようになります。

管理セキュリティを構成する場合の最も簡単なシナリオでは、複数のグループを作成し、各グループにロールを通じて固有の権限のセットを割り当ててから、ユーザーを作成してグループに追加します。グループ内の各ユーザーは、例外なく自動的に対応するロールのメンバーになり、事前定義済のアクセス権をすべて持つようになります。

11.1.3 ロール

Service Busには、デフォルトのロールがいくつか用意されており、それぞれのロールには、特定のアクセス権のセットが含まれています。ユーザーが実行できるタスクは、割り当てられているロールによって決まります。Oracle Service BusコンソールおよびFusion Middleware Controlでは、リソースとサービスを保護するために、ユーザーまたはグループにロールを割り当てることができます。これにより、ユーザー・アクセスは、割り当てるロールで許可されているアクションに限定されます。また、ロールの権限に応じて、特定のロールで使用できるユーザー・インタフェースを制限することもできます。

各ロールで付与される権限の詳細は、「Oracle Service Busでのロール・ベースのアクセス」を参照してください。

ユーザーまたはグループを複数のロールに関連付けることもできます。たとえば、MyCustomersEastとMyCustomersWestという名前の2つのグループを作成します。PrivilegedCustomerという名前のセキュリティ・ロールを作成し、米国の東部標準時の午前8時から午後8時の間にMyCustomersWestグループがこのロールに入り、米国の東部標準時の午後8時から午前8時の間にMyCustomersEastグループがこのロールに入るようにする条件を作成します。次に、プロキシ・サービスのアクセス制御ポリシーを作成して、PrivilegedCustomerロールにサービスへのアクセス権を与えます。所属しているグループがMyCustomersEastであるかMyCustomersWestであるかに応じて、各ユーザーがアクセス権を持つ時間帯が変わることになります。

11.1.3.1 Oracle Service Busのアプリケーション・ロール

Service Busには、8つのデフォルト・アプリケーション・ロールが用意されており、各ロールにより、特定のユーザーのカテゴリに共通する特定のアクセス権のセットが提供されます。次に、これらのロールの一覧と説明を示します。

11.1.3.1.1 MiddlewareAdministrator

MiddlewareAdministratorロールは、管理セキュリティ・ロールで、Service Busのすべてのリソースとサービスへの完全なアクセス権が付与されています。これには、サービス・アカウントおよびサービス・キー・プロバイダに含まれるユーザー名、パスワード、資格証明エイリアスのバインディングの作成、編集、または削除の機能が含まれます。このロールで作成できるユーザー名とパスワードは、アウトバウンド認証のためにサービス・アカウントによってのみ使用されます。Service Busリソースへのアクセスを認可するためには使用されません。

11.1.3.1.2 Developer

Developerロールは、開発環境とテスト環境でのみ使用することを目的としていて、本番環境を対象にしていません。MiddlewareAdministratorと同様に、Developerには、Oracle Service BusコンソールとFusion Middleware ControlのService Bus機能への完全なアクセス権が付与されています。ただし、MiddlewareAdministratorとは異なり、Developerがユーザーやアプリケーション・ロールを追加、編集または削除することや、別のユーザーの所有するセッションを表示することはできません。このロールは、アクティブ化を表示できます。共有開発環境では、Developerは、JDeveloperからサーバーへのパブリッシュを実行できません。そのかわりに、Oracle Service Busコンソールにプロジェクトをエクスポートして、リソースをアクティブ化できます。

11.1.3.1.3 Composer

Composerロールには、Fusion Middleware Controlのモニター機能と管理機能に対する完全なアクセス権が付与されています。ただし、リソースのインポート機能とエクスポート機能へのアクセス権を除きます。このロールには、Oracle Service Busコンソールへの表示専用アクセス権が付与されています。将来のリリースでは、このロールの担当範囲が拡大される予定です。

11.1.3.1.4 Deployer

Deployerロールには、Fusion Middleware ControlとOracle Service Busコンソールのモニター機能と管理機能への完全なアクセス権が付与されています。ただし、セキュリティ・ポリシーの更新機能とリシーケンス・エラーの解決機能へのアクセス権を除きます。このロールが割り当てられたユーザーは、通常、アプリケーションのデプロイとアップグレードを担当します。

11.1.3.1.5 Tester

Testerロールには、Oracle Service Busコンソールのリソースと、Fusion Middleware Controlのモニター機能および管理機能への読取り専用アクセス権が付与されています。このロールには、Oracle Service BusコンソールとFusion Middleware Controlの両方からテスト・コンソールへの完全なアクセス権が付与されています。このロールが割り当てられたユーザーは通常、本番前のシステムに対して、コマンドライン・クライアント、Fusion Middleware Controlおよびカスタム・インタフェースを組み合せた統合テストを実行します。

11.1.3.1.6 MiddlewareOperator

MiddlewareOperatorロールには、特定のモニター・タスクとセッション管理へのアクセス権と、すべてのService Busリソースへの読取りアクセス権が付与されています。さらに、このロールには、アラート・ルールとアラート宛先を作成、表示、編集および削除するためのアクセス権と、操作設定を表示および編集するためのアクセス権が付与されています。このロールには、すべてのセッションの表示、リソースのインポートまたはエクスポート、セキュリティ・ポリシーの変更、またはテスト・コンソールの起動を実行するためのアクセス権はありません。このロールが割り当てられたユーザーは、Service Busリソースに対する日常業務の実行と、操作の継続性の確保を担当します。

11.1.3.1.7 ApplicationOperator

ApplicationOperatorロールには、Oracle Service BusコンソールとFusion Middleware Controlに対する読取り専用アクセス権が付与されています。また、「グループの再配列」タブへの完全なアクセス権が付与されています。アプリケーション・オペレータは、フォルトに関する通知を受信し、適切な対応(フォルトのリカバリ、メッセージのスキップ、またはトランザクションの中止)を実行できます。

11.1.3.1.8 Monitor

Monitorロールは、Oracle Service BusコンソールとFusion Middleware Controlでリソースとサービスをモニターするユーザーに付与します。このロールが割り当てられたユーザーには、すべてのService Busリソースへの読取りアクセス権が付与されていて、サービス・レベル・アグリーメント(SLA)の違反とパイプラインからのアラートのモニターも実行できます。

11.1.3.2 WebLogic Serverのセキュリティ・ロール

Service Busのロールには、Service Busのリソースのみを変更する権限が付与されています。Oracle WebLogic ServerまたはOracle WebLogic Server上の他のリソースを変更する権限は付与されていません。Oracle WebLogic Serverのリソースを変更する許可を付与するには、Oracle WebLogic Serverのセキュリティ・ロールのいずれかにユーザーを追加します。Service Busの各ドメインでは、少なくとも1人のユーザーがAdministratorロールに追加されていることを確認してください。

セキュリティ・ロールの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。

11.1.3.3 旧リリースとの互換性

リリース11gのService Busには、管理権限を付与する4つの事前定義済セキュリティ・ロールが用意されていました。これらのロールは、後方互換性を維持するために、現在のリリースにも用意されています。

- IntegrationAdmin (12cの「Administrator」に類似)

- IntegrationDeployer (12cの「Deployer」に類似)

- IntegrationMonitor (12cの「Monitor」に類似)

- IntegrationOperator (12cの「Operator」に類似)

Service Busには、後方互換性を維持するためのデフォルトのセキュリティ・グループも用意されています。これらのグループは、それぞれ、管理権限が付与されていた従来のセキュリティ・ロールのいずれかに含まれます。表11-1に、従来のグループとそのグループのロールを示します。

表11-1 Oracle Service Bus 11gのグループ

グループ

ロール

IntegrationAdministrators

IntegrationAdmin

IntegrationDeployers

IntegrationDeployer

IntegrationOperators

IntegrationOperator

IntegrationMonitors

IntegrationMonitor

11.1.4 アクセス制御ポリシー

アクセス制御ポリシーは、ユーザー、グループ、またはロールがプロキシ・サービスにアクセスできるようにするための条件を指定します。たとえば、あるプロキシ・サービスへのアクセスを、GoldCustomerロールのユーザーには常時許可して、SilverCustomerロールのユーザーには平日の午後12時以降にのみ許可するというポリシーを作成できます。

すべてのプロキシ・サービスに対して、トランスポート・レベルのポリシーを作成することができます。トランスポート・レベルのポリシーでは、クライアントがプロキシ・サービスとの接続を確立しようとしたときにセキュリティ・チェックが適用されます。トランスポート・レベルのポリシーのリストに入っているユーザーからのリクエストだけが続行を許可されます。

メッセージ・レベルのアクセス制御ポリシーでは、メッセージ・レベル・セキュリティを持つプロキシ・サービスをクライアントが呼び出そうとしたときに、セキュリティ・チェックが適用されます。次のような場合はメッセージ・レベルのアクセス制御ポリシーを作成できます。

- Webサービス・セキュリティのアクティブな仲介であるプロキシ・サービスの場合

- メッセージ・レベルのカスタム認証を使用するプロキシ・サービスの場合

メッセージ・レベルのポリシーのリストに入っているユーザーだけが、その操作を呼び出せます。

11.1.5 セキュリティ構成データとセッション

ユーザー、グループおよびロールは、Service Busのセッションでは制御されないセキュリティ・プロバイダに保持されます。そのため、このデータは、WebLogic Service管理コンソールまたはFusion Middleware Controlを使用することでセッションの内外から作成または変更できます。データに対する追加や変更は、即座に有効になり、すべてのセッションで使用できるようになります。データを追加または変更したときのセッションを破棄した場合でも、セキュリティ・データは破棄 されません 。

アクセス制御ポリシーは認可プロバイダに保持されます。また、Service Busリポジトリには、これらへの参照があります。アクセス制御ポリシーは、設計セッションの外部ではなく内部で管理されます。変更がセッション内で行われるため、他のリソースと同じように変更をコミットまたは破棄できます。

一貫した管理には、Service Busセッション外(認可プロバイダMBeansまたはサード・パーティの認可プロバイダ・ツールを使用)でアクセス制御リスト(ACL)を完全に管理するか、Service Busセッション内でACLを完全に管理します。2つの方法を組み合せると、ポリシー表示の一貫性が失われる場合があります。

11.2 エクスポート時のセキュリティ構成

ユーザー、グループ、ロールはセキュリティ・プロバイダ・ストアにあるため、構成をエクスポートするときにこれらのオブジェクトをエクスポートすることはできません。

エクスポートされた構成をインポートする場合や、WebLogic Serverツール(使用できる場合)を使用して構成をエクスポートおよびインポートする場合は、これらのオブジェクトを再度作成する必要があります。

11.3 Oracle Service Bus管理セキュリティの構成

Fusion Middleware Controlを使用すると、ユーザーおよびグループを作成および変更し、それらのユーザーまたはグループにロールを割り当てることができます。

複数のユーザーに同一の権限を付与する場合は、個別のユーザーにロールを直接割り当てるか、カスタムのグループにユーザーを割り当てます。ユーザーおよびグループ・データに対する変更内容は即座に反映され、すべてのセッションで利用できるようになります。

また、WebLogic Server管理コンソールを使用して、ユーザーとグループを作成し、ユーザーをグループに追加することもできます。ただし、アプリケーション・ロールはFusion Middleware Controlを使用して割り当てます。このドキュメントでは、Fusion Middleware Controlを使用する場合について説明します。WebLogic Server管理コンソールのセキュリティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザーとグループの管理に関する項を参照してください。

11.3.1 個別のユーザーに権限を付与する方法

個別のユーザーに権限を付与するには:

1. Administratorアプリケーション・ロールに属するユーザー・アカウントで、Fusion Middleware Controlにログインします。

2. ユーザーを作成し、そのユーザーをMonitorsグループに追加します。「Oracle Service Busユーザーの作成」および「ユーザーをグループに割り当ててアクセス権を付与する方法」を参照してください。

3. 新しいユーザーを1つ以上のアプリケーション・ロールに割り当てます。「個別のユーザーへの権限の付与」を参照してください。

4. 必要に応じて、個別の権限をユーザーに付与します(非推奨)。「個別のユーザーへの権限の付与」を参照してください。

11.3.2 ユーザー・グループ内のユーザーに権限を付与する方法

ユーザー・グループ内のユーザーに権限を付与するには:

1. Administratorアプリケーション・ロールに属するユーザー・アカウントで、Fusion Middleware Controlにログインします。

2. Service Busユーザーの割当て先にできるグループを作成し、そのグループをMonitors親グループのメンバーにします。「Oracle Service Busのグループの作成」を参照してください。

3. ユーザーを作成して、そのユーザーを適切なグループに追加します。「Oracle Service Busユーザーの作成」および「ユーザーをグループに割り当ててアクセス権を付与する方法」を参照してください。

4. 新しいグループを1つ以上のアプリケーション・ロールに割り当てます。「グループへの権限の付与」を参照してください。

5. 必要に応じて、個別の権限をグループに付与します(非推奨)。「グループへの権限の付与」を参照してください。

11.3.3 Oracle Service Busのグループの作成

Service Busのグループは、Fusion Middleware Controlを使用して作成します。すべてのService Busのグループは、Monitors親グループに追加する必要があります。

注意:

グループ名の大文字と小文字は区別されませんが、一意の名前にする必要があります。ユーザー名には、「< > \ , = / ( ) + ? [ ]」のいずれの文字も使用できません。

ユーザー名の最初の文字に、ポンド記号(#)または二重引用符(")を使用してはいけません。これらの無効な文字を含むユーザーを作成すると、WebLogicドメインが破損する場合があります。

Service Busのグループを作成するには:

1. 管理者権限のあるユーザー・アカウントで、Fusion Middleware Controlにログインします。

2. ターゲットのナビゲータで、「WebLogicドメイン」を開き、ドメインの名前を右クリックします。

3. 「セキュリティ」をポイントして、「ユーザーとグループ」を選択します。「グループ」タブをクリックします。

4. 「グループ」表の上側で、「作成」をクリックします。

5. 「新規グループの作成」ダイアログの「名前」フィールドに、グループの名前を入力します。

6. 必要に応じて、「説明」フィールドに、グループの識別に役立つ簡単な説明を入力します。

7. 「プロバイダ」ドロップダウン・リストで、そのグループの認証プロバイダを選択します。

8. 「作成」をクリックします。

「グループ」表に、グループの名前が表示されます。

9. 「グループ」表で、今回追加したグループの名前をクリックして、「メンバーシップ」タブをクリックします。

10. 使用可能な親グループ・リストで、Monitorsを選択し、右矢印をクリックして「選択済」リストに追加します。

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

12. アプリケーション・ロールをグループに割り当てる場合は、「グループへの権限の付与」に進みます。

11.3.4 グループへの権限の付与

グループの作成が完了すると、Fusion Middleware Controlを使用してグループをアプリケーション・ロールに割り当てることで、グループのユーザーに付与するService Busの権限を定義できます。グループをロールに割り当てることで一括して権限を付与することも、権限を個別にグループに付与することもできます。

11.3.4.1 アプリケーション・ロールへのグループの割当て

アプリケーション・ロールにグループを割り当てるには:

1. 管理者権限を持つユーザーとして、Fusion Middleware Controlにログインします。

2. ターゲットのナビゲータで、「SOA」を開き、「service-bus」をクリックします。

3. 「Service Bus」メニューで、「セキュリティ」→「アプリケーション・ロール」を選択します。

4. 「アプリケーション・ロール」ページの「アプリケーション・ストライプ」フィールドで、Service_Bus_Consoleを選択します。

5. 「検索」アイコン(青色の矢印)をクリックして、Service Busのアプリケーション・ロールを表示します。

6. ロールの表で、グループに割り当てるロールを選択し、「編集」をクリックします。
各ロールで付与される権限の詳細は、「アプリケーション・セキュリティ・ロール」を参照してください。

7. 「アプリケーション・ロールの編集」ページに示される「メンバー」表の上部で、「追加」をクリックします。

8. 「プリンシパルの追加」ダイアログで、次の操作を実行します。

a. 「タイプ」フィールドで、「グループ」を選択します。

b. 必要に応じて、グループのプリンシパルまたは表示名の全体または一部を入力します。検索文字列には、名前の冒頭部分または名前の一部を指定できます。

c. 「検索」をクリックします。

d. 検索結果のリストで、ロールを割り当てるグループの名前をクリックして、「OK」をクリックします。

e. 「アプリケーション・ロールの編集」ページで、「OK」をクリックします。

11.3.4.2 グループへの個別の権限の付与

権限はグループに個別に付与できますが、この方法はお薦めしません。可能であれば、「アプリケーション・ロールへのグループの割当て」の説明に従って、グループをロールに割り当てることで権限を付与します。

個別の権限をグループに付与するには:

1. 管理者権限を持つユーザーとして、Fusion Middleware Controlにログインします。

2. ターゲットのナビゲータで、「SOA」を開き、「service-bus」をクリックします。

3. 「Service Bus」メニューで、「セキュリティ」→「アプリケーション・ポリシー」を選択します。

4. 「アプリケーション・ポリシー」ページの「アプリケーション・ストライプ」フィールドで、Service_Bus_Consoleを選択します。
「作成」ボタンが有効になります。

5. 表の上にある「作成」をクリックします。

6. 「アプリケーション権限の作成」ページの「権限受領者」セクションで、「追加」をクリックします。

7. 「プリンシパルの追加」ダイアログで、次の操作を実行します。

a. 「タイプ」フィールドで、「グループ」を選択します。

b. 必要に応じて、グループのプリンシパルまたは表示名の全体または一部を入力します。検索文字列には、名前の冒頭部分または名前の一部を指定できます。

c. 「検索」をクリックします。

d. 検索結果のリストで、ロールに割り当てるグループの名前をクリックして、「OK」をクリックします。

8. 「アプリケーション権限の作成」ウィンドウの「権限」セクションで、「追加」をクリックします。

9. 「権限の追加」ダイアログで、次の操作を実行します。

a. Javaクラス単位で検索するには、「権限」を選択し、「権限クラス」フィールドでoracle.soa.osb.console.common.permissions.OSBPermissionを選択します。

b. リソース単位で検索するには、「リソース・タイプ」を選択し、「リソース・タイプ」フィールドでOSBPermissionを選択します。

c. 必要に応じて、リソース名の全体または一部を入力します。

d. 「検索」をクリックします。

e. 検索結果のリストで、付与する権限の名前をクリックして、「続行」をクリックします。
Service Bus権限の詳細は、「アプリケーション・セキュリティ・ロール」を参照してください。

f. 「権限アクション」フィールドでは、権限付与するアクションのみを選択します。Javaクラス単位で検索した場合は、カンマ区切りリストで権限アクションを入力します。たとえば、create,delete,editと入力します。
選択可能な権限は、前のページでの選択内容に応じて異なります。

g. 「選択」をクリックします。
新しい権限が「権限」表に表示されます。

10. 権限の付与が完了したら、「アプリケーション権限の作成」ウィンドウの「OK」をクリックします。

11.3.5 Oracle Service Busユーザーの作成

Service Busのグループは、Fusion Middleware Controlを使用して作成します。すべてのService Busユーザーは、Monitors親グループ、またはMonitors親グループのメンバーであるグループに追加する必要があります。

注意:

ユーザー名には、「; , + = \」のいずれの文字も使用してはいけません(二重のバックスラッシュは、smith\\のように使用できます)。ユーザー名の最初の文字に、ポンド記号(#)または二重引用符(")を使用してはいけません。これらの無効な文字を含むユーザーを作成すると、WebLogicドメインが破損する場合があります。

Service Busユーザーを作成するには:

1. 管理者権限を持つユーザーとして、Fusion Middleware Controlにログインします。

2. ターゲットのナビゲータで、「WebLogicドメイン」を開き、ドメインの名前を右クリックします。

3. 「セキュリティ」をポイントして、「ユーザーとグループ」を選択します。「ユーザー」タブをクリックします。

4. 「ユーザー」表の上側で、「作成」をクリックします。

5. 「新規ユーザーの作成」ダイアログの「名前」フィールドに、ユーザーのログインIDを入力します。

6. 必要に応じて、「説明」フィールドに、ユーザーの識別に役立つ簡単な説明を入力します。

7. 「プロバイダ」ドロップダウン・リストで、ユーザーの認証プロバイダを選択します。

8. 「パスワード」フィールドに、ユーザーのパスワードを入力します。パスワードは、8文字以上にする必要があります。

9. ユーザーのパスワードを「パスワードの確認」フィールドに再入力します。

10. 「作成」をクリックして、変更内容を保存します。

「ユーザー」表に、ユーザー名が表示されます。

11. 次のいずれかを行います。

- ユーザーをグループに割り当ててユーザーにアクセス権を付与する場合は、「ユーザーをグループに割り当ててアクセス権を付与する方法」に進みます。

- 個別のユーザーにアクセス権を付与する場合は、「個別のユーザーへの権限の付与」を参照してください。

11.3.6 ユーザーをグループに割り当ててアクセス権を付与する方法

同一の権限を多数のユーザーに割り当てるためにグループを使用する場合は、ユーザーを適切なグループに追加して権限を付与します。このグループは、すでにMonitorsグループのメンバーであるため、これらのユーザーがMonitorsグループのメンバーである必要はありません。

Service Busユーザーをグループに追加するには:

1. 管理者権限を持つユーザーとして、Fusion Middleware Controlにログインします。

2. ターゲットのナビゲータで、「WebLogicドメイン」を開き、ドメインの名前を右クリックします。

3. 「セキュリティ」をポイントして、「ユーザーとグループ」を選択します。「ユーザー」タブをクリックします。

4. 「ユーザー」表で、今回追加したユーザーの名前をクリックして、「グループ」タブをクリックします。

5. ユーザーを追加するグループを選択し、右矢印をクリックして「選択済」リストに追加します。

6. グループの追加が完了したら、「保存」をクリックします。

11.3.7 個別のユーザーへの権限の付与

WebLogic Server管理コンソールでユーザーを作成したら、そのユーザーをFusion Middleware Controlでアプリケーション・ロールに割り当ててアクセス権を付与します。権限は個別に付与できますが、この方法はお薦めしません。

11.3.7.1 アプリケーション・ロールへのユーザーの割当て

ユーザーをアプリケーション・ロールに割り当てるには:

1. 管理者権限を持つユーザーとして、Fusion Middleware Controlにログインします。

2. ユーザーをMonitorsグループに割り当てます(「ユーザーをグループに割り当ててアクセス権を付与する方法」を参照)。

3. ターゲットのナビゲータで、「SOA」を開き、「service-bus」をクリックします。

4. 「Service Bus」メニューで、「セキュリティ」→「アプリケーション・ロール」を選択します。

5. 「アプリケーション・ロール」ページの「アプリケーション・ストライプ」フィールドで、Service_Bus_Consoleを選択します。

6. 「検索」アイコン(青色の矢印)をクリックして、Service Busのアプリケーション・ロールを表示します。

7. ロールの表で、ユーザーを追加するロールを選択し、「編集」をクリックします。
各ロールで付与される権限の詳細は、「アプリケーション・セキュリティ・ロール」を参照してください。

8. 「アプリケーション・ロールの編集」ページに示される「メンバー」表の上部で、「追加」をクリックします。

9. 「プリンシパルの追加」ダイアログで、次の操作を実行します。

a. 「タイプ」フィールドで、「ユーザー」を選択します。

b. 必要に応じて、ユーザーのプリンシパルおよび表示名の全体または一部を入力します。検索文字列には、名前の冒頭部分または名前の一部を指定できます。

c. 「検索」をクリックします。

d. 検索結果のリストで、ロールに割り当てるユーザーの名前をクリックして、「OK」をクリックします。

e. 「アプリケーション・ロールの編集」ページで、「OK」をクリックします。

11.3.7.2 ユーザーへの個別の権限の付与

権限はユーザーに個別に付与できますが、この方法はお薦めしません。可能であれば、「アプリケーション・ロールへのユーザーの割当て」の説明に従って、ユーザーをロールに割り当てることで権限を付与します。ロールまたは権限をユーザーに直接割り当てるときには、そのユーザーをMonitorsグループに追加する必要もあります。

ユーザーに個別に権限を付与するには:

1. 管理者権限を持つユーザーとして、Fusion Middleware Controlにログインします。

2. ターゲットのナビゲータで、「SOA」を開き、「service-bus」をクリックします。

3. 「Service Bus」メニューで、「セキュリティ」→「アプリケーション・ポリシー」を選択します。

4. 「アプリケーション・ポリシー」ページの「アプリケーション・ストライプ」フィールドで、Service_Bus_Consoleを選択します。
「作成」ボタンが有効になります。

5. 表の上にある「作成」をクリックします。

6. 「アプリケーション権限の作成」ページの「権限受領者」セクションで、「追加」をクリックします。

7. 「プリンシパルの追加」ダイアログで、次の操作を実行します。

a. 「タイプ」フィールドで、「ユーザー」を選択します。

b. 必要に応じて、ユーザーのプリンシパルまたは表示名の全体または一部を入力します。検索文字列には、名前の冒頭部分または名前の一部を指定できます。

c. 「検索」をクリックします。

d. 検索結果のリストで、権限を付与するユーザーの名前をクリックして、「OK」をクリックします。

8. 「アプリケーション権限の作成」ウィンドウの「権限」セクションで、「追加」をクリックします。

9. 「権限の追加」ダイアログで、次の操作を実行します。

a. Javaクラス単位で検索するには、「権限」を選択し、「権限クラス」フィールドでoracle.soa.osb.console.common.permissions.OSBPermissionを選択します。

b. リソース単位で検索するには、「リソース・タイプ」を選択し、「リソース・タイプ」フィールドでOSBPermissionを選択します。

c. 必要に応じて、リソース名の全体または一部を入力します。

d. 「検索」をクリックします。

e. 検索結果のリストで、付与する権限の名前をクリックして、「続行」をクリックします。
Service Bus権限の詳細は、「アプリケーション・セキュリティ・ロール」を参照してください。

f. 「権限アクション」フィールドでは、権限付与するアクションのみを選択します。Javaクラス単位で検索した場合は、カンマ区切りリストで権限アクションを入力します。たとえば、create,delete,editと入力します。
選択可能な権限は、前のページでの選択内容に応じて異なります。

g. 「選択」をクリックします。
新しい権限が「権限」表に表示されます。

10. 権限の付与が完了したら、「アプリケーション権限の作成」ウィンドウの「OK」をクリックします。

11.4 本番環境でのOracle Service Busのセキュリティ

Service Busインストールを本番用に準備する場合、セキュリティ要件に特に注意する必要があります。これらのガイドラインは、本番環境でService Busを保護するために推奨される戦略です。

- 『Oracle WebLogic Server本番環境の保護』に記載されたガイドラインを読んで、そのガイドラインに従います。

- Service Bus管理者用のユーザー・アカウントを作成し、そのアカウントを自分で作成した1つ以上のグループに割り当てるか、アプリケーション・ロールに個別に割り当てます。

- ファイル・システムで、Service Busの構成データを格納するディレクトリのアクセス制御を構成します。これは、ドメイン・ルートの下のconfigディレクトリになります。次に例を示します。

C:\oracle\user_projects\domains\servicebus_domain\config\osb

- ファイル・システムで、FTP、SFTP、ファイル、および電子メールのトランスポートに使用するディレクトリのアクセス制御を構成します。

- 必要に応じて、Service Busインストールで使用するJMSリソースのアクセス制御を構成します。

11.4.1 Service Bus (SB)リソースのアンデプロイ

Service Busには、Service Busに登録されたリソースを公開する際に使用するリソース・サーブレット(MW_HOME/OSB_ORACLE_HOME/lib/apps/sbresourceWar/sbresource.war)が用意されています。Service Busに登録されるリソースは、次のとおりです。

- WSDL (Service Busのリソースとして登録したWSDLファイル)

- WADL (Service Busのリソースとして登録したWADLファイル)

- スキーマ

- MFL

- WS-Policy

- WSDL (プロキシ・サービスの解決済のポリシーとポート情報を持つ有効なWSDL。プロキシ・サービスがWSDLファイルを使用して作成されている場合に使用可能)。

ただし、このサーブレットは、メタデータへの匿名HTTPアクセスを提供しており、これが、一部の高セキュリティ環境では、セキュリティ・リスクと見なされる場合があります。

HTTPを介して匿名でService Busリソースにアクセスできないようにする場合は、sbresources.warでセキュリティ・ロールを設定して、リソースへのアクセスを制御するか、リソースを完全にアンデプロイしてください。

注意:

SBリソースをアンデプロイすると、UDDIサブシステムを使用できなくなります。

11.4.2 bodyコンテンツをストリーミングする場合の一時ファイルの保護

『Oracle Service Busでのサービスの開発』のメッセージ・コンテキスト・モデルに関する項で説明しているように、メッセージ・コンテンツを処理する場合は、Service Busパイプラインがコンテンツをメモリーにロードするのではなく、ストリーミングするように指定できます。コンテンツ・ストリーミングを有効にするときは、メッセージ処理時の中間手順として、ストリーミングされたコンテンツをメモリーとディスク・ファイルのどちらにバッファ・リングするかを指定します。

一時ディスク・ファイルを使用する場合は、それらを保護する必要があります。Service Busドメインをロック・ダウンするには、Javaシステム・プロパティcom.bea.wli.sb.context.tmpdirを設定して、一時ファイルが書き込まれる場所を指定します。このディレクトリが存在し、適切なアクセス権のセットがあることを確認してください。詳細は、『Oracle WebLogic Server本番環境の保護』のファイルのアクセス権限およびファイル・システムの推奨事項を参照してください。

11.4.3 Oracle Service Busコンソールに対するサービス拒否攻撃からの保護

本番環境では、管理者以外のユーザーはOracle Service Busコンソールにアクセスできない必要があります。サービス拒否攻撃では、1つのソースから大量のリクエストが発信されたり、リソース制約がある点に達するとサーバーへの新しい接続が確立されたりします。Oracle Service Busコンソールに対するサービス拒否攻撃からの保護に関する推奨事項を次に示します。

- 本番環境では、管理サーバー(Oracle Service Busコンソールが稼働するサーバー)は決して公開しないようにします。管理対象サーバーだけを、呼出し元からアクセスできるようにする必要があります。

- Oracle Service Busコンソールのデフォルトのワーク・マネージャを使用するのではなく、別のワーク・マネージャを構成し、Oracle Service BusコンソールのWebアプリケーションにアクセスできるユーザー数のデフォルトの制限値(max-threads-constraint)を設定して使用します。
ワーク・マネージャの詳細は、『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。

第IV部 高度な管理タスクの実行

ここでは、ビジネス・サービスのエンドポイントURIの管理、ビジネス・サービスのメッセージ・フローの制御、トラブルシューティングなど、Service Busの高度な管理タスクについて説明します。

この部は、次の章で構成されています。

- メッセージおよびアラートのレポートの構成

- セキュリティ・ポリシーのモニターと管理

- ビジネス・サービスのエンドポイントURIのモニターおよび管理

- メッセージ・スロットル用にビジネス・サービスを構成する方法

- リシーケンサ表の管理

12 メッセージおよびアラートのレポートの構成

この章では、デフォルトのJMSレポート・プロバイダとFusion Middleware Controlのメッセージ・レポート・モジュールを含め、Oracle Service Busのレポート・フレームワークについて説明します。

この章の構成は、次のとおりです。

- Service Busのレポート・フレームワークについて

- JMSレポート・プロバイダについて

- JMSレポート・プロバイダ・データ・ストア用データベースの構成

- メッセージ・レポートの有効化

- メッセージ・レポートの操作

- レポート・プロバイダの停止

- レポート・プロバイダの起動

- JMSレポート・プロバイダの割当て解除

- Oracle Advanced Queueing JMSの使用

12.1 Service Busのレポート・フレームワークについて

Service Busには、メッセージまたはアラート用に1つ以上のレポート・プロバイダを作成するための拡張可能なフレームワークが含まれています。メッセージおよびアラートのレポートを生成するパイプラインを構成すると、そのレポートをレポート・ストリームにエクスポートできるようになります。

メッセージ・データは、メッセージ$bodyおよびメッセージに関連付けられた他の変数($header変数や$inbound変数など)から取り込むことができます。アラート・データには、パイプラインをモニターするために構成できるサービス・レベル・アグリーメント(SLA)違反に関する情報が含まれます。レポート・プロバイダに配信されるメッセージまたはアラート・データは、メッセージのトラッキングや規定の監査などの機能に使用できます。

12.1.1 メッセージ・レポートの構成

メッセージ・レポートを有効化するには、まず、パイプラインにレポート・アクションを作成しておく必要があります。レポート・アクションを使用すると、各メッセージから情報を抽出して、その情報をService Busのレポート・データ・ストリームに書き込みできるようになります。アラート・レポートのレポート・アクションを構成する必要はありません。アラート・データは常にレポート・データ・ストリームで使用可能です。詳細は、「パイプライン・レポート・アクションについて」を参照してください。

12.1.2 デフォルトのレポート・プロバイダ

Service Busには、メッセージ・レポート用にJMSレポート・プロバイダが組み込まれています。Fusion Middleware Controlの「メッセージ・レポート」ページには、このレポート・プロバイダから取り込んだ情報が表示されます。組込みのJMSレポート・プロバイダを使用しない場合は、このプロバイダを割当て解除して、レポート・サービス・プロバイダ・インタフェース(SPI)を使用して独自のレポート・プロバイダを作成できます。メッセージ用に独自のレポート・プロバイダを構成すると、Fusion Middleware Controlに情報が表示されなくなります。したがって、独自のユーザー・インタフェースを作成する必要があります。SLAアラート・データを取り込むには、アラート用のレポート・プロバイダを作成する必要があります。

12.1.3 カスタム・レポート・プロバイダ

独自のレポート・プロバイダの作成に必要な情報は、Oracle Service Bus Java APIリファレンスのcom.bea.wli.reportingを参照してください。Java APIリファレンスには、パッケージ化する方法、配置場所、デプロイの方法、デプロイメント順序など、レポート・プロバイダの実装に必要なものに関する情報が記載されています。レポート・スキーマ(MessageReporting.xsd)の場所は、OSB_ORACLE_HOME/lib/sb-schemas.jarです。

12.1.4 レポートのワークフロー

図12-1に示すように、レポート・メッセージとアラートの両方がレポート・データ・ストリームにエクスポートされます。レポート・ステージでは、レポート・アクションによって各メッセージから情報が抽出され、MessageReporting.xsdに準拠するメタデータとともにレポート・データ・ストリームに書き込まれます。

同様に、SLAマネージャは、レポート・データ・マネージャAPIを使用して、AlertReporting.xsdに準拠するメタデータとともにアラート・レポート・ストリームに書き込みます。アラートのレポート・プロバイダまたは独自のメッセージ・レポート・プロバイダを開発するには、ReportingDataHandlerインタフェースを実装し、ReportingDataManagerクラスを使用する必要があります。

図12-1 レポート・フレームワーク

ReportingDataHandlerインタフェースは、レポートまたはアラートのデータ・ストリームを処理します。このストリームは、リレーショナル・データベース、ファイル、JMSキューなどで処理したり格納したりできます。使用するストリームに応じて、データ・ストリームを処理する適切なhandleメソッドを実装する必要があります。

- メッセージ・レポート・ストリーム: ランタイムのレポート・アクションは、次の2つのhandleメソッドを使用して、メッセージ・レポート・ストリームに書き込みます。

handle(com.bea.xml.XmlObject metadata, String s)
handle(com.bea.xml.XmlObject metadata, com.bea.xml.XmlObject data)

- アラート・レポート・ストリーム: アラート・マネージャで次のhandleメソッドを使用して、アラート・レポート・ストリームに書き込みます。

handle(com.bea.xml.XmlObject metadata, String data)

ReportingDataManagerは、レポート・プロバイダのレジストリを保持するローカル・サーバー・オブジェクトです。レポート・プロバイダは、ReportingDataHandlerインタフェースを実装します。ReportingDataManagerでは、次の操作を実行できます。

- レポート・データ・ハンドラの追加と削除

- 各種handle操作を使用したレポート・データ・ストリームのエクスポート

12.2 JMSレポート・プロバイダについて

JMSレポート・プロバイダは、パイプラインのレポート・アクションを使用して各メッセージからレポート情報を取り込むプラガブルなアーキテクチャを備えています。

デフォルトのJMSレポート・プロバイダは、Service Busドメインの作成時に自動的に構成されます。クラスタ内のすべてのメッセージは集約され、データベース固有の形式でJMSレポート・プロバイダ・データ・ストアに格納されます。このプロバイダは、JMSレポート・プロバイダ・データ・ストアの情報を表示します。

注意:

デフォルトのService Bus JMSレポート・プロバイダを使用しない場合は、「JMSレポート・プロバイダの割当て解除」の説明に従って、レポート・プロバイダおよびドメイン内の対応するデータ・ソースを割当て解除します。

JMSレポート・プロバイダは、プロデューサとコンシューマで構成されています。これらはスケーラビリティを向上させるために切り離されています。図12-2に示すように、プロデューサはJMSプロデューサであり、MDB(メッセージドリブンBean)がJMSコンシューマとして機能します。

図12-2 JMSレポート・プロバイダ

レポート・ステージには、レポート情報を収集し、ReportingDataManagerの各種のhandle操作を通じてレポート・ストリームをJMSレポート・プロバイダにディスパッチするレポート・アクションが含まれています。JMSReportingDataHandlerは、レポート・プロバイダのJMSプロデューサです。JMSReportingDataHandlerはレポート・ストリームを取得し、情報をJMSキューに記録します。MDBは、JMSレポート・キューをリスニングします。メッセージは非同期に処理され、データはJMSレポート・プロバイダ・データ・ストアに格納されます。

JMSレポート・プロバイダはレポート・アクションによって生成されたレポートを処理しますが、SLAやパイプライン・アラートのため生成されたレポートは無視されます。カスタム・レポート・プロバイダに書き込むとき、その動作に制限されません。ビジネス要件に応じて、レポート・フレームワークによってカスタム・レポート・プロバイダに配信されたレポート・データのすべてまたはサブセットを処理することができます。

12.2.1 パイプライン・レポート・アクションについて

レポート・メッセージをJMSレポート・プロバイダ(Service Busインストールに付属)または独自のカスタム・レポート・プロバイダから受信するには、まず、レポートが必要になるパイプラインにレポート・アクションを作成しておく必要があります。レポート・アクションを使用すると、各メッセージから情報を抽出して、その情報をService Busのレポート・データ・ストリームに書き込みできるようになります。レポート・アクションでは、メッセージから抽出し、データ・ストリームに追加する情報を指定します。

レポート・アクションの構成時に、キー値を使用してメッセージからキー識別子を抽出します(複数のキーを構成できます)。情報は、メッセージの本文からのみでなく、header変数やinbound変数など、メッセージに関連付けられている他のあらゆる変数からも取り込むことができます。

任意のXML要素をキーとして使用できます。たとえば、次に示すメッセージ構造を使用している場合は、識別子を抽出する手段として、item-code要素を使用できます。

<?xml version="1.0" encoding="utf-8"?>
<poIncoming>
<areacode>408</areacode>
<item-quantity>100</item-quantity>
<item-code>ABC</item-code>
<item-description>Medicine</item-description>
</poIncoming>

図12-3は、ItemCodeという名前で、値に.//item-code (XPath式)が定義されたキー値を示しています。キーの値は、メッセージ本文(body変数)のitem-code要素から取得されます。

図12-3 Oracle Service Busコンソールのキー名と値

デフォルトのJMSレポート・プロバイダを使用する場合は、キーおよび関連付けられている値が「メッセージ・レポート」表の「レポート・インデックス」列に表示されます。複数のキーを構成した場合は、キーと値の各ペアがカンマで区切られ、「レポート・インデックス」列に表示されます。

レポート・アクションの作成の詳細は、『Oracle Service Busでのサービスの開発』のレポート・アクションの追加に関する項を参照してください。

12.2.2 グローバル・トランザクションでのレポート・アクション

JMSレポート・プロバイダは、デフォルトのキュー接続ファクトリを使用しますが、これによってグローバル・トランザクションのコンテキストでパイプラインがレポート・アクションを実行できるようになります。jmsResourcesモジュールで定義される接続ファクトリは、wli.reporting.jmsprovider.ConnectionFactoryと呼ばれます。

グローバル・トランザクションのコンテキストでレポート・アクションを実行する必要がない場合は、次の操作をOracle WebLogic Server管理コンソールで実行して、接続ファクトリを変更します。

1. 「サービス」→「メッセージング」→「JMSモジュール」→「jmsResources」を選択します。

2. 「トランザクション」タブを選択します。

3. 「XA接続ファクトリの有効化」オプションの選択を解除します。

この接続ファクトリを使用してレポート・アクションを処理する場合にパイプラインが使用するロジックは次のとおりです。

- グローバル・トランザクションが存在し、かつ、接続ファクトリがXA対応(デフォルト)である場合、レポートはそのグローバル・トランザクションのコンテキスト内で生成されます。

- グローバル・トランザクションが存在し、かつ、接続ファクトリがXA対応でない場合、トランザクションが一時停止され、レポートはローカル・トランザクション内で生成されます。

- グローバル・トランザクションが存在しない場合、レポートはローカル・トランザクション内で生成されます。

12.3 JMSレポート・プロバイダ・データ・ストア用データベースの構成

Service Busには、JMSレポート・プロバイダ・データ・ストア用のデータベースが必要です。Oracle WebLogic ServerとともにインストールされるJava DBデータベースは開発のみを目的としており、本番環境用ではありません。

本番環境では、サポートされているデータベースの1つを使用する必要があります。サポートされているデータベースに関する最新情報については、次の場所にあるOracle Fusion Middlewareのサポートされるシステム構成の、サポート対象のデータベースとドライバを参照してください:

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

注意:

デフォルトのJMSレポート・プロバイダを使用せず、そのためデータベースを構成しない場合は、「JMSレポート・プロバイダの割当て解除」の説明に従って、レポート・プロバイダおよびドメイン内の対応するデータ・ソースを割当て解除します。

12.3.1 トランザクションのレポート・データ・ソースの構成

デフォルトのデータ・ソースwlsbjmsrpDataSourceは、Service Busインストール用に自動的に作成されます。カスタムのJMSレポート・プロバイダ・データ・ソースを作成する場合は、そのデータ・ソースが次のいずれかの方法でトランザクションをサポートしていることを確認してください。構成が不適切であると、例外が発生する場合があります。

- サポートされたXAドライバを使用するように、データ・ソースを構成します。

- データ・ソースに非XAドライバを使用する場合、データ・ソースの構成で次のオプションを選択してください。

- グローバル・トランザクションのサポート

- ロギング・ラスト・リソース
ロギング・ラスト・リソース(LLR)の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』の「ロギング・ラスト・リソース」トランザクション・オプションの理解に関する項を参照してください。

12.3.2 JMSレポート・プロバイダ・ストア用データベースの作成

開発環境では、デフォルトのJMSレポート・プロバイダは、指定されたデータベースの表が存在するかどうかを実行時にチェックします。表が存在しない場合、レポート・プロバイダによって表が作成されます。表が存在する場合は、その表が使用されます。

リポジトリ作成ユーティリティ(RCU)を実行すると、レポート・プロバイダで使用される表を含め、スキーマおよび必要なService Busデータベース表が作成されます。これは製品インストールの一部です。詳細は、Oracle Fusion Middleware構造のインストールと構成のデータベース・スキーマの作成に関する項を参照してください。

12.4 メッセージ・レポートの有効化

メッセージ・レポートを生成するには、レポートするパイプラインにレポート・アクションを作成する必要があります。

「パイプライン・レポート・アクションについて」に説明が記載されています。この手順は、『Oracle Service Busでのサービスの開発』のレポート・アクションの追加に関する項を参照してください。

また、グローバルおよびパイプライン用のレポートの操作設定を両方とも有効にする必要もあります。操作設定の更新手順は、次の項を参照してください。

- グローバル・レベルの操作設定の構成

- 「複数のサービスに対する操作設定の有効化と無効化」または「単一のサービスに対する操作設定の有効化と無効化」

12.5 メッセージ・レポートの操作

Fusion Middleware Controlでは、JMSレポート・プロバイダ・データ・ストアで収集された情報を表示できます。メッセージ・レポート機能を使用すると、レポート、エラー・コード、レポート・インデックスを生成したパイプライン、または日付範囲に基づいて特定のメッセージを検索できます。

検索結果は、抽出された情報と、その他の情報(メッセージがデータベースに書き込まれた時刻やメッセージに関連付けられているサービスなど)を含む表に表示されます。エラー情報など、特定のメッセージに関する詳細情報を表示できます。

メッセージ・データを管理するには、パージ機能を使用します。この機能を使用すると、すべてのメッセージをレポート・データストアからパージすることも、特定の期間内に生成されたメッセージのみをパージすることもできます。JMSレポート・プロバイダ・データ・ストアのホストに使用しているデータベースに対して、標準的なデータベース管理手続きを行ってください。

12.5.1 メッセージ・レポートの検索

メッセージ・レポートを表示するには、レポートの検索を実行する必要があります。すべての検索基準を空白のままにすると、利用可能なすべてのレポートを表示できます。また、指定した期間のメッセージに対して、サービスの名前別、エラー・コード別、およびレポート・インデックス別のフィルタを適用することもできます。このページに示されるフィールドの詳細は、「メッセージ・レポート」ページのオンライン・ヘルプを参照してください。

メッセージ・レポートを検索するには:

1. Fusion Middleware Controlで、次のいずれかの操作を実行します。

- 「Service Bus」または「Service Busプロジェクト」メニューをクリックし、「メッセージ・レポート」を選択します。

- ターゲット・ナビゲータで、Service Busサーバーの名前か、そのサーバーにデプロイしたプロジェクトの名前を右クリックして、「メッセージ・レポート」を選択します。

2. 次に示す基準を検索フィールドに入力します。すべてのメッセージを取得する場合は、検索フィールドを空のままにします。

- インバウンド・サービス名(パイプラインの名前)

- エラー・コード

- レポート・インデックス(キー/値のペア)

これらのフィールドには、アスタリスク(*)のワイルドカード文字を使用できます。

3. 取得するレポートの日付範囲を指定するには、次の操作を実行します。

a. 「自」ラジオ・ボタンを選択します。

b. 「自」フィールドに、日付範囲の開始日を入力します。「日付および時間の選択」アイコンを使用して日付を選択するか、Month DD, YYYY HH:MM:SS AM|PMの書式で日付と時刻を入力します。たとえば、'Nov 29, 2013 12:45:00 AM'と入力します。

c. 「至」フィールドで前述の手順を繰り返して、日付範囲の終了日を定義します。

4. 最近のメッセージを取得するには、次の操作を実行します。

a. 「過去」ラジオ・ボタンを選択します。

b. 「日」フィールドで、何日前までのメッセージ・レポートを取得するかについての日数を選択します。

c. 「時間:分」フィールドで、何時間前までのメッセージを取得するかの時間数と分数を選択します。

5. 「検索」をクリックします。
指定した基準と一致するメッセージ・レポートのリストが、ウィンドウの下部に表示されます。

図12-4 「メッセージ・レポート」ウィンドウ

12.5.2 メッセージ・レポートの詳細の表示

「メッセージの詳細」ページには、選択したレポート・メッセージに関する完全な情報が表示されます。この情報には、レポートを生成したノード、パイプラインおよびステージに加え、タイムスタンプ、サーバー名、インバウンド・サービスとアウトバウンド・サービス、およびレポートに関連するフォルト(ある場合)が含まれます。さらに、パイプラインのレポート・アクションで定義されているレポートについては、そのレポートに書き込まれたテキストを表示することもできます。

メッセージ・レポートの詳細を表示するには:

1. Fusion Middleware Controlで、メッセージ・レポートの検索を実行します(「メッセージ・レポートの検索」を参照)。

2. メッセージの完全なレポートを表示するには、「メッセージ・レポート」表で、そのメッセージの行のレポート・インデックスをクリックします。

「メッセージの詳細」ウィンドウが表示されます。このウィンドウに表示されるフィールドの詳細は、Fusion Middleware Controlのオンライン・ヘルプを参照してください。

図12-5 「メッセージ・レポート」の「メッセージの詳細」ウィンドウ

3. メッセージ・レポートに出力されたテキストを表示するには、このページの「レポート」セクションで「レポート詳細の表示」をクリックします。

次の図は、レポートのメッセージ本文を示しています。

図12-6 メッセージ・レポートのデータ

注意:

レポートの本文テキストを取得するには、パイプラインにレポート・アクションを作成するときに、XQuery式を使用してレポートに書き込む値を指定します。

4. インバウンド・サービスまたはアウトバウンド・サービスのダッシュボードを表示するには、そのサービスの名前をクリックします。

5. 「メッセージの詳細」ページの確認が終了したら、「閉じる」をクリックして「メッセージ・レポート」のサマリー・ページに戻ります。

12.5.3 レポート・データ・ストアからのメッセージ・レポートのパージについて

レポート・データストアからは、すべてのメッセージをパージすることも、指定した期間中に生成されたレポートのみをパージすることもできます。メッセージのパージは非同期プロセスであるため、バックグラウンドでパージが行われているときにも、「メッセージ・レポート」ページでの操作を継続できます。Fusion Middleware Controlには、パージが処理中であることを示すメッセージは表示されませんが、パージの処理中に別のユーザーがパージを開始しようとすると、次のメッセージが表示されます。

A Purge job is already running. Please try later.

パージの完了に要する時間は、パージ・キューにあるメッセージの数によって異なります。パージ・プロセス中にレポート・メッセージを検索すると、メッセージの削除の速度が低下します。また、一部のデータのパージがまだ完了していない場合は、「メッセージ・レポート」ページに不正なデータが表示されることがあります。

12.5.4 レポート・データ・ストアからのメッセージ・レポートのパージ

メッセージのパージは、プロジェクトの設計段階とテスト段階で役立つ機能です。ただし、本番環境では、データベース内のデータの管理(パージを含む)は、データベース管理者がデータベース管理ツールを使用して行うことをお薦めします。

メッセージ・レポートをパージするには:

1. Fusion Middleware Controlで、メッセージ・レポートの検索を実行します(「メッセージ・レポートの検索」を参照)。

2. 「パージ」をクリックします。

「メッセージ・レポート履歴のパージ」ダイアログが表示されます。

3. 次のいずれかを行います。

- すべての日付のメッセージをパージするには、「すべて」を選択します。

- 特定の日付範囲のメッセージをパージするには、「パージ開始」を選択し、「日付および時間の選択」アイコンを使用して、開始日と終了日および時刻を指定します。

注意:

手動で、月、日、年、および時刻を入力することもできます(MM/DD/YY HH:MM:SSの書式で入力します)。たとえば、「10/10/07 12:45:00 AM」と入力します。

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

5. 警告メッセージを読んでから、もう一度「OK」をクリックして先に進みます。

6. 「閉じる」をクリックします。

12.6 レポート・プロバイダの停止

Service Busサーバーの実行中に、レポート・プロバイダを停止するには、これらの手順に従います。

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

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

「デプロイメントのサマリー」ページが表示されます。

3. 「デプロイメント」表で、停止するレポート・プロバイダの横にあるチェック・ボックスを選択します。

4. 「停止」をクリックして、適切な停止コマンドを選択します。

12.7 レポート・プロバイダの起動

Service Busサーバーの実行中に、レポート・プロバイダを起動するには、これらの手順に従います。

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

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

「デプロイメントのサマリー」ページが表示されます。

3. 「デプロイメント」表で、開始するレポート・プロバイダの横にあるチェック・ボックスを選択します。

4. 「起動」をクリックして、適切な起動コマンドを選択します。

12.8 JMSレポート・プロバイダの割当て解除

デフォルトのJMSレポート・プロバイダ(またはカスタム・レポート・プロバイダ)を使用しない場合は、ドメイン内でプロバイダを割当て解除します。

Service Busドメインの作成時に、JMSレポート・プロバイダは、ターゲットとしてデプロイメント・リストに組み込まれます。デフォルトのJMSレポート・プロバイダおよび関連付けられたデータ・ソースを割当て解除すると、サーバー起動時の無害なJMSレポート・エラーを回避できます。

注意:

レポート・プロバイダがなくても、レポート・アクションを定義できます。ただし、データの書込みは行われません。

12.8.1 ドメインの作成時にデフォルトのJMSレポート・プロバイダを割当て解除する方法

ドメインの作成時に、デフォルトのJMSレポート・プロバイダが割り当てられないようにするには:

1. 構成ウィザードの「拡張構成」ページで、「デプロイメントとサービス」および「JMSファイル・ストア」に対してオプション構成を選択します。

2. 「デプロイメント・ターゲット指定」ページが表示されたら、「ターゲット」パネルでService Bus JMSレポート・プロバイダを選択し、左矢印をクリックして「ターゲット」リストから削除します。

3. 「サービス・ターゲット指定」ページが表示されたら、「ターゲット」パネルで「wlsbjmsrpDataSource」を選択し、左矢印をクリックして「ターゲット」リストから削除します。

ウィザードによってドメインが作成されると、サーバーの起動時にどのリソースも割り当てられません。

12.8.2 JMSレポート・プロバイダの割当て解除(サーバーが実行中の場合)

Service Busドメインの実行中に、レポート・プロバイダを割当て解除するには:

1. Oracle WebLogic Server管理コンソールを起動し、ログインします。

2. 「ドメイン構造」パネルで、「デプロイメント」をクリックします。
「デプロイメントのサマリー」ページが表示されます。

3. 「デプロイメント」表で、割当て解除するレポート・プロバイダをクリックします。
プロバイダの「設定」ページが表示されます。

4. 「ターゲット」タブをクリックします。

5. 割当て解除するコンポーネントのチェック・ボックスを選択解除します。

6. 「保存」をクリックします。
設定が正常に更新されたことを示すメッセージが表示されます。

7. レポート・プロバイダを割当て解除した後で、レポート・プロバイダで使用されているデータ・ソースを次のように割当て解除します。

注意:

この手順は、他のコンポーネントとデータ・ソースを共有しないレポート・プロバイダにのみ必要になります。Oracle Service BusのインストールでデフォルトのJMSレポート・プロバイダを割当て解除するには、次の手順を実行する必要があります。

a. 左側のパネルの「ドメイン構造」で、「サービス」→「データ・ソース」を選択します。

b. 「JDBCデータ・ソースの概要」ページで、割当て解除するデータ・ソースの名前をクリックします。
データ・ソースの「設定」ページが表示されます。

c. 「ターゲット」タブをクリックします。

d. 割当て解除するデータ・ソースがあるサーバーのチェック・ボックスを選択解除します。

e. 「保存」をクリックします。
設定が正常に更新されたことを示すメッセージが表示されます。

12.8.3 JMSレポート・プロバイダのターゲット設定解除(サーバーが実行されていない場合)

Service Busドメインが実行されていない場合は、WebLogic Scripting Tool (WLST)を使用してドメインからJMSレポート・プロバイダを削除できます。

レポート・プロバイダを割当て解除するには、次の手順を実行します:

1. まだWLSTを使用するように環境を設定していない場合は、『WebLogic Scripting Toolの理解』の「WebLogic Scripting Toolの使用」、WLSTの使用の主な手順に関する項を参照してください。

2. WLST Offlineを起動します。

C:>java com.bea.plateng.domain.script.jython.WLST_offline

3. 構成ウィザードを使用して作成されたドメインを読み取るには、次のコマンドを実行します。

wls:/offline>readDomain("C:/oracle/user_projects/domains/base_domain")

4. レポート・プロバイダ・データ・ソースを割当て解除するには、次のコマンドを実行します。

wls:/offline/base_domain>unassign("JdbcSystemResource", "wlsbjmsrpDataSource", "Target", "AdminServer")

5. レポート・プロバイダ・アプリケーションを割当て解除するには、次のコマンドを実行します。

wls:/offline/base_domain>unassign("AppDeployment", "JMS Reporting Provider", "Target", "AdminServer")

6. ドメインを更新するには、次のコマンドを実行します。

wls:/offline/base_domain>updateDomain()

7. ドメインを閉じるには、次のコマンドを実行します。

wls:/offline/base_domain>closeDomain()

8. WLSTのコマンド・プロンプトを終了するには、次のコマンドを実行します。

wls:/offline>exit()

注意:

クラスタでは、JMSレポート・プロバイダはクラスタに割り当てられます。したがって、クラスタでメッセージを表示およびパージするには、少なくとも1つの管理対象サーバーを管理サーバーとともに実行するよう構成する必要があります。実行中の管理対象サーバーが存在していないと、レポート・プロバイダは利用できなくなります。

12.9 Oracle Advanced Queueing JMSの使用

デフォルトでは、JMSレポート・プロバイダはデータ・ストアにWebLogic JMSを使用します。クラスタ環境でService Busを実行している場合は、かわりにOracle AQ JMSを使用するようにドメインを構成できます。これにより、レポートとポーラーのトランスポート用JMSプロバイダを変更します。

Oracle AQを使用するようにドメインを構成すると、構成ウィザードは新しいJMSシステム・リソースOSBAQJMSServerを生成します。このリソースは、AQ JMSの外部JMSサーバーに関連付けられています。必須のJMS外部宛先、外部接続ファクトリ、初期コンテキスト・ファクトリ、およびデータソースは、レポート・キュー用とポーラー・トランスポート・キュー用に構成されます。AQ JMS用のJMS外部サーバーは、JMSレポート・データソースwlsbjmsrpDataSourceを使用するように構成されます。このデータソースは、デフォルトのWebLogic JMSが使用するデータソースと同じものです。

注意:

Oracle AQ JMSは、Oracleデータベースを使用したクラスタ環境内のService Busでのみサポートされます。

次の手順は、クラスタ化したService Busドメインを作成するときに、特別に実行する必要がある手順を示しています。ドメイン作成の詳細は、Oracle Service Busのインストールと構成の「Service Busドメインの構成」を参照してください。

Oracle AQ JMSを使用するようにクラスタ・ドメインを構成するには:

1. 構成ウィザードの「拡張構成」ページで、「デプロイメントとサービス」および「管理対象サーバー、クラスタおよびCoherence」に対してオプション構成を選択します。

2. 管理サーバーおよび管理対象サーバーを構成し、クラスタを定義して、それらのサーバーを通常どおりにクラスタに割り当てます。

3. 「サービス・ターゲット指定」ページが表示されたら、次の操作を実行します。

a. Cluster/cluster_name/JMS/JMS System Resourceの下にある「ターゲット」パネルで、「jmsResources」を選択し、左矢印をクリックして「ターゲット」リストから削除します。

b. JMS System Resourceの下の「サービス」パネルで「OSBAQJMSServer」を選択して、「ターゲット」パネルでクラスタの名前を選択し、右矢印をクリックして「ターゲット」リストにサービスを追加します。
これにより、サービスのターゲットをクラスタに設定します。

c. 「サービス」パネルで「OSBAQJMSServer」を再度選択して、「ターゲット」パネルで管理サーバーの名前を選択し、右矢印をクリックして「ターゲット」リストにサービスを追加します。
これにより、サービスのターゲットを管理サーバーに設定します。

4. 通常どおりに、ドメインの構成を継続します。

ドメインの作成が完了したら、JMSリソースとそのリソースに関連付けられた接続ファクトリおよび宛先を、Oracle WebLogic Server管理コンソールの「JMSモジュール」ページで確認してください。

13 セキュリティ・ポリシーのモニターと管理

Fusion Middleware Controlを使用すると、ユーザーのService Busサービスにアタッチされたポリシーを、その使用状況メトリックと違反メトリックも含め、モニターおよび管理できます。また、ポリシー・セットをグローバルに付加し、ポリシーのオーバライドを定義して、ユーザーのサービスに対してポリシーをアタッチおよびデタッチすることもできます。

この章の内容は次のとおりです。

- セキュリティ・ポリシーについて

- グローバル・ポリシーの構成

- セキュリティ・ポリシーのモニター

- セキュリティ・ポリシーの管理

13.1 セキュリティ・ポリシーについて

セキュリティ・ポリシーにより、組織全体で一貫性のあるWebサービスの管理と保護のためのフレームワークが提供されます。Service Busでは、プロキシ・サービスとビジネス・サービスにポリシーをアタッチします。

Service Busプロジェクトに含まれる個別のサービスに対するポリシーは、JDeveloper、Oracle Service BusコンソールおよびFusion Middleware Controlで管理できます。どちらのコンソールも、ランタイム構成をサポートしています。Fusion Middleware Controlを使用する場合は、ポリシー・セットを作成することで、ポリシーをグローバルにアタッチすることもできます。

この章では、Fusion Middleware Controlでポリシーのモニターと管理を実行する方法について説明します。Oracle Service BusコンソールおよびOracle JDeveloperでポリシーを操作する方法の詳細は、『Oracle Service Busでのサービスの開発』の「ビジネス・サービスとプロキシ・サービスの保護」を参照してください。

13.2 グローバル・ポリシーの構成

Fusion Middleware Controlでポリシー・セットを使用すると、Service Busプロジェクトに含まれる複数のサービスにポリシーを割り当てることができます。このようなポリシーは、グローバル・ポリシーと呼ばれます。

グローバル・ポリシー・セットを作成すると、セットに含まれるポリシーは、ポリシー・セットの構成と一致するプロキシ・サービスまたはビジネス・サービスに自動的にアタッチされます。一致するサービスでグローバル・ポリシー・セットのポリシーを使用するには、OWSMポリシーを使用してサービスを構成する必要があります。

ポリシー・セットの構成では、ポリシー・サブジェクトを定義し、ポリシーをアタッチするサービスのドメイン名、アプリケーション名、およびリソース・パス(project_name/folder/subfolder形式)のいずれかを定義します。ポリシーをアタッチできるService Busのサービスは、次のとおりです。

- JCAビジネス・サービス

- JCAプロキシ・サービス

- RESTfulビジネスサービス

- RESTfulプロキシ・サービス

- SOAPビジネス・サービス

- SOAPプロキシ・サービス

グローバル・ポリシー・アタッチメントおよびポリシー・セットの詳細は、『Oracle Web Services Managerの理解』のポリシー・セットを使用したグローバル・ポリシー・アタッチメントに関する項を参照してください。それぞれに対して選択するポリシー・サブジェクトの詳細は、『Oracle Web Services Managerの理解』のポリシー・サブジェクトの理解に関する項を参照してください。

13.2.1 グローバル・ポリシー・セットの作成方法

ポリシー・セットを作成する場合は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のFusion Middleware Controlを使用したポリシー・セットの作成に関する項の手順に従ってください。

13.2.2 グローバル・ポリシーのサービスを有効化する方法

Fusion Middleware Controlでグローバル・ポリシー・セットを有効化および無効化できるようにするだけでなく、ビジネス・サービスおよびプロキシ・サービスでポリシーを使用する、または使用しないように構成することもできます。グローバル・ポリシーを使用するには、ビジネス・サービスまたはプロキシ・サービスでのOWSMポリシー・ストアからのポリシーの使用を有効化する必要があります。これは、JDeveloperまたはOracle Service Busコンソールのいずれかで構成します。詳細は、『Oracle Service Busでのサービスの開発』のJDeveloperでOracle Web Services Managerポリシーをアタッチする方法に関する項とコンソールでOracle Web Services Managerポリシーをアタッチする方法に関する項を参照してください。

グローバル・ポリシーのサービスを有効化するには:

1. 「アプリケーション・ナビゲータ」またはプロジェクト・ナビゲータで、グローバル・ポリシーを有効化するビジネス・サービスまたはプロキシ・サービスを検索します。

2. サービスを右クリックして、「開く」を選択します。

ビジネスまたはプロキシ・サービス定義エディタが表示されます。

3. 次のいずれかを行います。

- JDeveloperの場合は、「ポリシー」タブをクリックします。

- Oracle Service Busコンソールで、「ポリシー」タブをクリックします。

4. 「ポリシー」ページで、使用可能なポリシー・バインディング・モデルのリストから「OWSMポリシー・ストアから」を選択します。

アタッチするポリシーを選択する必要はありませんが、必要に応じてポリシーを個別にアタッチできます。

5. ポリシーの構成が終了したら、「保存」をクリックします。

6. ランタイムの変更をアクティブ化するには、「アクティブ化」をクリックします。

13.2.3 グローバル・ポリシーのサービスを無効化する方法

ビジネス・サービスまたはプロキシ・サービスに有効化されたポリシーがあり、サービスがグローバル・ポリシー・セットの構成と一致する場合、そのセットのポリシーはサービスに自動的に適用されます。これは、サービスのポリシーを無効化することで回避できますが、それはポリシーを個別にアタッチできないということも意味します。これは、JDeveloperまたはOracle Service Busコンソールのいずれかで構成します。詳細は、『Oracle Service Busでのサービスの開発』のJDeveloperでOracle Web Services Managerポリシーをアタッチする方法に関する項とコンソールでOracle Web Services Managerポリシーをアタッチする方法に関する項を参照してください。

グローバル・ポリシーのサービスを無効化するには:

1. 「アプリケーション・ナビゲータ」またはプロジェクト・ナビゲータで、グローバル・ポリシーを無効化するビジネス・サービスまたはプロキシ・サービスを検索します。

2. サービスを右クリックして、「開く」を選択します。

ビジネスまたはプロキシ・サービス定義エディタが表示されます。

3. 次のいずれかを行います。

- JDeveloperの場合は、「ポリシー」タブをクリックします。

- Oracle Service Busコンソールで、「ポリシー」タブをクリックします。

4. 「ポリシー」ページで、使用可能なポリシー・バインディング・モデルのリストから「ポリシーなし」を選択します。

5. ポリシーの構成が終了したら、「保存」をクリックします。

6. ランタイムの変更をアクティブ化するには、「アクティブ化」をクリックします。

13.3 セキュリティ・ポリシーのモニター

Fusion Middleware Controlを使用すると、ドメイン内のサービスで使用されているポリシーは、各プロキシ・サービスまたは各ビジネス・サービスで使用されているポリシーの表示によってモニターできます。

さらに、発生したポリシー違反を表示することも、各ポリシーの使用状況を表示および分析することもできます。

13.3.1 サービスにアタッチされたポリシーの表示

ビジネス・サービスまたはプロキシ・サービスの「ポリシー」ページには、あるサービスに対してグローバルにアタッチされたポリシーと直接アタッチされたポリシーがすべて表示されます。サービスの「ポリシー」ページには、様々な方法でアクセスできます。次に示す手順では、プロジェクトの「サービス・ヘルス」ページからアクセスする方法について説明します。

サービスにアタッチされたポリシーを表示するには:

1. Fusion Middleware Controlで、「SOA」→「service-bus」を開きます。

2. 表示するサービスを含むプロジェクトの名前をクリックします。

プロジェクトの「サービス・ヘルス」ページが表示されます。

3. 「サービス」タブで、表示するポリシーを持つサービスの名前をクリックします。

選択したサービスの「ダッシュボード」が表示されます。

4. 「ポリシー」タブをクリックします。

「ポリシー」ページに、グローバルにアタッチされたポリシーと直接アタッチされたポリシーの両方が一覧表示されます。

図13-1 プロキシ・サービスの「ポリシー」ページ

5. 「直接アタッチされたポリシー」表に有効なポリシーのみを表示するには、表の上にある「有効のみ」をクリックします。

有効なポリシーの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の有効なポリシー・セットの計算方法に関する項を参照してください。

13.3.2 ポリシー使用状況のモニター

サービスで使用しているポリシーを変更する前に、どのサブジェクトが特定のポリシーを使用しているかを確認するために、使用状況分析を実行するようにしてください。データベース・ベースのOWSMリポジトリでは、ポリシー使用状況の情報のみが、有効化されたサービスに対してのみ使用できます。「WSMポリシー」ページには、ポリシーがアタッチされているサブジェクトの数が表示されます。その後で、ポリシーがアタッチされた、選択したタイプのポリシー・サブジェクトのリストを表示できます。

ポリシー使用状況をモニターするには:

1. Fusion Middleware Controlの上部にある「WebLogicドメイン」メニューをクリックし、「Webサービス」をポイントして、「WSMポリシー」を選択します。

「WSMポリシー」ページが表示されます。

2. ポリシーの一覧表示にフィルタを適用するには、名前またはカテゴリを入力するか、保存済の検索を選択します。「検索」をクリックします。

3. 選択したポリシーのアタッチメント列で数字をクリックして、「使用状況分析」ページを表示します。

4. ローカル・ドメイン内のポリシー・サブジェクトのみを表示するには、「表示オプション」フィールドで「ローカル・ドメイン」を選択します。すべてのドメインのポリシー・サブジェクトを表示するには、「エンタープライズ」を選択します。

5. ポリシーがアタッチされている別のポリシー・サブジェクトを表示するには、「サブジェクト・タイプ」メニューからサブジェクト・タイプを選択します。

「サブジェクト・タイプ」メニューには、ポリシーがアタッチされているサブジェクト・タイプごとのアタッチメント数が示されます。

13.3.3 ポリシー違反の表示

サービスの「ポリシー」タブに表示されるポリシーの一覧では、フォルトのあるポリシーに対してポリシー違反の数が示されます。

ポリシー違反をモニターするには:

1. 構成するサービスの「ポリシー」ページにアクセスします(「サービスにアタッチされたポリシーの表示」を参照)。

2. 「直接アタッチされたポリシー」表で、「合計違反」列を調べてフォルトのあるポリシーを特定します。

3. 「違反」列の数字をクリックして、フォルトについての詳細情報を表示します。

13.4 セキュリティ・ポリシーの管理

Fusion Middleware Controlでは、ポリシーのアタッチとデタッチ、ポリシー・プロパティのオーバーライド、およびグローバル・ポリシーの作成を実行することで、セキュリティ・ポリシーを管理できます。

グローバル・ポリシーの詳細は、「グローバル・ポリシーの構成」を参照してください。

13.4.1 サービスへのセキュリティ・ポリシーの直接アタッチ

セキュリティ・ポリシーをサービスにアタッチするには:

1. 構成するサービスの「ポリシー」ページにアクセスします(「サービスにアタッチされたポリシーの表示」を参照)。

2. 「直接アタッチされたポリシー」表の上にある、「アタッチ/デタッチ」をクリックします。

「ポリシーのアタッチ/デタッチ」ウィンドウが表示されます。

図13-2 「ポリシーのアタッチ/デタッチ」ウィンドウ

3. 「使用可能」リストで、アタッチするポリシーを選択して、「アタッチ」をクリックします。

4. この手順を、アタッチするポリシーごとに繰り返します。

5. 「検証」をクリックして、構成を検証します。

6. 「OK」をクリックして、「ポリシーのアタッチ/デタッチ」ウィンドウを閉じます。

新しいポリシーが、「直接アタッチされたポリシー」表に表示されます。

13.4.2 サービスからのポリシーのデタッチ

サービスからポリシーをデタッチするには:

1. 構成するサービスの「ポリシー」ページにアクセスします(「サービスにアタッチされたポリシーの表示」を参照)。

2. 「直接アタッチされたポリシー」表の上にある、「アタッチ/デタッチ」をクリックします。

「ポリシーのアタッチ/デタッチ」ウィンドウが表示されます。

3. 「直接アタッチされたポリシー」リストで、デタッチするポリシーを選択して、「デタッチ」をクリックします。

4. この手順を、デタッチするポリシーごとに繰り返します。

5. 「検証」をクリックして、構成を検証します。

6. 「OK」をクリックして、「ポリシーのアタッチ/デタッチ」ウィンドウを閉じます。

「直接アタッチされたポリシー」表からポリシーが削除されます。

13.4.3 セキュリティ・ポリシーのオーバーライド

サービスに直接アタッチされたポリシーの構成はオーバライドできます。これにより、各サービスまたはクライアント単位で、それらに新しいポリシーを作成することなく、構成を更新できるようになります。この方法では、デフォルト構成の値を定義するポリシーを作成して、それらの値をランタイムの要件に基づいてカスタマイズできます。プロキシ・サービスまたはビジネス・サービスの構成でオーバーライドを定義できます。詳細は、『Oracle Service Busでのサービスの開発』の「ビジネス・サービスとプロキシ・サービスの保護」を参照してください。

Fusion Middleware Controlで、セキュリティ・ポリシーをオーバーライドするには:

1. オーバーライドするポリシーを特定します(「サービスにアタッチされたポリシーの表示」を参照)。

2. 「直接アタッチされたポリシー」表で、オーバーライドを定義するポリシーを選択して、「ポリシー構成のオーバーライド」をクリックします。

「セキュリティ構成の詳細」ダイアログが表示され、オーバーライド可能な値を持つプロパティが一覧表示されます。

3. 「値」列で、プロパティごとにオーバーライド値を入力して、「適用」をクリックします。

14 ビジネス・サービスのエンドポイントURIのモニターおよび管理

この章では、再試行の構成、応答していないエンドポイントのオフラインとしてのマーク、エンドポイントのメトリックの表示、エンドポイントのステータスに基づいたアラートのトリガーを含む、ビジネス・サービスでのエンドポイントURIの管理方法について説明します。

この章の構成は、次のとおりです。

- エンドポイントURIの管理について

- 応答しないエンドポイントURIをオフラインにするService Busの構成

- エンドポイントURIに手動でオフラインのマークを付ける方法

- オフラインのURIにオンラインのマークを付ける方法

- ビジネス・サービスに対するエンドポイントURIのメトリックの表示

- エンドポイントURIのメトリックに基づいたアラートの作成

14.1 エンドポイントURIの管理について

実行時に各エンドポイントURIのメトリックをモニターすることで、それらすべてのエンドポイントが期待したとおりに実行していることを確認できます。

エンドポイントURIに問題が見つかったときには、そのURIをオフラインとしてマークできます。これにより、そのエンドポイントURIに対するアクセスの試行が繰り返されることを避けられます。また、応答しないURIをオフラインとしてマークするように、ビジネス・サービスを構成することもできます。

14.1.1 エンドポイントURIについて

エンドポイントURIとは、ビジネス・サービスがアクセスする外部サービスのURLです。Service Busでは、1つのビジネス・サービスに対して、少なくとも1つのエンドポイントURIを定義する必要があります。1つのビジネス・サービスに対して複数のエンドポイントURIを定義する場合は、ロード・バランシング・アルゴリズムを定義して、ビジネス・サービスがエンドポイントURIへのアクセスを試行する方法を制御します。ビジネス・サービスでは、次のいずれかのロード・バランシング・アルゴリズムを使用できます。

- ラウンド・ロビン

- ランダム

- ランダムな重みベース

- なし

ビジネス・サービスの構成時には、再試行を処理する方法も構成できます。詳細は、『Oracle Service Busでのサービスの開発』のビジネス・サービスのURI再試行についてに関する項を参照してください。

14.1.2 オフラインおよびオンラインのエンドポイントURI

ビジネス・サービスは、応答しないURIにオフラインのマークを付けるように構成できます。これにより、ビジネス・サービスが応答しないURIにアクセスの試行を繰り返さないようにして、応答しないURIにアクセスを試行することで発生する通信エラーを回避します。Service BusでエンドポイントURIに自動的にオフラインのマークが付けられた場合、指定した時間の経過後にService Busでオンラインに戻すことも、手動でステータスを変更するまでService Busでオフラインのままにしておくこともできます。エンドポイントURIのステータスは、Fusion Middleware ControlまたはパブリックAPIを使用して、手動でオンラインまたはオフラインに変更できます。クラスタ・ドメインのエンドポイントURIをオンラインとしてマークすると、すべての管理対象サーバーのエンドポイントURIがオンラインとしてマークされます。

Service Busは、次のいずれかの場合に、自動的にエンドポイントURIにオンラインのマークを付けます。

- ビジネス・サービスにエンドポイントURIを追加する。

- サーバーを再起動する。

- 無効になっているサービスを有効にする。

- サービスの名前を変更するか、サービスを移動する。

- 構成した再試行間隔の期間が経過すると、ビジネス・サービスはuriに正常にアクセスできます。

応答しないURIに自動的にオフラインのマークを付けるビジネス・サービスを構成するときには、この状態を一時的な状態にすることも、永続的な(つまり、手動でステータスを更新するまで続く)状態にすることもできます。

詳細は、「操作設定とグローバル設定の構成」を参照してください。

14.1.2.1 一時的なオフライン・エンドポイントURIについて

ビジネス・サービスが短い時間間隔で自動的に同じエンドポイントを再試行するようにするには、エンドポイントURIを一時的にオフラインとしてマークします。ユーザーが手動でリセットするまで、ビジネス・サービスがエンドポイントURIをオフラインとして処理するようにするには、エンドポイントURIを永続的にオフラインとしてマークします。

一時的なオフラインのマークが付けられている場合、エンドポイントURIのステータスは、通信エラーの発生時にオフラインに変更されます。再試行間隔の期間が経過すると、ビジネス・サービスは新しい要求を処理するために、このエンドポイントURIへのアクセスを試行します。この試行が正常に実行された場合、エンドポイントURIは、再びオンラインとしてマークされます。失敗する場合、URIは再試行間隔の期間中、再びオフラインとしてマークされ、サイクルが繰り返されます。この構成は、通信エラーが一時的なもので、自動的に修復する場合に役立ちます。たとえば、一時的なオーバーロードの場合、通信エラーは発生しますが、エンドポイントは自動的に正常動作に復帰するため、手動で介入する必要はありません。

14.1.2.2 永続的なオフライン・エンドポイントURIについて

永続的なオフラインのマークを付けると、エンドポイントURIのステータスは通信エラーの発生時にオフラインに変化します。このステータスは、そのエンドポイントURIに手動で再度オンラインのマークを付けるまで維持されます。この構成は、手動介入によって解決する必要があるエンドポイントURIの問題に起因する通信エラーが発生した場合に役立ちます。

修正作業を行って手動でURIをオンラインとしてマークするまで、応答しないURIをオフラインにしておく場合は、再試行間隔を設定しません。たとえば、再試行間隔をゼロにすると、エンドポイントが永続的にオフラインになります。

14.1.2.3 クラスタ環境のオフラインURI

管理対象サーバーをホストしているマシンでは、ネットワークの問題に起因する通信エラーが発生する可能性があります。ビジネス・サービスは、このようなイベントについては、(アクセスしているリモート・エンドポイントが応答していても)エンドポイントURIが応答していないと解釈します。エンドポイントURIが応答していないために、通信エラーが発生する場合もあります。

最初のケースでは、URIは、(ネットワークの問題があるマシン上の)1つのサーバーでのみオフラインとしてマークされ、クラスタ内のその他のサーバーではすべてオンラインとしてマークされます。「特定のサーバーで評価する」句に基づくSLAアラート条件ではアラートが生成されますが、「すべてのサーバーで評価する」句に基づくアラート条件ではアラートは生成されません。

2番目のケースでは、URIは、すべての管理対象サーバーでオフラインとしてマークされます(各サーバーがそのエンドポイントへのアクセスを試行するたびに1つずつマークされます)。各管理対象サーバーがエンドポイントURIをオフラインとしてマークするたびに、「特定のサーバーで評価する」に基づくアラート・ルール条件が満たされ、アラートが生成されます。クラスタ・ドメイン内の最後のサーバーのエンドポイントURIをオフラインとしてマークすると、「すべてのサーバーで評価する」に基づくアラート・ルール条件も満たされ、このアラートも生成されます。

クラスタリングされたドメイン用:

- 「サーバー」フィールドが「クラスタ」または管理対象サーバーの1つに設定されている場合、Onlineステータスは、クラスタ全体または選択した管理対象サーバーですべてのエンドポイントURIがオンラインであることを示します。

- 「サーバー」フィールドが「クラスタ」または管理対象サーバーの1つに設定されている場合、Offlineステータスは、クラスタ全体または選択した管理対象サーバーですべてのエンドポイントURIがオフラインであることを示します。

- 「サーバー」フィールドが「クラスタ」に設定されている場合、Partialステータスは、少なくとも1つのサーバー上でビジネス・サービスの1つ以上のエンドポイントURIがオフラインであるか、エンドポイントURIの少なくとも1つがすべてのサーバーでオフラインであるが、同じビジネス・サービスの他のエンドポイントURIが1つまたはすべてのサーバー上で使用できるステータスになっていることを示します。

- 「サーバー」フィールドが管理対象サーバーの1つに設定されている場合、Partialステータスは、選択した管理サーバー上で、ビジネス・サービスのエンドポイントURIの少なくとも1つがオフラインであることを示します。

14.1.3 エンドポイントURIをモニターするためのメトリック

Fusion Middleware Controlには、エンドポイントURIのメトリックが表示されるため、ビジネス・サービスのヘルスをモニターできます。JMXモニタリングAPIを使用して、エンドポイントURIのメトリックを表示することもできます。Fusion Middleware Controlの使用方法の詳細は、「ビジネス・サービスに対するエンドポイントURIのメトリックの表示」を参照してください。JMXモニタリングAPIの使用方法の詳細は、「JMXモニタリングAPI」を参照してください。

Fusion Middleware Controlでは、「Service Busプロジェクト」ページのビジネス・サービスについての「ダッシュボード」タブで、エンドポイントURIのメトリックを利用できます。利用可能なメトリックには、状態、メッセージとエラーの数、およびレスポンス時間があります。次に示す事項では、Fusion Middleware Controlで、エンドポイントURIをモニターするときに予期される動作について説明しています。

- 統計は、ビジネス・サービスのモニターを有効にしている場合にのみ利用できます。

- サービスの名前変更や移動を実行すると、URIレベルの統計がリセットされます。

- 集約間隔を変更すると、URIステータスを除くすべてのURIレベルの統計がリセットされます。

- サービスの統計をリセットすると(または、すべての統計をリセットすると)、URIステータスを除くすべてのURIレベルの統計がリセットされます。

- 既存のビジネス・サービスに新しいURIを追加すると、新しいURIについてのメトリックの収集が自動的に開始されます。

14.1.3.1 エンドポイントURIの状態

Fusion Middleware Controlのビジネス・サービスに対する「ダッシュボード」には、エンドポイントURIがオンラインとオフラインのどちらであるかを示す「状態」統計が表示されます。JMXモニターリングAPIを使用してエンドポイントURIのステータスを取得することもできます。表14-1は、考えられるエンドポイントURIの状態についての説明です。

表14-1 エンドポイントURIのステータス

ステータス

説明

オンライン

特定のサーバーのURIがオンラインであることを示します。クラスタでは、すべてのサーバーのURIがオンラインであることを示します。

オフライン

特定のサーバーのURIがオフラインであることを示します。クラスタでは、すべてのサーバーのURIがオフラインであることを示します。

部分的

クラスタ内の1つ以上のサーバーがそのURIについて問題を報告していることを示します。このメトリックは、クラスタだけに使用できます。

注意:

URIが複数のビジネス・サービスに関連付けられている場合、同じエンドポイントURIのステータスがビジネス・サービスごとに異なる可能性があります。

14.1.3.2 エンドポイントURIのパフォーマンス・メトリック

エンドポイントURIのパフォーマンス・メトリックでは、特定のエンドポイントで処理されたメッセージの数、失敗の数、およびそのレスポンス時間に関する情報が提供されます。エンドポイントURIのヘルスをモニターする場合は、次のメトリックが役立ちます。

- メッセージ数: エンドポイントURIで処理されたメッセージの数。

- エラー数: エンドポイントURIで発生したエラーの数。

- 最小レスポンス時間: このサービスがメッセージの実行に費やした最小時間(ミリ秒単位)。

- 最大レスポンス時間: このサービスがメッセージの実行に費やした最大時間(ミリ秒単位)。

- 平均レスポンス時間: このサービスがメッセージの実行に費やした平均時間(ミリ秒単位)。

14.2 応答しないエンドポイントURIをオフラインにするService Busの構成

応答しないエンドポイントを自動的にオフラインとマークするようにService Busを構成すると、そのエンドポイントURIへの継続的なアクセスの試行を防止できます。

これは、再試行間隔に基づいた一時的な状態にすることもできますが、エンドポイントURIを永続的に(手動でエンドポイントURIをオンラインにするまで)オフラインにすることもできます。これを行うには、ビジネス・サービスの「オフラインのエンドポイントURI」操作設定を有効にする必要があります。ビジネス・サービスのオフラインURI設定は、サービスのすべてのURIに適用されます。

APIを使用して、オフラインのエンドポイントURIをオンラインとしてマークすることもできます。この方法は、ビジネス・サービスのモニターを有効にしていないが、そのエンドポイントURIをオンラインとしてマークする必要がある場合に役立ちます。詳細は、Oracle Service Bus Java APIリファレンスのcom.bea.wli.monitoring.ServiceDomainMBeanを参照してください。

応答しないエンドポイントURIにオフラインのマークを付けるようにService Busを構成するには:

1. Fusion Middleware Controlのターゲット・ナビゲータで、次のいずれかの操作を実行します。

- 「SOA」→service-busの順に開き、変更対象のURIが存在するビジネス・サービスを含んでいるプロジェクトをクリックします。「サービス・ヘルス」タブで、ビジネス・サービスの検索と選択を実行します。

- 「SOA」を開き、service-busを選択して、「操作」タブをクリックします。変更対象のURIが存在するビジネス・サービスの検索と選択を実行します。

選択したビジネス・サービスの「ダッシュボード」が表示されます。

2. 「プロパティ」タブをクリックします。

3. 「一般設定」で、「オフラインのエンドポイントURI」を選択します。

このようにService Busを構成することで、ビジネス・サービスのエンドポイントURIが応答しないときには、そのエンドポイントURIにオフラインのマークが付けられるようになります。

4. 次のいずれかを行います。

- Service BusがエンドポイントURIに一時的なオフラインのマークを付けるようにするには、「時間」、「分」および「秒」のフィールドを使用して再試行間隔を指定します。Service Busは、この時間が経過するまで待機してから、後続のメッセージを処理するために同じエンドポイントURIへのアクセスを試行します。

- Service BusがエンドポイントURIに永続的な(手動で操作するまで続く)オフラインのマークを付けるようにするには、「再試行間隔」に、0時間0分0秒を設定します。

注意:

エンドポイントURIに一時的なオフラインのマークを付けるように構成すると、そのURIは指定した時間間隔が経過するまでオフラインの状態が維持され、その後で再試行されます。エンドポイントが応答すると、URIは再度オンラインになるか、オフラインのままで、処理自体が繰り返されます。

5. ランタイムの変更を保存するには、「適用」をクリックします。

14.3 エンドポイントURIに手動でオフラインのマークを付ける方法

Fusion Middleware Controlでビジネス・サービスをモニターすると、そのビジネス・サービスに関連するエンドポイントURIのメトリックを表示できます。

特定のエンドポイントURIに問題が見つかった場合は、そのエンドポイントURIをオフラインとしてマークできます。これにより、そのURIに対するアクセスの試行が繰り返されないようにします。エンドポイントURIを手動でオフラインにすると、そのURIは手動で元に戻すまでオフラインのままになります。

エンドポイントURIを手動でオフラインとマークするには:

1. Fusion Middleware Controlのターゲット・ナビゲータで、次のいずれかの操作を実行します。

- 「SOA」→service-busの順に開き、変更対象のURIが存在するビジネス・サービスを含んでいるプロジェクトをクリックします。「サービス・ヘルス」タブで、ビジネス・サービスの検索と選択を実行します。

- 「SOA」を開き、service-busを選択して、「操作」タブをクリックします。変更対象のURIが存在するビジネス・サービスの検索と選択を実行します。

選択したビジネス・サービスの「ダッシュボード」が表示されます。

2. 「エンドポイントURI」セクションが表示されるまでスクロール・ダウンします。

3. オフラインとマークするオンラインのエンドポイントURIを選択し、「URI状態の切替え」をクリックします。

URIの「状態」列が「オフライン」に変化します。

14.4 オフラインのURIにオンラインのマークを付ける方法

エンドポイントURIにオフラインのマークが付けられている場合、そのマークがService Busにより自動的に付けられたものでも、管理者により手動で付けられたものでも、エンドポイントURIが応答しなくなったエラーの修正手順を実行した後に、そのエンドポイントURIを手動でオンライン状態に戻せます。

エンドポイントURIに付けたマークをオンラインに戻すと、Service Busはビジネス・サービスのエンドポイントURIの構成に従って処理を継続します。

エンドポイントURIに手動でオンラインのマークを付けるには:

1. Fusion Middleware Controlのターゲット・ナビゲータで、次のいずれかの操作を実行します。

- 「SOA」→service-busの順に開き、変更対象のURIが存在するビジネス・サービスを含んでいるプロジェクトをクリックします。「サービス・ヘルス」タブで、ビジネス・サービスの検索と選択を実行します。

- 「SOA」を開き、service-busを選択して、「操作」タブをクリックします。変更対象のURIが存在するビジネス・サービスの検索と選択を実行します。

選択したビジネス・サービスの「ダッシュボード」が表示されます。

2. 「エンドポイントURI」セクションが表示されるまでスクロール・ダウンします。

3. オフラインとマークするオンラインのエンドポイントURIを選択し、「URI状態の切替え」をクリックします。

URIの「状態」列が「オンライン」に変化します。

4. オフラインのマークが付けられたエンドポイントURIをService Busでオンラインに戻す場合は、「応答しないエンドポイントURIをオフラインにするService Busの構成」の手順を実行してください。

14.5 ビジネス・サービスに対するエンドポイントURIのメトリックの表示

Service Busは、各エンドポイントURIがメッセージを処理している状況についての情報を収集します。メッセージ数、エラー数に加え、最小、最大および平均のレスポンス時間を確認できます。ビジネス・サービスの「ダッシュボード」には、エンドポイントURIがオンラインとオフラインのどちらであるかも表示されます。

ビジネス・サービスのエンドポイントのメトリックを表示するには:

1. Fusion Middleware Controlのターゲット・ナビゲータで、次のいずれかの操作を実行します。

- 「SOA」→service-busの順に開き、変更対象のURIが存在するビジネス・サービスを含んでいるプロジェクトをクリックします。「サービス・ヘルス」タブで、ビジネス・サービスの検索と選択を実行します。

- 「SOA」を開き、service-busを選択して、「操作」タブをクリックします。変更対象のURIが存在するビジネス・サービスの検索と選択を実行します。

選択したビジネス・サービスの「ダッシュボード」が表示されます。

2. 「統計の表示」フィールドで、現在の集約間隔の統計を表示するか、最後のリセット以降の統計を表示するかを選択します。

3. 「エンドポイントURI」セクションが表示されるまでスクロール・ダウンします。

4. 各エンドポイントURIのメトリックを表内で確認します。

表示されるメトリックの詳細は、「エンドポイントURIをモニターするためのメトリック」およびFusion Middleware Controlのオンライン・ヘルプを参照してください。

5. エンドポイントURIのステータスを変更する場合は、「エンドポイントURIに手動でオフラインのマークを付ける方法」または「オフラインのURIにオンラインのマークを付ける方法」を参照してください。

14.6 エンドポイントURIのメトリックに基づいたアラートの作成

エンドポイントURIにアクセスできない場合、アクセスを試行しているビジネス・サービスは通信エラーを受け取ります。

「応答しないエンドポイントURIをオフラインにするService Busの構成」で説明したように、応答しないURIをオフラインにするようにビジネス・サービスを構成することに加え、エンドポイントURIの状態に基づいたビジネス・サービスのSLAアラート・ルールを構成して、応答しないURIをシステムが検出したときにアラートを生成することもできます。

14.6.1 エンドポイントURIの状態に基づいたSLAアラートの作成について

ビジネス・サービスのエンドポイントURIの状態に基づいたSLAアラートを作成すると、特定のエンドポイントURIまたはすべてのエンドポイントURIの状態がオンラインからオフライン(またはオフラインからオンライン)に変化したときにアラートが生成されます。たとえば、1つは「オフラインのすべてのURI = True」条件、もう1つは「オフラインの特定のURI = True」条件に基づいた2つのアラート・ルールが構成されているビジネス・サービスを考えてみます。「オフラインのすべてのURI = True」条件に基づいてアラートが生成されている場合、この状態が解決されるまでこのサービスに対するすべてのリクエストが失敗する可能性が高いため、これは重大な問題を示します。しかし、「オフラインの特定のURI = True」に基づいてアラートが生成されている場合、これは、他のエンドポイントURIが応答するために以降のリクエストが失敗しない可能性があることを示します。

すべてのアラート・ルールは、単独で評価されます。同じビジネス・サービスに対して両方(特定またはすべてのURI)の句に基づくアラートを構成すると、最後のエンドポイントURIをオフラインとしてマークするときに両方のアラートが同時に生成される可能性があります。ビジネス・サービスがURIを1つだけ持つ場合、「オフラインのすべてのURI = True」句と「オフラインの特定のURI = True」句は同じことを意味し、同じように動作します。

オフラインからオンラインへの移行に基づくアラート・ルール条件の評価は、再度オンライン状態としてマークされている特定またはすべてのエンドポイントURIを追跡する場合を除き、同じように動作します。

14.6.2 エンドポイントURIの状態に基づいたSLAアラートの作成

エンドポイントURIの状態に基づいてアラート・ルールを作成できます。

エンドポイントURIの状態に基づいてSLAアラートを作成するには:

1. ビジネス・サービスに対するSLAアラート・ルールを作成します(「SLAアラート・ルールのプロパティの構成」を参照)。

2. 「SLAアラート・ルールの作成」ウィザードの「ルール条件」ページで、「条件の集約間隔」の時間間隔を選択します。

詳細は、「集約間隔」を参照してください。

3. 表にテンプレート行がない場合は、条件ビルダー表の上の「新しい条件の追加」をクリックします。

表に新しい行が表示されます。

4. 最初のフィールドで、「ステータス」を選択します。

5. その次のフィールドで、次のいずれかを選択して、アラートを生成するステータス条件を指定します。

- オフラインのすべてのURI

- オンラインのすべてのURI

- オフラインの特定のURI

- オンラインの特定のURI

6. その次のフィールドには、=演算子が選択されています(選択可能なオプションは、この演算子のみです)。

7. その次のフィールドでは、条件を評価する方法に応じて、「True」または「False」のどちらかを選択します。

8. 最後のフィールドで、次のいずれかを選択します。

- すべてのサーバーで評価する: このオプションでは、すべてのサーバーで条件が満たされた場合に、ルールをTrueと評価します。

- 特定のサーバーで評価する: このオプションでは、いずれかのサーバーが条件を満たした場合に、ルールをTrueと評価します。

9. 行の左側にある「条件の更新」をクリックします。

10. 「作成」をクリックします。

新しいアラート・ルールがサマリー表に表示されます。

注意:

URIの状態が頻繁に変更される場合にトリガーされたアラートを見逃さないように、URIの状態に基づくアラート・ルールの集約間隔を1分に設定することをお薦めします。集約間隔の詳細は、「集約間隔について」を参照してください。

14.6.3 エンドポイントURIの統計に基づいたアラート・ルールの構成

アラート・ルールは、エンドポイントURIのメッセージ数、エラー数またはレスポンス時間に基づいて作成できます。

エンドポイントURIの統計に基づいてアラート・ルール構成するには:

1. ビジネス・サービスに対するSLAアラート・ルールを作成します(「SLAアラート・ルールのプロパティの構成」を参照)。

2. 「SLAアラート・ルールの作成」ウィザードの「ルール条件」ページで、「条件の集約間隔」の時間間隔を選択します。

詳細は、「集約間隔」を参照してください。

3. 表にテンプレート行がない場合は、条件ビルダー表の上の「新しい条件の追加」をクリックします。

表に新しい行が表示されます。

4. 最初のフィールドで、次のいずれかを選択します。

- カウント: 条件がエンドポイントURIのメッセージ数またはエラー数に基づくようにします。

- 最小: 条件がエンドポイントURIの最小レスポンス時間に基づくようにします。

- 最大: 条件がエンドポイントURIの最大レスポンス時間に基づくようにします。

- 平均: 条件がエンドポイントURIの平均レスポンス時間に基づくようにします。

5. その次のフィールドで、作成している条件の対象になるURIを選択します。

6. その次のフィールドで、=、!=、>または<のいずれかの比較演算子を選択します。

7. その次のフィールドに、実際の統計と比較する値を入力します。

8. 行の左側にある「条件の更新」をクリックします。

9. 「作成」をクリックします。

新しいアラート・ルールがサマリー表に表示されます。

15 メッセージ・スロットル用にビジネス・サービスを構成する方法

この章では、Oracle Service Busのスロットを有効化および使用する方法について説明します。スロットルはビジネス・サービスおよびリモート・サーバーへのメッセージ・トラフィックの量を制御し、通信量の多いビジネス・サービスでメッセージのオーバーロードが発生しないようにして、パフォーマンスの向上と安定性を改善する際に役立ちます。

この章の構成は、次のとおりです。

- スロットルについて

- クラスタ内でのスロットル

- スロットルのメトリック

- 1つのビジネス・サービスに対するスロットルの構成

- ビジネス・サービスのグループに対するスロットルの構成

15.1 スロットルについて

ビジネス・サービスへのメッセージ・フローを制御してバックログを回避するため、Service Busアプリケーションでビジネス・サービスに対するメッセージ・スロットルを有効化し、構成できます。

複数のビジネス・サービスから1つのリモート・サーバーへのメッセージのフローを制御する場合は、それらのビジネス・サービスを管理するためのスロットル・グループを作成できます。

15.1.1 スロットルの概念

メッセージ・フローを制御するためにスロットルを使用するときには、スロットル・キューを作成します。ビジネス・サービスが同時実行性の最大値に達した場合や、スロットル・グループが同時実行性の最大値に達した場合には、このキューにメッセージが格納されます。メッセージは優先度が高いものから処理されます。同じ優先度のメッセージが複数ある場合は、先入れ先出し方式で処理されます。優先度の高いメッセージが先に処理されるようにするために、ルーティング・オプションを使用してメッセージに優先度を割り当てます。メッセージの優先度は、優先度の整数が大きいほど高くなります。

スロットル・キューは、インメモリー・キューです。スロットルが適用されるビジネス・サービスまたはサーバーごとのキューは最大で1つです。このキューに置かれているメッセージは、サーバー障害が発生した場合やサーバーを起動した場合に回復できません。スロットル・キューに格納されているメッセージは、キューに格納されている期間がビジネス・サービスまたはスロットル・グループに定義したメッセージの有効期限の値を超えると期限切れメッセージになり、キューから削除されます。ビジネス・サービスの削除または名前変更を行うと、スロットル・キュー内のすべてのメッセージが破棄されます。

15.1.2 スロットルのプロパティ

ビジネス・サービスまたはスロットル・グループのスロットルを有効にするときには、メッセージの許容量に関する情報と、許容量を超えたときにメッセージを保持するために使用するスロットル・キューに関する情報を構成します。スロットル・キューを使用するには、キューの長さを指定する必要があります。スロットル・キューの長さが0 (ゼロ)の場合、定義された容量(最大同時実行性)に達すると、メッセージは破棄されます。キューの長さの超過や有効期限切れが原因でメッセージがキューから破棄または削除されると、スロットル・エンジンがTransportExceptionをパイプラインにスローし、エラー・ハンドラが構成されている場合はトリガーされます。

15.1.2.1 最大同時実行性

最大同時実行性により、ビジネス・サービスまたはスロットル・グループで同時に処理可能なレコードの数が制限されます。このしきい値に達すると、このビジネス・サービスに対するすべての着信メッセージは、ビジネス・サービスがさらにメッセージを受け取れる状態になるまで、スロットル・キューに置かれます。キューがいっぱいの場合、優先度の低いキュー内のメッセージは削除され、新しい着信メッセージがキューに入ります。この設定を実行時に変更すると、新しいメッセージとキュー内にすでに存在するメッセージの両方に影響します。値を大きくすると、Service Busは、キュー内のメッセージの処理後に、より多くのメッセージを処理できるようになります。値を小さくすると、Service Busは、処理するメッセージの数が新しいしきい値を下回るまで、新しいメッセージをすべてスロットル・キューに格納します。

15.1.2.2 スロットル・キューの長さ

スロットル・キューの長さにより、任意の時点でスロットル・キューに保持できるメッセージの数が制限されます。最大同時実行性の制限を超える着信メッセージは、すべてスロットル・キューに配置されます。キューが完全に満たされているときに、優先度の高い新しい着信メッセージがあると、キュー内で最も優先度の低いメッセージが削除されます。この設定の値を実行時に小さくすると、新しい長さを超えるメッセージはすべて破棄されます。

15.1.2.3 メッセージの有効期限(TTL)

メッセージの有効期限の期間(存続時間)により、スロットル・キューにメッセージを保持できる時間が制限されます。時間が経過すると、メッセージはキューから削除されます。このようなメッセージは、期限切れのメッセージと呼ばれます。この設定の値を大きくすると、新しいメッセージとキュー内に既に存在するメッセージの有効期限が延長されます。この設定の値を小さくすると、新しい値を超えたすべてのメッセージは即時に破棄されます。この値はキュー・レベルで設定します。キューに入れられたメッセージの「メッセージの有効期限」の値はすべて同じになります。有効期限を過ぎると、メッセージは処理されずにキューから削除されます。

15.1.3 スロットル・グループ

個別のビジネス・サービスにスロットルを構成すると、参照されるサービスをホストしているサーバーの制限を考慮に入れずに、それらのビジネス・サービスのメッセージ・フローを制御することになります。同一のリモート・サーバーにリクエストを送信するビジネス・サービスが複数存在すると、サーバーの許容量を超過することがあります。スロットル・グループを定義することで、複数のビジネス・サービスから特定のリモート・サーバーに送信されるメッセージのフローを制限できるようになります。

スロットル・グループは、Oracle JDeveloperまたはOracle Service Busコンソールのどちらかで作成できます。スロットル・グループの作成時に、ビジネス・サービスのURLをグループに関連付けます。各URLは、1つのスロットル・グループにのみ関連付けできます。1つのスロットル・グループに含まれるすべてのビジネス・サービスには、メッセージ処理について同一の優先度が割り当てられます。ルーティング・ルールで設定されたメッセージの優先度により、処理の順序が決まります。複数のメッセージに同一の優先度が割り当てられていると、それらのメッセージは先入れ/先出しポリシーで処理されます。

グループのスロットルを有効化する場合は、そのグループに含まれているメッセージ・フローを制限する必要のある各ビジネス・サービスのスロットルも有効にする必要があります。

15.1.4 スロットル・グループのプロパティとビジネス・サービスのスロットルのプロパティ

スロットル・グループに設定するプロパティは、個別のビジネス・サービスに設定するプロパティと同じです。Service Busは、最大同時実行性プロパティを次に示すように決定します。

- スロットル・グループに設定された最大同時実行性が、そのグループ内の各ビジネス・サービスに設定された最大同時実行性の合計よりも大きい場合、Service Busはビジネス・サービスに設定された同時実行性を使用します。

- スロットル・グループに設定された最大同時実行性が、そのグループ内の各ビジネス・サービスに設定された最大同時実行性の合計よりも小さい場合は、スロットル・グループに設定された同時実行性の制限が優先されます。

スロットル・グループに設定されたスロットル・キューの長さとメッセージの有効期限の期間により、そのグループ内の各ビジネス・サービスのデフォルト値を指定します(それらの値が、ビジネス・サービスに定義されていない場合)。これらの値は、スロットル・グループが有効であるか無効であるかとは関係なく、グループから継承されます。Service Busは、スロットル・キューの長さとメッセージの有効期限のプロパティを次に示すように決定します。

- スロットル・グループに関連付けられたビジネス・サービスに対して指定したプロパティ値は、そのスロットル・グループ自体に対して指定した値よりも優先されます。ただし、ビジネス・サービスの値が、そのビジネス・サービスを関連付けたスロットル・グループの値よりも大きい場合、スロットル・グループに設定した値が優先されます。

- ビジネス・サービスにプロパティの値が指定されていない場合、スロットル・グループに定義された値が使用されます。

15.1.5 複数のエンドポイントURIを使用するビジネス・サービスのスロットル

Service Busでは、ビジネス・サービスを複数のエンドポイントURIに関連付けることができます。エンドポイントURIの詳細は、「ビジネス・サービスのエンドポイントURIのモニターおよび管理」を参照してください。ビジネス・サービスを複数のURIに関連付ける際には、個々のURIではなく、そのビジネス・サービスの最大同時実行性を構成します。各URIの最大同時実行性は、全体の最大同時実行性とロード・バランシングの重みにより、次の数式に基づいて内部的に設定されます。

URI-specific max_concurrency = [User configured max_concurrency] X [weight]

たとえば、3つのエンドポイントURI eu1、eu2およびeu3を使用するビジネス・サービスBを考えてみます。ロード・バランシング・アルゴリズムは、ランダムな重みベースであると定義されます。URIの重みは、それぞれ1、2および3です。ビジネス・サービスの最大同時実行性を10と定義したと仮定すると、URI固有の最大同時実行性は、10、20および30です。また、ビジネス・サービスBの有効最大同時実行性は60です。重みが3の最終エンドポイントURIがオフライン状態である場合、このビジネス・サービスの有効最大同時実行性は30です。

注意:

ロード・バランシングがラウンド・ロビンまたはランダムに設定されている場合のURIの重みは1です。また、ロード・バランシングがなしに設定されている場合、プライマリURIの重みは1で、バックアップURIの重みは0です。プライマリURIがオフライン状態になると、バックアップURIの重みは1になります。

スロットルは、ルーティング・オプションでエンドポイントURIがオーバーライドされているメッセージには適用されません。また、セッション固定が有効になっている場合は、メッセージにもスロットルが使用されません。

15.1.6 再試行されたメッセージのスロットル

サービスに対してフェイルオーバーが有効である場合、再試行されたメッセージにはスロットルは適用されません。メッセージは、スロットルの操作設定にかかわらず、その次のURIに送信されます。スロットル・キューが一杯になっているため、またはサービスが最大同時実行性の値に達しているために、期限切れになったり破棄されたメッセージは再試行されません。

15.1.7 スロットルとワーク・マネージャ

エンドポイントのスロットルおよびディスパッチ・ポリシー(ワーク・マネージャ)はどちらも負荷を制限する働きがありますが、処理の異なる領域に作用します。プロキシ・サービスに対して構成されたワーク・マネージャは、そのプロキシ・サービスで実行されるスレッド数を制限します。ビジネス・サービスに対して構成されたワーク・マネージャは、バックエンド・システムからのレスポンスを処理するスレッド数を制限します。ビジネス・サービスに対して構成されたエンドポイントのスロットルは、バックエンド・システムへのリクエストを制限します。ワーク・マネージャとスロットルを組み合せて使用することにより、これら3つの処理ポイントを制御できます。

15.2 クラスタ内でのスロットル

スロットル許容量は、クラスタ全体の設定です。各管理対象サーバーには、独自のサーバー固有の許容量があります。スロットル許容量は、すべての管理対象サーバーに均等に分割されます(稼働していないサーバーがあったとしても)。

クラスタ内の管理対象サーバー間に作業を分割するときには、各サーバーのスロットル許容量(maximum concurrency)が端数処理されます。たとえば、クラスタに3つの管理対象サーバーがあり、許容量が10の場合、その許容量は各サーバーに4ずつ分配されます。スロットルが構成されると、クラスタ内の各管理対象サーバーのスロットル許容量が1以上となります。

15.3 スロットルのメトリック

Service Busは、Oracle Enterprise Managerの「Service Busプロジェクト」ビジネス・サービスについての「ダッシュボード」ページに、スロットルのサービス・メトリックを表示します。

ダッシュボードには、現在の集約間隔および最後の統計のリセット以降の最大スロットル時間、最小スロットル時間および平均スロットル時間が表示されます。詳細は、「サービスのすべてのサービス・ヘルス統計の表示」を参照してください。JMXモニタリングAPIを使用してメトリックにアクセスすることもできます。詳細は、「JMXモニタリングAPI」を参照してください。

15.3.1 スロットルのメトリックを使用したアラートの定義

SLAアラート・ルールは、使用可能なスロットルのメトリックに基づいて定義できます。たとえば、最大スロットル時間が指定の時間を超えたときのアラートを作成できます。詳細は、「サービス・レベル・アグリーメントのアラート・ルールの作成」を参照してください。

15.4 1つのビジネス・サービスに対するスロットルの構成

スロットルの有効化および無効化やスロットル・プロパティの構成は、Fusion Middleware Controlのビジネス・サービスのホーム・ページにある「プロパティ」タブで実行します。

このページで適用した変更内容は、すぐに有効になります。

15.4.1 1つのビジネス・サービスに対するスロットルの構成

ランタイムに対してビジネス・サービスをデプロイまたは有効化していると、そのサービスのスロットルを有効化または無効化したり、スロットル・オプションを構成したりできます。スロットルを有効化すると、エンドポイントに対するメッセージのフローが制限され、メッセージは優先度に応じて処理されるようになります。ルーティング・オプションを使用してメッセージに優先度を割り当てることもできます。優先度を割り当てていないと、メッセージは先入れ先出し方式でデキューされます。

1つのビジネス・サービスのスロットルを構成するには:

1. Fusion Middleware Controlの「ターゲット・ナビゲーション」パネルで、「SOA」→「service-bus」の順に開き、構成するビジネス・サービスが含まれているプロジェクトの名前をクリックします。

「Service Busプロジェクト」ホーム・ページが表示されます。

2. 「操作」タブで、ビジネス・サービスの検索を実行します。

「操作」表に結果が表示されます。

3. ビジネス・サービスの名前をクリックして、そのビジネス・サービスのホーム・ページを表示します。

4. 「プロパティ」ページが隠れている場合は、「プロパティ」タブをクリックします。

5. ビジネス・サービスのスロットルを有効にするには、「スロットルの状態」をクリックします。

6. 次の情報を入力します。

- 最大同時実行性: ビジネス・サービスで同時に処理できるレコードの最大数。この値は0 (ゼロ)にできません。この値は、正の整数にする必要があります。

- スロットル・キュー:スロットル・キュー内のメッセージの最大数。0の値は、スロットル・キューが存在しないことを表します。

- メッセージの有効期限: キューにメッセージを保持できる期限切れになるまでの時間(ミリ秒数)。0の値は、メッセージが期限切れにならないことを表します。

これらのプロパティの詳細は、Fusion Middleware Controlに付属のオンライン・ヘルプを参照してください。ビジネス・サービスがスロットル・グループの一部であれば、これらのフィールドは空白のまま残すことができます。この場合、Service Busではスロットル・グループのプロパティ・セットを使用します。

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

15.4.2 1つのビジネス・サービスに対するスロットルの無効化

ビジネス・サービスに対するメッセージのスロットルが必要なくなった場合には、いつでも、そのサービスに対するスロットルを無効にできます。スロットルを無効にすると、スロットル・キュー内のメッセージは通常どおりに処理されますが、メッセージ・フローはスロットルのパラメータで制限されることはなくなります。

ビジネス・サービスのスロットルを無効にするには

1. Fusion Middleware Controlの「ターゲット・ナビゲーション」パネルで、「SOA」→「service-bus」の順に開き、構成するビジネス・サービスが含まれているプロジェクトの名前をクリックします。

「Service Busプロジェクト」ホーム・ページが表示されます。

2. 「操作」タブで、ビジネス・サービスの検索を実行します。

「操作」表に結果が表示されます。

3. ビジネス・サービスの名前をクリックして、そのビジネス・サービスのホーム・ページを表示します。

4. 「プロパティ」ページが隠れている場合は、「プロパティ」タブをクリックします。

5. 「スロットルの状態」チェック・ボックスの選択を解除します。

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

15.5 ビジネス・サービスのグループに対するスロットルの構成

スロットル・グループは、プロジェクトの開発にどちらを使用したかによって、Oracle JDeveloperまたはOracle Service Busコンソールで作成および構成できます。

スロットル・グループに含まれるビジネス・サービスに対してスロットルを有効にするには、スロットル・グループと、そのグループに含まれる各ビジネス・サービスのスロットルを有効にする必要があります。

15.5.1 スロットル・グループの作成

スロットル・グループを使用して、ビジネス・サービスのグループからリモート・サーバーへのメッセージのフローを制限します。

スロットル・グループを作成するには:

1. 次のいずれかを行います。

- JDeveloperの場合: 「アプリケーション・ナビゲータ」で、新しいサービス・アカウントを含めるプロジェクトまたはフォルダを右クリックし、「新規」をポイントして「スロットル・グループ」を選択します。

- Oracle Service Busコンソールの場合: プロジェクト・ナビゲータで、新しいサービス・アカウントを含めるプロジェクトまたはフォルダを右クリックし、「作成」をポイントして「リソース」を選択します。「リソース・ギャラリ」から、「その他」、「スロットル・グループ」、「OK」の順にクリックします。

2. このスロットル・グループに一意の名前を入力します。また、オプションとして説明を入力します。

3. 「作成」または「終了」をクリックします。

スロットル・グループの定義エディタが表示されます。

4. グループのスロットルを有効にするには、「スロットルの状態」を選択します。

5. 次の情報を入力します。

- 最大同時実行性: グループ内のビジネス・サービスで同時に処理できるレコードの最大数。

- スロットル・キュー:スロットル・キュー内のメッセージの最大数。

- メッセージの有効期限: キューにメッセージを保持できる期限切れになるまでの時間(ミリ秒数)。

これらのプロパティの詳細は、Service Busに付属のオンライン・ヘルプを参照してください。

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

スロットル・グループは、現在のセッションで作成および保存されます。

注意:

Oracle Service Busコンソールでは、セッションを破棄すると、スロットル・グループが破棄されます。新しい情報を有効にするには、セッションをアクティブ化する必要があります。

7. スロットル・グループにビジネス・サービスを追加する場合は、「ビジネス・サービスとスロットル・グループの関連付け」に進みます。

15.5.2 ビジネス・サービスとスロットル・グループの関連付け

スロットル・グループを作成すると、そのグループにビジネス・サービスを関連付けできます。また、すでにグループに関連付けられているビジネス・サービスを削除することもできます。

スロットル・グループにビジネス・サービスを関連付けるには:

1. Oracle JDeveloperまたはOracle Service Busコンソールを起動します。

2. プロジェクト・ナビゲータまたは「アプリケーション・ナビゲータ」で、ビジネス・サービスを関連付けるスロットル・グループをクリックまたはダブルクリックします。

3. 「関連付けられたビジネス・サービス」表の上側で、「編集」または「追加」をクリックします。

ダイアログが表示され、追加するビジネス・サービスが選択できます。

4. Oracle Service Busコンソールを使用している場合は、追加するビジネス・サービスの検索を実行します。基準を省略して検索すると、すべてのビジネス・サービスが返されます。

5. プロジェクトを開いて、スロットル・グループに関連付けるビジネス・サービスを選択します。

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

7. ビジネス・サービスを間違って関連付けた場合は、そのビジネス・サービスを「関連付けられたビジネス・サービス」表から選択して、「削除」をクリックします。

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

サービス・アカウントが現在のセッションで作成および保存されます。

15.5.3 スロットル・グループの編集

スロットル・グループを作成すると、スロットルのプロパティを変更できます。また、グループのメッセージ・フローを制限する必要がなくなった場合は、グループを無効にすることもできます。

スロットル・グループを編集するには:

1. Oracle JDeveloperまたはOracle Service Busコンソールを起動します。

2. 「アプリケーション・ナビゲータ」またはプロジェクト・ナビゲータで、編集するスロットル・グループを含んでいるプロジェクトおよびフォルダを開きます。

3. スロットル・グループの名前を右クリックして、「開く」を選択します。

4. 次の変更を行います。

- グループのスロットルを無効にするには、「スロットル有効」チェック・ボックスの選択を解除します。

- スロットルのプロパティのいずれかを変更します。

- 追加のビジネス・サービスをグループに関連付けるには、「関連付けられたビジネス・サービス」表の上側で「追加」または「編集」をクリックして、新しいサービスを関連付けます(「スロットル・グループの作成」を参照)。

- グループからビジネス・サービスを削除する場合は、そのビジネス・サービスを「関連付けられたビジネス・サービス」表から選択して、「削除」をクリックします。

5. 変更が終了したら、「保存」をクリックします。

6. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックし、セッションを終了して、ランタイムに構成をデプロイします。

15.5.4 スロットル・グループの削除

スロットル・グループを削除すると、その時点で処理されているメッセージと、スロットル・キューに格納されているメッセージが完全に処理されます。関連付けられていたビジネス・サービスについては、Fusion Middleware Controlで、引き続き個別にスロットルを構成できます。グループ内のすべてのビジネス・サービスのスロットルを無効にする場合は、それらを個別に無効にする必要があります(「1つのビジネス・サービスに対するスロットルの無効化」を参照)。

スロットル・グループを削除するには:

1. Oracle JDeveloperまたはOracle Service Busコンソールを起動します。

2. 「アプリケーション・ナビゲータ」またはプロジェクト・ナビゲータで、削除するスロットル・グループを含んでいるプロジェクトおよびフォルダを開きます。

3. スロットル・グループを右クリックして、「削除」を選択します。

4. 確認ダイアログで、「OK」または「はい」をクリックします。

5. Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックし、セッションを終了して、ランタイムに構成をデプロイします。

16 リシーケンサ表の管理

この章では、リシーケンス・データを格納するデータベース表のクリーンアップについて説明します。 Service Busプロジェクトで着信メッセージを並べ替えるためにリシーケンスを使用する場合、メッセージ・ペイロードとメタデータおよびリシーケンス・グループ情報がリシーケンス・データベース表に格納されます。Service Busには、これらの表のサイズの管理と古いレコードのクリーン・アップに役立つスクリプトが用意されています。

この章の内容は次のとおりです。

- リシーケンサ・データベース表について

- Oracle Service Busのリシーケンサ・データのパージ

- サポートされないアクティブなリシーケンサの再構成

16.1 リシーケンサ・データベース表について

リシーケンサは、データベースに依存して、処理するメッセージの格納、グループ化および並べ替えを行います。このデータベースには、リシーケンサのメッセージおよびグループの情報を格納するための表が含まれています。

このデータベースは、ドメインに対してリポジトリ作成ユーティリティ(RCU)を実行すると自動的に作成されます。正常に処理されたメッセージを自動的にパージするようにリシーケンサを構成できますが、それでも、データベース内のリシーケンス・データを手動で管理する必要がある場合があります。Service Busには、リシーケンス・データをパージし、データベースをクリーン・アップするためのSQLパージ・スクリプトが用意されています。

16.1.1 データベース表パージ・スクリプト

Service Busのリシーケンサ・データをパージするスクリプトは、他のSOA Suiteコンポーネント・パージ・スクリプトとともに/MW_HOME/soa/common/sql/soainfra/sql/oracle/122100/soa_purge12にあります。メインのSOA Suiteパージ・スクリプト(すべてのコンポーネントのデータをパージするスクリプト)を実行すると、Service Busのリシーケンス・データもパージされます。リシーケンス・グループのグループ情報は、そのグループの次のシーケンスIDに必要な情報を含むため、削除されません。この情報をパージすると、最初のシーケンスIDからグループを始めることと同じになり、意図に反することになる可能性があります。

SOA Suiteのパージ・プロシージャは、パラレル・モードまたはループ・モードで実行できることに注意してください。Service Busプロシージャはループ・モードでのみ実行できます。

16.1.2 完了リシーケンサ・メッセージの自動パージ

Service Busには、「完了メッセージのパージ」というグローバル設定があり、この設定は正常に処理されたリシーケンス済メッセージを自動的にパージするかどうかを決めます。処理されたメッセージは、次のガイドラインに従って、データベースからパージされます。

- 「完了メッセージのパージ」が選択されている場合のみ、正常に処理されたメッセージがデータベースから自動的に削除されます。この設定は、デフォルトで選択されています。メッセージを自動的にパージしない場合は、この設定のチェック・ボックスを選択解除する必要があります。

- 「完了メッセージのパージ」が選択されている場合、すべてのタイプのリシーケンサで、メッセージ・メタデータが自動的にパージされます。

- 失敗したメッセージがパージされることはありません。

- グループ情報はパージされません。

メッセージとメタデータが自動的にパージされない場合のために、Service Busには、データベース内のリシーケンサ表をパージおよび管理するためのスクリプトが用意されています。

16.1.3 リシーケンスのためのデータソース

リシーケンサは、デフォルトのOracle SOA Suiteデータソースであるjdbc/SOADataSourceを使用して、データベース内のリシーケンス表に接続します。このデータソースは、SOA SuiteまたはService Busをインストールし、WebLogic Serverドメインを作成すると、自動的に作成されます。リシーケンサ・データソースでは、JNDI名はjdbc/SOADataSourceである必要があります。また、リシーケンサ・データソースは、リポジトリ作成ユーティリティ(RCU)によって作成されたsoainfraデータベースに接続します。

16.1.4 パージ・スクリプトおよびリシーケンス済メッセージのパージ・ステータス

パージ・スクリプトには、Service Busのリシーケンサ表(osb_msg、osb_group_statusおよびosb_resequencer_message)に保持されている情報をパージするためのパージ・コマンドが含まれています。パージ・スクリプトを実行すると、次の情報がリシーケンサ表からパージされます。

- すべてのリシーケンサ・タイプの完了したメッセージおよび中断したメッセージ

- 標準のリシーケンサのタイムアウトしたメッセージ

- ベスト・エフォートおよびFIFO(先入れ先出し)のリシーケンサの準備完了状態のグループ(これらのグループのみをパージできます)

フォルト・リカバリおよびメッセージ処理を完了させるため、パージ・スクリプトは、リシーケンス・メッセージ情報をすべてパージするわけではありません。さらに、標準のリシーケンサ・グループには、パージしてはいけない情報が格納されています。パージ・スクリプトを実行しても、次のものはパージされません。

- すべてのリシーケンサ・タイプの失敗したメッセージ

- すべてのリシーケンサ・タイプの実行中のメッセージ

- 標準のリシーケンサのグループ情報

- ベスト・エフォートおよびFIFOのリシーケンサの、準備完了以外の状態のグループ

注意:

パージ・スクリプトは、まずメッセージを削除し、その後グループに移ります。osb_resequencer_message表にグループのメッセージがある場合、そのグループは削除できません。

前述のパージ・スクリプトの処理では、インスタンスのトラッキングが有効であるか無効であるかは関係ありません。シーケンス・グループがパージされる前に、グループに関連付けられているすべてのメッセージが処理されていることを確認するためのチェックが実行されます。

次に、リシーケンサ表で使用されているグループ状態コードのリストを示します。

- 0: 準備完了

- 1: ロック済

- 2: エラー

- 4: タイムアウト

- 6: グループ・エラー

次に、リシーケンサ表で使用されているメッセージ状態コードのリストを示します。

- 0: 準備完了

- 1: ロック済

- 2: 完了

- 3: エラー

- 4: タイムアウト(これは無視されます)

- 5: 中止

16.2 Oracle Service Busのリシーケンサ・データのパージ

全体的なSOA Suiteデータベース管理スクリプトの一部としてService Busのリシーケンサ・パージ・スクリプトを実行することも、Service Busに対してのみスクリプトを実行することもできます。

SOA Suiteデータベースの全体的な戦略の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のデータベース増分の管理に関する項を参照してください。

注意:

SOA Suiteは、Fusion Middleware Controlの自動パージ機能を使用し、データベース表からデータを自動的にパージします。この機能により、Service Busのリシーケンサ表からデータがパージされることはありません。

16.2.1 完了メッセージを自動的にパージするためのリシーケンサの構成

Service Busには、処理が完了したメッセージをリシーケンス・データベース表から自動的に削除するかどうかを指定するグローバル設定があります。これは、グループ情報または失敗、実行中または中断したメッセージをパージするものではなく、正常に処理されたメッセージのみがパージされます。パージされたメッセージを取得することはできません。

完了メッセージを自動的にパージするには:

1. Fusion Middleware Controlで、「SOA」を展開し、「service-bus」を選択します。

2. 「グローバル設定」タブをクリックします。

3. 「リシーケンス」セクションで、「完了メッセージのパージ」を選択します。

これがデフォルト設定であることに注意してください。

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

リシーケンサによって正常に処理されたメッセージは、完了時にパージされます。

16.2.2 SQLスクリプトを使用したリシーケンサ表のパージ

SOA Suiteの全パージ・プロシージャを実行する一環としてService Busリシーケンサ表からデータをパージできます。また、Service Busのリシーケンサ表のみを単独でパージする場合は、Service Busリシーケンサ・プロシージャsoa_osb.deleteOSBResequencerInstancesを実行することもできます。パージ・スクリプトは/MW_HOME/soa/common/sql/soainfra/sql/oracle/122100/soa_purge12にあり、Service Busスクリプトは/osbサブディレクトリにあります。

16.2.2.1 環境とスクリプトの設定

次の手順は、パージ・スクリプトを実行する一般的な手順です。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のSQL*Plusを使用した大量のインスタンスの削除に関する項を参照してください。前述のリンクには、Service Busには適用されないパラレル処理に関する情報が含まれています。

データベースを設定し、パージ・スクリプトをロードするには:

1. スクリプト・ディレクトリ(/MW_HOME/soa/common/sql/soainfra/sql/oracle/122100/soa_purge12)にPurgeLogsという名前のディレクトリを作成します。

診断用に、ログがこのディレクトリ(データベースではSOA_PURGE_DIR)に書き込まれるので、ファイル・システムに作成しておく必要があります。

2. SQLエディタを使用してSYSDBAとしてデータベースに接続します。

3. 次のコマンドを実行して、このスクリプトを実行するユーザーに権限を付与します。

GRANT EXECUTE ON DBMS_LOCK TO USER_NAME;
GRANT CREATE JOB TO USER_NAME;

注意:

パージ・スクリプトの実行には、DEV_MDSユーザーを使用しないでください。エラーが発生することになります。

4. 次のコマンドを実行して、診断ログ・ディレクトリを定義し、前述のユーザーに権限を付与します。

CREATE OR REPLACE DIRECTORY SOA_PURGE_DIR AS 'SCRIPT_LOCATION/PurgeLogs';
GRANT READ, WRITE ON DIRECTORY SOA_PURGE_DIR TO USER_NAME;

5. 前の手順で権限を付与したユーザー名を使用して、SQLエディタでデータベースに接続します。パージ・スクリプトを容易に使用できるように、この操作はパージ・スクリプトがある場所から実行します。

スクリプトは、/MW_HOME/soa/common/sql/soainfra/sql/oracle/122100/soa_purge12にあります。

6. 次のコマンドを使用して、パージ・スクリプトをロードします。

@soa_purge_scripts.sql

「Oracle Service Busのパージ・プロシージャの実行」の説明に従って、データをパージする準備ができました。

16.2.2.2 Oracle Service Busのパージ・プロシージャの実行

次の手順では、Service Busデータのみをパージする方法について説明します。「Service Busのパージ・スクリプトの実行」にはService Busのパージ・スクリプトの実行例がありますが、「SOA Suiteのパージ・スクリプトの実行(ループ・モード)」にはSOA Suite全体に対するプロシージャの実行例があります。SOA Suiteのパージ・プロシージャの使用の詳細および手順は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のSQL*Plusを使用した大量のインスタンスの削除に関する項を参照してください。

Service Busのパージ・プロシージャを実行するには:

1. 「環境とスクリプトの設定」の手順を完了し、その項の手順5と同じユーザー名を使用してSQLエディタでデータベースに接続します。

2. 次のコマンドを実行して、パージ中のデバッグ情報をログに記録します。

@common/debug_on.sql
SET SERVEROUTPUT ON;

3. 次のコマンドを実行して、出力をスプール・ファイルに取得します。

spool '/MW_HOME/soa/common/sql/soainfra/sql/oracle/122100
/soa_purge12/PurgeLogs/spool.log'

4. 次のコマンドを実行して、Service Busのリシーケンサ・データをパージします。

execute soa_osb.deleteOSBResequencerInstances (batch_size,
min_creation_date,max_creation_date);

説明:

- batch_sizeは一度に削除するレコードの最大数です。デフォルト値は20000です。

- min_creation_dateは削除するレコードの最も古い作成日です。

- max_creation_dateは削除するレコードの最も新しい作成日です。

5. 次のコマンドを実行して、スプール・ファイルへの情報の書込みを停止します。

spool off

16.2.2.3 Service Busのパージ・スクリプトの実行

次の例では、2014年1月1日から2014年3月31日までに作成されたリシーケンサ・レコードを、10,000レコードずつパージします。Service Busのレコードのみパージされます。

execute soa_osb.deleteOSBResequencerInstances ( 10000,
to_timestamp('2014-01-01','YYYY-MM-DD'),
to_timestamp('2014-03-31','YYYY-MM-DD'));

16.2.2.4 SOA Suiteのパージ・スクリプトの実行(ループ・モード)

次の例では、作成日が2011年1月1日から2011年1月31日までのService Busリシーケンス・データを含むSOA Suiteデータを、20,000インスタンスずつ、実行時間60分でクリアします(2011年1月31日まで更新されたすべてのインスタンスは保持します)。

execute soa.delete_instances ( to_timestamp('2010-01-01','YYYY-MM-DD'),
to_timestamp('2010-01-31','YYYY-MM-DD'),20000,60,
to_timestamp('2010-01-31','YYYY-MM-DD'),false);

16.3 サポートされないアクティブなリシーケンサの再構成

リシーケンサがアクティブであり、メッセージを処理している間は、リシーケンス構成を変更できません。アクティブなリシーケンサの構成を変更すると、Service Busがリシーケンス済メッセージを自動的にパージするように構成されていてもメッセージとメタデータがデータベースに残るなど、予期しない動作が発生する可能性があります。

たとえば、パイプラインからリシーケンサを削除すると、まだ処理されていないメッセージがデータベースに残ります。メッセージの処理中にリシーケンサ構成を変更すると、メッセージは処理されず、データベースに残ることがあります。アクティブなリシーケンサの使用の詳細は、「デプロイメント・アクティビティがリシーケンスに与える影響」および「サーバーのシャットダウンがリシーケンスに与える影響」を参照してください。

リシーケンスの方式を変更するには:

1. 構成中のコンポーネントのリシーケンサを停止します。

2. この章で説明されているスクリプトを使用して、データベース表をクリーン・アップします。

3. コンポーネントのリシーケンスを再構成します。

4. コンポーネントを再アクティブ化または再デプロイします。

第V部 Oracle Service Busサービスのトラブルシューティング

この部では、実行しているService Busサービスの問題の診断に使用できるツールについて説明します。

この部は、次の章で構成されています。

- 実行トレースを使用した問題の診断

- 診断フレームワークを使用した問題の診断

17 実行トレースを使用した問題の診断

この章では、Fusion Middleware Controlで、Oracle Service Busサービスの実行トレースを有効化して使用する方法について説明します。次の項が含まれます:

- 実行トレースについて

- 実行トレースの有効化および無効化

- 実行トレースの情報へのアクセス

17.1 実行トレースについて

Service Busでは、サーバーをシャットダウンすることなく、メッセージをトレースできます。これは、開発環境と本番環境の両方に役立つ機能です。管理者、エンジニアおよびシステム・エンジニアは、実行トレース機能を使用して、1つまたは複数のパイプラインまたは分割-結合のメッセージ・フローを診断したり、トラブルシューティングすることができます。

たとえば、あるパイプラインが失敗しているときに、どのステージに問題があるかを調べるには、そのパイプラインに対する実行トレースを有効にします。トレースを有効にすると、ステージ名、パイプラインの名前、ルート・ノード名などの様々な詳細情報が、システムによってメッセージ・フローから抽出され、ログに記録されます。ログ・エントリには、ヘッダーとメッセージ本文を含む完全なメッセージ・コンテキストも含まれています。メッセージ・フローでフォルトが発生した場合は、エラー・コードや理由などの詳細もログに記録されます。実行トレースは、ステージ、パイプライン・ペア、ブランチおよびノードを含む、パイプラインの各コンポーネントの最初と最後に行われます。アクションは個別にはトレースされません。

17.2 実行トレースの有効化および無効化

Service Busでは、サーバーをシャットダウンすることなく、メッセージをトレースできます。これにより、メッセージ・フローのトラブルシューティングと診断が簡単になります。

デフォルトでは、実行トレースは無効にされています。実行トレースを有効にすると、パイプライン・コンテキストやメッセージ・コンテキストから選別された各種情報がログに記録されます。これには、ステージ名、パイプラインまたはルート・ノード名および現在のメッセージ・コンテキストが含まれます。

パイプラインまたは分割-結合の実行トレースは、Fusion Middleware Controlでサーバーまたはプロジェクトの「操作」タブか、パイプラインまたは分割-結合の「プロパティ」タブから有効化できます。

17.2.1 Oracle WebLogic Serverのログ・レベルの設定

ログ・ファイルまたは標準出力(サーバー・コンソール)にトレースを表示するには、Oracle WebLogic Serverのロギングを次の重大度に設定する必要があります。

- ログの最低の重大度: 情報

- ログ・ファイル: 情報

- 標準出力: 情報

ログの重大度の設定の詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』のログの重大度の使用に関する項を参照してください。

17.2.2 1つのサービスに対する実行トレースの構成

1つのサービスに対する実行トレースを構成するには:

1. 「操作設定を構成するサービスの検索」の説明に従って、サービスの検索を実行します。

2. 「操作」表で、構成するパイプラインまたは分割-結合をクリックします。

そのサービスの「プロパティ」ページが表示されます。

3. 「実行トレース」の横にある「有効」を選択します。

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

17.2.3 複数のサービスに対する実行トレースの構成

複数のサービスに対する実行トレースを構成するには:

1. 「操作設定を構成するサービスの検索」の説明に従って、サービスの検索を実行します。

2. 結果リストに含まれるパイプラインまたは分割-結合の実行トレースを有効にするには、実行トレース列で、それらのチェック・ボックスを選択します。

3. 結果リストに含まれるパイプラインまたは分割-結合の実行トレースを無効にするには、実行トレース列で、それらのチェック・ボックスを選択解除します。

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

17.3 実行トレースの情報へのアクセス

実行トレース情報は、サーバー・ディレクトリのログに記録されます。

この場所に格納されています。

DOMAIN_HOME/servers/server_name/logs/server_name-diagnostic.log

Oracle WebLogic Server管理コンソールとFusion Middleware Controlでは、ログ・ファイルを直接表示することも、ログのエントリを表示することもできます。

注意:

サーバー・ログの実行トレース・パターンはテスト・コンソールの実行トレースと同じになります。

次の例は、ログ・ファイル内の実行トレース・エントリの例を示しています。

例 - トレース・エントリの例

####<Dec 6, 2013 12:32:35 PM PST> <Info> <oracle.osb.pipeline.kernel.router>
<MyServer> <osb_server1> <[ACTIVE] ExecuteThread: '19' for queue:
'weblogic.kernel.Default (self-tuning)'> <<anonymous>>
<BEA1-7438AA7859AFBEC29BF0> <7f5b2958-8673-4439-87ec-f860ccac436b-0005f450>
<1386361955302> <OSB-382159> <[OSB Tracing] The following variables are changed:
$body = <soapenv:Body xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<cus:Customer xmlns:cus="http://oracle.com/Customer">
<cus:first>Mike</cus:first>
<cus:last>Morse</cus:last>
<cus:company>CompanyA</cus:company>
</cus:Customer>
</soapenv:Body>
$inbound = <con:endpoint name="ProxyService$osb-102-FileHandling$CustomerPoller"
xmlns:con="http://www.bea.com/wli/sb/context">
<con:service/>
<con:transport>
<con:uri>file:///customer/data/input</con:uri>
<con:mode>request</con:mode>
<con:qualityOfService>exactly-once</con:qualityOfService>
<con:request xsi:type="file:FileRequestMetaData"
xmlns:file="http://www.bea.com/wli/sb/transports/file"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tran:headers xsi:type="file:FileRequestHeaders"
xmlns:tran="http://www.bea.com/wli/sb/transports">
<file:fileName>/customer/data/input/CustList.txt
</file:fileName>
</tran:headers>
<tran:encoding xmlns:tran="http://www.bea.com/wli/sb/transports">utf-8
</tran:encoding>
<file:isFilePath>false</file:isFilePath>
</con:request>
</con:transport>
<con:security>
<con:transportClient>
<con:username>anonymous></con:username>
</con:transportClient>
</con:security>
</con:endpoint>
>
####<Dec 6, 2013 12:32:35 PM PST> <Info> <oracle.osb.pipeline.kernel.router>
<MyServer> <osb_server1> <[ACTIVE] ExecuteThread: '19' for queue:
'weblogic.kernel.Default (self-tuning)'> <<anonymous>>
<BEA1-7438AA7859AFBEC29BF0> <7f5b2958-8673-4439-87ec-f860ccac436b-0005f450>
<1386361955303> <OSB-382186> <[OSB Tracing] Exiting Pipeline>

18 診断フレームワークを使用した問題の診断

この章では、Service Busに関する問題の識別方法と、WebLogic診断フレームワーク(WLDF)およびOracle Fusion Middleware診断フレームワーク(DFW)を使用して適切な修正を行う方法について説明します。

この付録の内容は次のとおりです。

- Oracle Service Busの診断の理解

- Oracle Service Bus診断ダンプの操作

- RDAを使用した診断ダンプの生成

- ADRツールを使用したインシデント・パッケージの表示

- 問題とインシデントの問合せ

18.1 Oracle Service Busの診断の理解

Service Busは、Oracle Fusion Middleware診断フレームワークとともにWebLogic診断フレームワーク(WLDF)を使用して、ユーザーによる問題の検出、診断および解決を支援します。

WLDFを使用すると、指定した条件について特定のログとメトリックを監視し、条件が満たされたときに通知を送信することで、診断シナリオをモニターできます。診断フレームワークを使用すると、Service Bus固有の診断シナリオを、表示と分析用にフォーマットされたデータ・ダンプに集約できます。

WebLogicとSOAスイートにはいずれも、ユーザーの診断を助ける事前定義された複数の診断ダンプが用意されています。また、Service Busでは次の診断ダンプがサポートされています。

- 派生リソースのキャッシュ

- JMSリクエスト/レスポンス相関表

- MQリクエスト/レスポンス相関表

診断フレームワーク、監視および通知の詳細は、Oracle Fusion Middlewareの管理の「問題の診断」を参照してください。SOA Suiteでの診断フレームワークの使用方法の詳細(生成するダンプ、監視と通知の設定および事前定義診断ダンプを含む)は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「SOAコンポジット・アプリケーションに関する問題の診断」を参照してください。

18.1.1 Oracle WebLogic診断フレームワーク

WLDFはOracle WebLogic Serverに付属のモニターおよび診断フレームワークで、WebLogic Serverのプロセス内で実行する一連のサービスの定義および実装を行い、標準的なサーバーのライフ・サイクルに参加します。WLDFを使用すると、実行中のサーバーで生成された診断データを取得して、特定の条件が満たされたときに監視と通知を設定できます。監視と通知を定義することで、問題を特定するための診断データの収集がはかどり、フォルトの発生時にフォルトの特定と診断が可能になります。

WLDFの詳細は、『Oracle WebLogic Server診断フレームワークの構成と使用』を参照してください。

18.1.1.1 監視と通知

監視を作成すると、その監視によりサーバーとアプリケーションの状態がモニターされ、ユーザーが定義した条件に基づいて通知が送信されます。監視と通知は、ドメイン内の1つ以上のサーバー・インスタンスを対象にした診断モジュールの一部として構成します。監視の作成時に、Oracle WebLogic Server管理コンソールで、Service BusとOracle WebLogic ServerのMBeanの属性を使用して、モニター用のルール式を作成します。たとえば、空きヒープ・メモリーの割合が25%を下回るときに通知するように監視を設定できます。Service BusのメッセージIDを使用して、監視および通知を構成できます。

監視および通知の作成の詳細は、Oracle Fusion Middlewareの管理の診断フレームワークの構成に関する項を参照してください。

18.1.1.2 診断シナリオとMBean

診断フレームワークには、データ収集方法の定義に使用できるMBeanが用意されています。作成する監視ルール式では、データの収集とモニターの実行に、Service BusとOracle WebLogic ServerのMBeanの属性を使用します。シナリオの診断には、そのシナリオに関する統計の提供に利用可能なMBeanやメッセージのログ出力に利用可能なMBeanを使用します。次に示すMBeanの属性を利用できます。

- Oracle WebLogic Server MBean

- 診断Service Bus MBean

- MBeanとして公開されているDMSメトリック

Service Busには複数のMBeanが用意され、次のことを監視と通知でモニターできます。

- 構成フレームワーク

- プロキシおよびビジネス・サービス

- パイプラインおよび分割-結合

- セッション

Oracle WebLogic Server MBeanの詳細は、Oracle WebLogic Server MBeanリファレンスを参照してください。

18.1.2 Oracle Fusion Middleware診断フレームワーク

診断フレームワークは、クリティカル・エラー(コードの不具合、メタデータの破損、カスタム・データの破損、デッドロック状態のスレッド、矛盾した状態などが原因のエラー)を対象にすることで、問題の検出、診断および解決に役立ちます。診断フレームワークは、クリティカル・エラーを検出し、関連する診断情報のダンプを取り込みます。WLDFの監視と通知は、診断フレームワークがリスニングするイベントをトリガーし、適切なデータ・ダンプを生成します。

診断フレームワークによるイベント処理方法の詳細は、Oracle Fusion Middlewareの管理の診断フレームワークの動作に関する項を参照してください。

18.1.2.1 診断ダンプ

診断ダンプは、インシデントの作成時には自動的に、管理者の要求時には手動で、特定の診断情報を取り込んでダンプしまします。インシデント作成の一環として実行される場合、ダンプは一連のインシデント診断データに含まれます。診断ダンプの例として、JVMスレッドダンプ、JVMクラス・ヒストグラム・ダンプ、DMSメトリック・ダンプなどがあげられます。

診断フレームワークには、複数の事前定義済ダンプが用意されています。詳細は、『Oracle Fusion Middlewareの管理』の問題の調査、報告および解決に関する項を参照してください。診断フレームワークにより提供されるダンプに加え、Service Busには、Service Busに固有の診断のために用意されたダンプがあります。詳細は、「Oracle Service Bus診断ダンプの操作」を参照してください。

18.1.3 自動診断リポジトリについて

自動診断リポジトリ(ADR)は、トレースやダンプなどの診断データ用のファイル・ベースの階層型リポジトリです。Oracle Fusion Middlewareコンポーネントはすべてのインシデント・データをADRに保管し、各Oracle WebLogic ServerはADR内の各自のホーム・ディレクトリのサブディレクトリに診断データを保管します。ADRの詳細は、Oracle Fusion Middlewareの管理の自動診断リポジトリに関する項を参照してください。

18.1.4 事前定義済のインシデント処理ルール

Oracle WebLogic Serverの管理者用コンソールで監視を作成するときには、通知も定義します。Oracle Fusion Middlewareでは、FMWDFW通知というデフォルトの通知が定義されています。ユーザー独自の通知を作成できる一方で、FMWDFW通知を選択すると、Service Busのダンプが作成されます(「Oracle Service Bus診断ダンプの操作」を参照)。

カスタム通知の作成の詳細は、Oracle Fusion Middlewareの管理のカスタム診断ルールの構成に関する項を参照してください。

18.1.5 ダイナミック・モニタリング・サービス・メトリック

Dynamic Monitoring Service (DMS)を使用すると、Oracle Fusion Middlewareのコンポーネントは、Fusion Middleware Controlなどの管理ツールに、コンポーネントのパフォーマンス、状態および進行中の動作に関するデータを提供できるようになります。DMSは、メトリック、トレース・イベントおよびシステム・パフォーマンスを測定して報告し、これらのコンポーネントにコンテキスト相関サービスを提供します。

ナウン・タイプのDynamic Monitoring Service (DMS)メトリックは、問題の診断に使用するService BusのMBeanとして公開されます。DMSナウンは、Oracle WebLogic Server管理コンソールで監視の作成に使用できます。Service Busは、DMSを使用してService Busプロキシ・サービスのレスポンス時間を取得します。

Service Busでは、親ナウンがサービス・パスのフェーズ・イベント・センサーresponseを定義します。表18-1に、サポートされるService Bus DMSナウンを示します。これには、ナウン階層を説明するために親ナウンも示しています。

表18-1 Service Busセンサー

ナウン・パス

ナウン

センサー

種類

親ナウン

/domain_name/server_name/project_name

コンテキスト

なし

osb_context

なし

PROXYまたはBIZ

サービス・タイプ

なし

osb_service_type

Context

フォルダ名とサービス名を含むサービスへのフルパス(スラッシュまたはバックスラッシュはハイフンに置き換える)。

サービス・パス

response

osb_service_path

サービス・タイプ

次のService Bus環境の場合のコンテキスト名およびサービス・パス名の例を示します。

環境

- ドメイン名: servicebus

- サーバー名: osb_server1

- Service Busプロジェクト名: TravelPoints

- プロキシ・サービスのフォルダ名(TravelPointsプロジェクト): TravelProxyServices

- プロキシ・サービス名: CalculatePoints

例

- コンテキスト: /servicebus/osb_server1/TravelPoints

- サービス・パス: TravelProxyServices-CalculatePoints
DMSでは、'/'で区切ったパスを使用して各Nounを参照できます。パスのデリミタ(/)は、親ナウンの識別に使用します。たとえば、前述の例のサービス・パス・ナウンは、次から直接参照できます。

/servicebus/osb_server1/TravelPoints/PROXY/TravelProxyServices-CalculatePoints

レスポンス・センサーは次の情報を取得します。

メトリック

説明

time

アクティブ化全体の合計レスポンス時間

completed

完了したアクティブ化の数

minTime

最短で完了したアクティブ化

maxTime

最長で完了したアクティブ化

avg

アクティブ化完了までの平均時間

active

現在まだ完了していないアクティブ化の数

maxActive

同時に開くアクティブ化の最大数

DMSの詳細は、『パフォーマンスのチューニング・ガイド』のOracle Dynamic Monitoring Serviceの使用に関する項を参照してください。

18.2 Oracle Service Bus診断ダンプの操作

Oracle WebLogic ServerおよびOracle SOAスイートで使用できる診断ダンプに加え、Service Busではこれらの場所での診断ダンプの作成がサポートされています。

表18-2は場所を示しています。

表18-2 Service Bus診断ダンプ

ダンプ

説明

OSB.derived-caches

サーバー上でのすべてのService Bus派生リソースのキャッシュに関する統計のコレクション

OSB.jms-async-table

Service Bus JMSリクエスト/レスポンス相関表

OSB.mq-async-table

Service Bus MQリクエスト/レスポンス相関表

18.2.1 使用可能な診断ダンプのリスト

ここでは、診断ダンプの操作にWebLogic Scripting Toolコマンドを使用する方法について説明します。これらのコマンドの詳細は、『WebLogic Server WLSTコマンド・リファレンス』の診断コマンドに関する項を参照してください。診断フレームワークのダンプの詳細は、Oracle Fusion Middlewareの管理の問題の診断に関する項を参照してください。

使用可能な診断ダンプをリスト表示するには:

1. MW_HOME/oracle_common/common/binにナビゲートし、次のコマンドを実行してWLSTを起動します。

./wlst.sh

注意:

MW_HOME/oracle_common/common/binからWLSTを起動する必要があります。そうしない場合、ODF機能はありません。

2. Service Busがインストールされているサーバーに接続して、次のコマンドを実行します。

connect('user_name', 'password','t3://hostname:port_number')

接続が成功したかどうかを示すメッセージが表示されます。

3. 使用可能な診断フレームワークのダンプをリスト表示するには、次のコマンドを実行します。

listDumps()

使用可能なダンプのリストがコンソールに表示されます。

特定のダンプのヘルプを表示するには、describeDump(name=dumpName)コマンドを使用します。

4. 使用可能なService Busのダンプをリスト表示するには、次のコマンドを実行します。

listDumps(appName='OSB')

Service Busのダンプのリストがコンソールに表示されます。

18.2.2 派生リソースのキャッシュ診断のダンプ(OSB.derived-caches)

次の表に、Service Bus派生リソースのキャッシュ診断ダンプについての説明を示します。取得される情報には、各キャッシュ・タイプの名前、各キャッシュの統計情報およびキャッシュされた各エントリの情報などがあります。

表18-3 JMS相関表診断ダンプ

ダンプ名

ダンプ・パラメータ/ダンプ・モード

取得される情報

OSB.derived-caches

なし

Service Bus実行時に管理される各派生リソースのキャッシュについて、次の情報が提供されます。

- 派生リソースのキャッシュ・タイプ

- 製品のバージョン

- 構成済キャッシュ・エントリの合計

- 使用中のキャッシュ・エントリ数

- サーバーが最後に起動されてからのキャッシュ・サーバーでのエントリの合計ヒット数

- サーバーが最後に開始されてから、キャッシュ済情報へのアクセス試行中の失敗数合計

- サーバーが最後に起動されてからのキャッシュのヒット率

各キャッシュ・エントリについて次の情報が提供されます。

- キャッシュされている参照

- 日時の作成

- キャッシュ・エントリの計算に費やされた時間これは、キャッシュ情報を作成するためにかかった時間です(ミリ秒単位)。

18.2.2.1 Oracle Service Bus派生リソースのキャッシュ

次の表に、診断情報に含まれる各Service Busキャッシュを示します。

表18-4 Oracle Service Bus派生リソースのキャッシュ

キャッシュ

説明

アーカイブClassLoader

依存性対応アーカイブ・クラス・ローダー。

アーカイブ・サマリー

アーカイブのサマリー。

CodecFactory

Codecファクトリ。

EffectiveWSDL

ビジネス・サービスまたはプロキシ・サービスのサービス・リソースあるいはWSDLリソースから派生した、有効なWSDLオブジェクト。

Flow_Info

メッセージ・フローの情報オブジェクト。

LightweightEffectiveWSDL

ビジネス・サービスまたはプロキシ・サービスのサービス・リソースあるいはWSDLリソースから派生した、有効なWSDLオブジェクト。

MflExecutor

MFLエグゼキュータ。

RouterRuntime

プロキシ・サービスのコンパイル済ルーター・ランタイム。

RuntimeEffectiveWSDL

ビジネス・サービスまたはプロキシ・サービスのサービス・リソースあるいはWSDLリソースから派生した、セッションの有効なWSDLオブジェクト。

RuntimeEffectiveWSPolicy

ビジネス・サービスまたはプロキシ・サービスのWSポリシー

SchemaTypeSystem

MFL、XSおよびWSDLドキュメントの型のシステム情報

ServiceAlertsStatisticInfo

ビジネス・サービスまたはプロキシ・サービスのサービス・アラート統計

ServiceInfo

ビジネス・サービスまたはプロキシ・サービス、あるいはWSDLドキュメントのコンパイル済サービス情報

Wsdl_Info

WSDL情報オブジェクト。

WsPolicyMetadata

コンパイル済WSポリシーのメタデータ。

XMLSchema_Info

XMLスキーマ・オブジェクトのXMLスキーマ情報

XqueryExecutors

XQueryエグゼキュータ。

XsltExecutor

XSLTエグゼキュータ。

alsb.transports.ejb. bindingtype

EJBビジネス・サービスのEJBバインディング情報

alsb.transports.jejb.business. bindingtype

JEJBビジネス・サービスのJEJBバインディング情報

alsb.transports.jejb.proxy. bindingtype

JEJBプロキシ・サービスのJEJBバインディング情報

18.2.2.2 派生リソースのキャッシュ・ダンプの説明の表示

派生リソースのキャッシュの説明を表示するには:

- 次のWLSTコマンドを実行します。

describeDump(name='OSB.derived-caches',appName='OSB')

ダンプの名前、説明および引数がコンソールに表示されます。

18.2.2.3 派生リソースのキャッシュ・ダンプの実行

派生リソースのキャッシュ・ダンプを実行するには:

- 次のWLSTコマンドを実行します。

executeDump(name='OSB.derived-caches', appName='OSB')

「派生リソースのキャッシュ・ダンプの出力例」に、派生リソースのキャッシュ・ダンプの出力例を示します。

18.2.2.4 派生リソースのキャッシュ・ダンプの出力例

「派生リソースのキャッシュ・ダンプの実行」の説明に従って、派生リソースのキャッシュ・ダンプを実行すると、次の例のような情報が表示されます。このダンプの一部は、読みやすくするために切り捨てられています。

<derivedCaches xmlns="http://www.bea.com/wli/config/xmltypes">
<derivedCache cacheType="RuntimeEffectiveWSDL">
<configuredEntries>2147483647</configuredEntries>
<cacheEntriesInUse>0</cacheEntriesInUse>
<totalHits>0</totalHits>
<totalMisses>0</totalMisses>
<hitRatio>0.0</hitRatio>
<cacheEntries/>
</derivedCache>
...
<derivedCache cacheType="ServiceAlertsStatisticInfo">
<configuredEntries>2147483647</configuredEntries>
<cacheEntriesInUse>9</cacheEntriesInUse>
<totalHits>0</totalHits>
<totalMisses>51</totalMisses>
<hitRatio>0.0</hitRatio>
<cacheEntries>
<cacheEntry>
<ref>services/bs_dq_uri4.BusinessService</ref>
<creationTime>2012-03-22T23:44:53.737-07:00</creationTime>
<computeTimeMSecs>0</computeTimeMSecs>
</cacheEntry>
<cacheEntry>
<ref>services/bs_dq_nopooling.BusinessService</ref>
<creationTime>2012-03-22T23:44:53.736-07:00</creationTime>
<computeTimeMSecs>0</computeTimeMSecs>
</cacheEntry>
<cacheEntry>
<ref>services/bs_dq_uri1.BusinessService</ref>
<creationTime>2012-03-22T23:44:53.738-07:00</creationTime>
<computeTimeMSecs>0</computeTimeMSecs>
</cacheEntry>
<cacheEntry>
<ref>services/proxy_dq_uri.ProxyService</ref>
<creationTime>2012-03-22T23:44:53.736-07:00</creationTime>
<computeTimeMSecs>0</computeTimeMSecs>
</cacheEntry>
<cacheEntry>
<ref>services/bs_dq_conn_pooling.BusinessService</ref>
<creationTime>2012-03-22T23:44:53.736-07:00</creationTime>
<computeTimeMSecs>0</computeTimeMSecs>
</cacheEntry>
<cacheEntry>
<ref>services/bs_dq_conn_nopooling.BusinessService</ref>
<creationTime>2012-03-22T23:44:53.737-07:00</creationTime>
<computeTimeMSecs>0</computeTimeMSecs>
</cacheEntry>
<cacheEntry>
<ref>services/bs_dq_uri2.BusinessService</ref>
<creationTime>2012-03-22T23:44:53.737-07:00</creationTime>
<computeTimeMSecs>0</computeTimeMSecs>
</cacheEntry>
<cacheEntry>
<ref>services/bs_dq_pooling.BusinessService</ref>
<creationTime>2012-03-22T23:44:53.736-07:00</creationTime>
<computeTimeMSecs>0</computeTimeMSecs>
</cacheEntry>
<cacheEntry>
<ref>services/bs_dq_uri3.BusinessService</ref>
<creationTime>2012-03-22T23:44:53.737-07:00</creationTime>
<computeTimeMSecs>0</computeTimeMSecs>
</cacheEntry>
</cacheEntries>
</derivedCache>
...
</derivedCaches>

18.2.3 JMS相関表診断ダンプ(OSB.jms-async-table)の実行

表18-5は、Service Bus JMSリクエスト/レスポンス相関表診断ダンプの詳細を示しています。取得される情報には、各メッセージの相関ID、有効期限および宛先などがあります。

表18-5 JMS相関表診断ダンプ

ダンプ名

ダンプ・パラメータ/ダンプ・モード

取得される情報

OSB.jms-async-table

なし

Service Busのバージョンに加え、各サービスの参照では保留中の各メッセージについて次の情報が表示されます。

- 相関ID (実際の相関IDでもメッセージIDでも可能です)

- 有効期限の日時

- メッセージの宛先

18.2.3.1 JMS相関表ダンプの説明の表示

JMS相関表ダンプの説明を表示するには:

- 次のWLSTコマンドを実行します。

describeDump(name='OSB.jms-async-table',appName='OSB')

ダンプの名前、説明および引数がコンソールに表示されます。

18.2.3.2 JMS相関表ダンプの実行

JMS相関表ダンプを実行するには:

- 次のWLSTコマンドを実行します。

executeDump(name='OSB.jms-async-table', appName='OSB')

「JMS相関表ダンプの出力例」に、JMS相関表ダンプの出力例を示します。

18.2.3.3 JMS相関表ダンプの出力例

次の例は、JMS相関表ダンプの出力例です。

<transportDiagnosticsContents xmlns="http://www.bea.com/wli/sb/transportdiags">
<version>11.1.1.7</version>
<transportDiagnostics transportType="jms">
<correlationTable>
<services>
<service>
<ref>default/testJmsResponseRollback_out</ref>
<message>
<correlationMsgId responsePattern="JMSCorrelationID">
ID:42454153155cc06b7f5ab312000001363d5bd59effff8d4
</correlationMsgId>
<expirationTime>2012-03-22T19:53:43.621-07:00</expirationTime>
<msgDestination>testJmsResponseRollback_outRequest</msgDestination>
</message>
</service>
</services>
</correlationTable>
</transportDiagnostics>
</transportDiagnosticsContents>

18.2.4 MQ相関表診断ダンプ(OSB.mq-async-table)の実行

表18-6は、Service Bus MQリクエスト/レスポンス相関表診断ダンプの詳細を示しています。取得される情報には、各メッセージの相関ID、有効期限および宛先などがあります。

表18-6 MQ相関表診断ダンプ

ダンプ名

ダンプ・パラメータ/ダンプ・モード

取得される情報

OSB.mq-async-table

なし

Service Busのバージョンに加え、各サービスの参照では保留中の各メッセージについて次の情報が表示されます。

- 相関ID (実際の相関IDでもメッセージIDでも可能です)

- 有効期限の日時

- メッセージの宛先

18.2.4.1 MQ相関表ダンプの説明の表示

MQ相関表ダンプの説明を表示するには:

- 次のWLSTコマンドを実行します。

describeDump(name='OSB.mq-async-table',appName='OSB')

ダンプの名前、説明および引数がコンソールに表示されます。

18.2.4.2 MQ相関表ダンプの実行

MQ相関表ダンプを実行するには:

- 次のWLSTコマンドを実行します。

executeDump(name='OSB.mq-async-table', appName='OSB')

「MQ相関表ダンプの出力例」に、MQ相関表ダンプの出力例を示します。

18.2.4.3 MQ相関表ダンプの出力例

次の例は、MQ相関表ダンプの出力例です。

例 - MQ相関表ダンプの出力例

<transportDiagnosticsContents xmlns="http://www.bea.com/wli/sb/transportdiags">
<version>11.1.1.7</version>
<transportDiagnostics transportType="mq">
<correlationTable>
<services>
<service>
<ref>services/mq_Biz_cached</ref>
<message>
<correlationMsgId responsePattern="MQCorrelationID">
000000000000000000000000000000000000000000000000
</correlationMsgId>
<expirationTime>2012-03-22T23:48:09.085-07:00</expirationTime>
<msgDestination>rc_req</msgDestination>
</message>
</service>
</services>
</correlationTable>
</transportDiagnostics>
</transportDiagnosticsContents>

18.3 RDAを使用した診断ダンプの生成

WSLTを使用したService Bus診断ダンプの生成に加え、Oracle Remote Diagnostic Agent (RDA)も使用できます。次の手順を実行する前に、RDAがシステムにインストールされていることを確認してください。

Service BusのRDAの使用についての詳細説明および詳細手順は、OracleサポートでSOA製品でのリモート診断エージェント(RDA)の実行方法に関するナレッジ・ベースの記事を参照してください。このドキュメントのIDは1571554.2です。このドキュメントでは、最小限のプロンプトでRDAを実行するための追加コマンドについて説明しています。追加情報および手順は、Fusion Middlewareホーム・ディレクトリのoracle_commonディレクトリにあるREADMEファイルにも示されています。

RDAを使用して診断ダンプを生成するには、次の手順を実行します。

1. 次のコマンドを実行して、環境変数を設定します。

<DOMAIN_HOME>/bin/setDomainEnv

2. コマンド行から次のコマンドを実行します。

Windowsの場合:

rda.cmd -vSCRP OSB

UNIXまたはLINUXの場合

rda.sh -vSCRP OSB

3. コマンド行でプロンプトに従って情報を入力します。Service Bus情報の収集にRDAを使用するかどうかを尋ねられたら、デフォルト(Y)を受け入れます。

4. Webブラウザに結果を表示できます。指定した出力ディレクトリからファイルにアクセスします。

このファイルの名前はprefix__start.htmです(prefixは、指定した接頭辞)。

18.4 ADRツールを使用したインシデント・パッケージの表示

ADRCIは、コマンド行ユーティリティです。このユーティリティを使用すると、問題を調査して、応急障害診断データをパッケージ化してOracleサポート・サービスにアップロードできます。また、ADRCIを使用すると、ADR内のダンプ・ファイルの名前を表示したり、XMLタグを削除したアラート・ログを表示したりできます。この表示には、コンテンツ・フィルタを適用することもできます。

ADRCIの詳細は、Oracle DatabaseユーティリティのADRCI: ADRコマンド・インタプリタに関する項を参照してください。その他のツールの詳細は、Oracle Database管理者ガイドの診断データの管理に関する項を参照してください。

18.5 問題とインシデントの問合せ

診断フレームワークには、問題とインシデントに関する情報を表示できるWLSTコマンドが用意されています。

次のものが必要となります。

- 複数のOracle WebLogic Serverに対する問題の問合せ

- 複数のOracle WebLogic Serverに対するインシデントの問合せ

- 特定のOracle WebLogic Serverのインシデントに関連付けられたダンプ・ファイルの表示

これらのWLSTコマンドの詳細は、Oracle Fusion Middlewareの管理の診断フレームワークの理解に関する項および『WebLogic Server WLSTコマンド・リファレンス』の診断コマンドに関する項を参照してください。

付録

この部には、Service Bus環境の管理に役立つ参照情報が含まれています。

この部は、次の付録で構成されています。

- JMXモニタリングAPI

- Oracle Service BusデプロイメントAPIの使用

- Oracle Service Busシステムの監査

- WSRPとの相互運用性

- Oracle Service Busでのロール・ベースのアクセス

A JMXモニタリングAPI

この付録では、Service Busモニター・データへの外部アクセスを提供するOracle Service BusのJava Management Extensions (JMX)モニタリングAPIについて説明します。 JMXモニタリングAPIの主な目的は、一括操作をサポートする、効率的な低レベルのAPIを提供することです。JMXをトランスポートとして使用することでこれを行います。このAPIは、JMXベースのツールと互換性のある高レベルのAPIではありません。ただし、クライアント・ソフトウェアを開発する場合は、JMXベースのツールをサポートする高レベルのJMX APIを開発することもできます。

この付録の内容は次のとおりです。

- JMXモニタリングAPIについて

- JMXモニタリングAPIの使用

- APIの使用方法の例

A.1 JMXモニタリングAPIについて

JMXモニタリングAPIは、トランスポートとしてのみJMXを利用します。任意のモニター対象サービスとそのコンポーネントのモニター・データ(統計情報)を取得するために必要なすべての操作を提供する公開MBeanを公開します。また、MBeanによって提供される操作を実行するために必要な、一連の公開POJOオブジェクトも公開します。

サード・パーティ製クライアント・ソフトウェアが、Service Busのモニター・システムに格納されている統計情報の階層構造の詳細を認識する必要はありません。

これらのAPIを使用することで、モニター/管理システムをService Busと統合し、次の操作を行うことができます。

- モニターが有効になっているサービスの特定。

- 特定のサービス、またはそのコンポーネント、もしくは両方の詳細な統計情報の取得。

- 最後のリセット以降に蓄積された統計のリセット。

A.2 JMXモニタリングAPIの使用

公開JMX APIは、モニター対象サービスをチェックし、それらからデータを取得する操作を含むServiceDomainMBeanの単一のインスタンスによってモデル化されます。POJOの公開セットは、ServiceDomainMbeanとともに統計のモニター用の完全なAPIを提供する、追加のオブジェクトとメソッドを提供します。

次の各項では、POJOとMBeanについて簡単に説明し、Service Busのリソースに関してレポートされる統計についても説明します。Oracle Service Bus Java APIリファレンスには、POJOとMBeanの詳細が記載されています。

この章の最後にある重要な注意事項を必ずお読みください。

A.2.1 公開POJOオブジェクト

次のPOJOオブジェクトは、JMXモニタリングAPIの一部として公開されています。

- ResourceType

- ServiceResourceStatistic

- ResourceStatistic

- StatisticValue

- StatisticType

A.2.1.1 ResourceType

このオブジェクトは、サービスのモニターに対して有効な、すべてのタイプのリソースを示します。enum定数には、タイプSERVICE、FLOW_COMPONENT、URIおよびWEBSERVICE_OPERATIONを示す4種類があります。

Oracle Service Bus Java APIリファレンスのcom.bea.wli.monitoring.ResourceTypeを参照してください。

A.2.1.2 ServiceResourceStatistic

このオブジェクトは、すべてのビジネス・サービスおよびプロキシ・サービスのリソース・タイプとそれらに関連付けられている統計を示します。すべてのリソースの統計を取得するメソッドと、特定のリソースの統計を取得するメソッドがあります。

Oracle Service Bus Java APIリファレンスのcom.bea.wli.monitoring.ServiceResourceStatisticを参照してください。

A.2.1.3 ResourceStatistic

このオブジェクトは、統計の収集がサポートされるリソースを示します。リソースの名前、タイプ、および統計を取得するメソッドがあります。

Oracle Service Bus Java APIリファレンスのcom.bea.wli.monitoring.ResourceStatisticを参照してください。

A.2.1.4 StatisticValue

このオブジェクトは、リソースの統計値を示します。現時点で、モニター・システムは、次のタイプの統計値をサポートしています。これらはすべて、ネストされたクラスです。

- CountStatistic

- IntervalStatistic

- StatusStatistic

StatisticValueは抽象クラスです。そのため、このクラスからは、数および時間間隔の統計値を表す具象オブジェクトを派生できます。これには、getName()メソッドおよびgetType()メソッドが含まれます。

Oracle Service Bus Java APIリファレンスのcom.bea.wli.monitoring.StatisticValueを参照してください。

A.2.1.5 StatisticType

このオブジェクトは、統計の事前定義されたタイプを示します。STATUS、COUNTおよびINTERVALという3つのenumタイプがあります。

Oracle Service Bus Java APIリファレンスのcom.bea.wli.monitoring.StatisticValueを参照してください。

A.2.2 ServiceDomainMBean

このMBeanは、サービス・ドメインを表します。モニター対象サービスを検索したり、統計を取得およびリセットしたり、ビジネス・サービス・エンドポイントURIをオフラインにマークするメソッドを提供します。詳細は、Oracle Service Bus Java APIリファレンスのcom.bea.wli.monitoring.ServiceDomainMBeanを参照してください。

A.2.3 MonitoringConfigurationMBean

このMBeanは、モニターおよびアラートを有効化/無効化するメソッドを提供します。サブインタフェースは、様々なタイプのサービスを実行時に管理するメソッドを提供します。詳細は、Oracle Service Bus Java APIリファレンスのcom.bea.wli.sb.management.configuration.MonitoringConfigurationMBeanを参照してください。

A.2.4 Oracle Service Busについて収集される統計

次の項では、リソース・タイプごとにレポートされる統計について説明します。

- リソース・タイプの統計の詳細 - SERVICE

- リソース・タイプの統計 - FLOW_COMPONENT

- リソース・タイプの統計の詳細 – WEBSERVICE_OPERATION

- リソース・タイプの統計の詳細 – URI

A.2.4.1 リソース・タイプの統計の詳細 - SERVICE

サービスのリソース・タイプには、インバウンドおよびアウトバウンドのエンドポイント(プロキシ・サービスおよびビジネス・サービス)に加え、メッセージを変換してルーティングするパイプラインと分割-結合があります。これらのリソースには、関連するWSDLファイル、セキュリティ設定などがあります。

次の統計が、このリソース・タイプについてレポートされます。この表に示すように、特定の統計が特定のサービスにのみ適用されることに注意してください。

表A-1 SERVICE統計

統計名

タイプ

サービス・タイプ

Alert.pipeline-severity-all

件数

パイプライン

Alert.pipeline-severity-critical

件数

パイプライン

Alert.pipeline-severity-fatal

件数

パイプライン

Alert.pipeline-severity-major

件数

パイプライン

Alert.pipeline-severity-minor

件数

パイプライン

Alert.pipeline-severity-normal

件数

パイプライン

Alert.pipeline-severity-warning

件数

パイプライン

Alert.severity-all

件数

すべて

Alert.sla-severity-all

件数

すべて

Alert.sla-severity-critical

件数

すべて

Alert.sla-severity-fatal

件数

すべて

Alert.sla-severity-minor

件数

すべて

Alert.sla-severity-normal

件数

すべて

Alert.sla-severity-major

件数

すべて

Alert.sla-severity-warning

件数

すべて

Router.elapsed-time

間隔

パイプライン

Router.error-count

件数

パイプライン

Router.failure-rate

派生

パイプライン

Router.message-count

件数

パイプライン

Router.success-rate

派生

パイプライン

Router.validation-errors

件数

パイプライン

Security.WebService Security.wss-errors

件数

ビジネス・サービスおよびプロキシ・サービス

SplitJoin.elapsed-time

間隔

分割-結合

SplitJoin.error-count

件数

SplitJoin

SplitJoin.failure-rate

派生

SplitJoin

SplitJoin.message-count

件数

SplitJoin

SplitJoin.success-rate

派生

SplitJoin

Transport.cache-hit-count

件数

ビジネス・サービス

Transport.error-count

件数

ビジネス・サービスおよびプロキシ・サービス

Transport.failover-count

件数

ビジネス・サービス

Transport.failure-rate

派生

ビジネス・サービスおよびプロキシ・サービス

Transport.message-count

件数

ビジネス・サービスおよびプロキシ・サービス

Transport.response-time

間隔

ビジネス・サービスおよびプロキシ・サービス

Transport.success-rate

派生

ビジネス・サービスおよびプロキシ・サービス

Transport.throttling-time

間隔

ビジネス・サービス

Transport.uri-offline-count

件数

ビジネス・サービス

注意:

- wss-error統計は、Webサービスのセキュリティ違反数を示します。

- ServiceDomainMBeanを使用して、クラスタ・ドメインから管理対象サーバーの統計を取得する場合、sla-severity-normal、sla-severity-minor、sla-severity-major、sla-severity-warning、sla-severity-critical、sla-severity-fatal、sla-severity-allは、プロキシ・サービスについての統計に含まれません。

- Fusion Middleware Controlには、統計の名前のみが表示されます。

- Success ratio (*.success-rate統計)は、メッセージの総数に対する成功したメッセージの割合(%)を表します。Failure ratio (*.failure-rate統計)は、メッセージの総数に対する失敗したメッセージの割合(%)を表します。

- 統計の名前は、収集対象のサービスのコンポーネントに「.」で連結されます。

A.2.4.2 リソース・タイプの統計 - FLOW_COMPONENT

パイプラインの統計は、パイプライン・ペア・ノードとルーティング・ノードで収集されます。分割-結合の場合は、ブランチ・ノードで収集されます。

パイプラインは、現在のメッセージに対して順次実行されるステージで構成される、一方向の処理の流れです。ステージは、トランスフォーメーション、ロギング、およびパブリッシュなどのアクティビティの実行に使用されます。パイプラインには、リクエスト、レスポンス、およびエラーの3つのカテゴリがあります。パイプライン・ペア・ノードは、1つのリクエスト・パイプラインと1つのレスポンス・パイプラインを1つの最上位要素に結び付けたものです。

ルーティング・ノードは、一連のルートで構成されます。ルートは、対象サービスを特定し、そのサービスへメッセージをパッケージ化し、送信する方法を決定する追加の構成オプションを含みます。ルーティング・ノードは、リクエスト処理の一部として選択されている1つのルートになります。

分割-結合を使用すると、標準の順次処理とは対照的に、注文などのサービス・ペイロードを、複数のサービスに同時に送信される個々のメッセージに分割できます。処理は各ブランチ内で定義されます。

これらのリソースのフロー・コンポーネントについて、次の統計がレポートされます。

表A-2 FLOW_COMPONENT統計

統計名

種類

サービス・タイプ

Router.Pipeline.name.elapsed-time

間隔

パイプライン

Router.Pipeline.name.error-count

件数

パイプライン

Router.Pipeline.name.message-count

件数

パイプライン

Router.Route Node.name.elapsed-time

間隔

パイプライン

Router.Route Node.name.error-count

件数

パイプライン

Router.Route Node.name.message-count

件数

パイプライン

SplitJoin.Branch.name.elapsed-time

間隔

SplitJoin

SplitJoin.Branch.name.error-count

件数

SplitJoin

SplitJoin.Branch.name.message-count

件数

SplitJoin

注意:

パイプラインペア、ルート・ノードおよび分割-結合ブランチの統計は、フロー・コンポーネントの統計として返されます。enum値のResourceType.FLOW_COMPONENTは、パイプラインと分割-結合の両方のコンポーネントを表します。そのため、返されたフロー・コンポーネントが、パイプラインペア、ルート・ノードまた分割-結合ブランチのどれであるかをクライアントでは確認できません。ただし、フロー・コンポーネントの名前が、タイプを示唆する場合があります。

A.2.4.3 リソース・タイプの統計の詳細 – WEBSERVICE_OPERATION

このリソース・タイプは、WSDL操作に関連する統計情報を提供します。統計は、それぞれの定義された操作についてレポートされます。次の統計がレポートされます。

表A-3 WEBSERVICE_OPERATION統計

統計名

種類

サービス・タイプ

Operation.name.elapsed-time

間隔

ビジネス・サービス、プロキシ・サービスおよびパイプライン

Operation.name.error-count

件数

ビジネス・サービス、プロキシ・サービスおよびパイプライン

Operation.name.message-count

件数

ビジネス・サービス、プロキシ・サービスおよびパイプライン

A.2.4.4 リソース・タイプの統計の詳細 – URI

このリソース・タイプは、ビジネス・サービスのエンドポイントURIに関連する統計情報を提供します。統計は、それぞれの定義されたエンドポイントURIについてレポートされます。次の統計がレポートされます。

表A-4 エンドポイントURIの統計

統計名

種類

Transport.uri.name.error-count

件数

Transport.uri.name.message-count

件数

Transport.uri.name.response-time

間隔

Transport.uri.name.status

ステータス

注意:

JMXモニタリングAPIを使用して、クラスタの種類のステータスの統計を取得することはできません。

A.2.5 注意事項

JMXモニタリングAPIの使用時には、次の事項に注意してください。

- クライアント・プログラムは、定期的に変更を確認しないかぎり、モニターが有効になっている新しく追加されたサービス、またはモニターが有効に変更されたサービスを認識しません。

- リセット・オプションは頻繁に実行しません。リセットの実行には15分を超える間隔を空けることをお薦めします。

- プロキシ・サービスまたはビジネス・サービスの実行中に統計がリセットされた場合は、次のTransactionConflictExceptionが発生する可能性があります。これが最も発生しやすいのは、統計がシステム起動時にリセットされた場合です。

<OSB-382016> <Failed to instantiate router for service...>

- 複数のスレッドまたはプロセスを同時に実行している場合は、このAPIの使用は推奨されません。これは、あるスレッドまたはプロセスで実行されたリセットが、別のスレッドまたはプロセスからは認識できないためです。この注意事項は、Fusion Middleware Controlから実行したリセットにも当てはまり、このようなリセットはこのAPIでは認識できません。

A.2.6 パフォーマンス

パフォーマンスは、Fusion Middleware Controlで確認されるもの以上になります。

A.3 APIの使用方法の例

この項のサンプル・プログラムは、JMXモニタリングAPIの使用方法について説明しています。

次の手順は、モニターが有効になっているプロキシ・サービスについて、統計を取得する方法について説明しています。

1. MBeanサーバーからServiceDomainMBeanを取得します。

2. ServiceDomainMBeanのgetMonitoredRefs操作を使用して、モニターされるサービスの参照を取得します。

3. 必要なサービスのServiceDomainMBeanのgetStatistics操作を使用して、ServiceResourceStatisticsを取得します。

4. getAllResourceStatisticsの操作を使用して、すべてのResourceStatisticオブジェクトを取得します。

5. 取得したResourceStatisticオブジェクトごとに、getStatistics操作を使用して、StatisticValueオブジェクトを取得し、統計情報をファイルに保存します。

6. 必要に応じてプロセスを繰り返します。

A.3.1 サンプル・プログラム

次のサンプル・プログラムは、次の方法を示します。

1. モニター可能なビジネス・サービスおよびプロキシ・サービスを検索します。

2. 1つまたは複数のサービスの統計を取得します。

3. 1つまたは複数のサービスの統計をリセットします。

4. 例外を処理します。

5. 取得した統計を適切な形式で保存します。

このプログラムを実行するには、次のJARファイルをクラス・パスに含めます。

- weblogic.jar

- oracle.servicebus.kernel-api.jar

- oracle.servicebus.configfwk.jar

- com.bea.core.management.core_version.jar

- com.bea.core.management.jmx_version.jar

ご使用の環境に合せて、次のコードに含まれるSERVER_NAME、HOSTNAME、PORT、USERNAMEおよびPASSWORDのデフォルト値をリセットする必要がある場合があります。

注意:

ビジネス・サービスのエンドポイントごとのステータス統計を取得する必要がある場合は、クラスタ環境でSERVER_NAME属性を設定してください。単一のノードで実行している場合は、このプロパティを設定しない場合でもステータス統計が返されます。

パフォーマンス上の理由から、大量のサービスの統計を頻繁に抽出したりリセットしたりしないでください。「注意事項」を参照してください。サンプル・プログラムは、次の例を参照してください。

例 - モニターが有効になっているプロキシ・サービスについての統計を取得するサンプル・プログラム

次のサンプルには、読みやすくするために折り返しおよび再書式化されている行があります。

package tests.monitoring;

import com.bea.wli.config.Ref;
import com.bea.wli.monitoring.*;
import com.bea.wli.sb.util.Refs;
import weblogic.management.jmx.MBeanServerInvocationHandler;

import javax.management.MBeanServerConnection;
import javax.management.MalformedObjectNameException;
import javax.management.ObjectName;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;
import javax.naming.Context;
import java.io.File;
import java.io.FileWriter;
import java.io.IOException;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
import java.net.MalformedURLException;
import java.util.*;
import java.text.SimpleDateFormat;

public class ServiceStatisticsRetriever
{
private ServiceDomainMBean serviceDomainMbean = null;
private String serverName = null;

/**
* Retrieve statistics for all business services being monitored in the
* domain and reset statistics for the same.
*/
void getAndResetStatsForAllMonitoredBizServices() throws Exception
{
getAndResetStatsForMonitoredServices(
new String[] {Refs.BUSINESS_SERVICE_TYPE},
new ResourceType[]{ResourceType.SERVICE, ResourceType.WEBSERVICE_OPERATION,
ResourceType.URI},
serverName, "BizStatistics");
}

/**
* Retrieve statistics for all proxy services being monitored in the
* domain and reset statistics for the same.
*/
void getAndResetStatsForAllMonitoredProxyServices() throws Exception
{
getAndResetStatsForMonitoredServices(
new String[]  {Refs.PROXY_SERVICE_TYPE},
new ResourceType[]{ResourceType.SERVICE, ResourceType.FLOW_COMPONENT,
ResourceType.WEBSERVICE_OPERATION},
null,
"ProxyStatistics");
}

/**
* Retrieve statistics for all business services being monitored in the
* domain and reset statistics for the same.
*/
void getAndResetStatsForMonitoredServices(String[] typeIds, ResourceType[] resourceTypes,
String serverName, String filePrefix) throws Exception
{
Ref[] serviceRefs = serviceDomainMbean.getMonitoredRefs(typeIds);

try
{
// Get statistics for a specific server.
System.out.println("Now trying to get statistics for -" + serviceRefs.length + "
services...");
HashMap<Ref, ServiceResourceStatistic> resourcesMap =
serviceDomainMbean.getStatistics(
serviceRefs,
resourceTypes,
serverName);

// Reset statistics.
long resetRequestTime = serviceDomainMbean.resetStatistics(serviceRefs);

// Save retrieved statistics.
String fileName = filePrefix +
"_" +
new SimpleDateFormat("yyyy_MM_dd_HH_mm").format(new
Date(System.currentTimeMillis())) +
".txt";
saveStatisticsToFile(resourcesMap, resetRequestTime, fileName);
}
catch (IllegalArgumentException iae)
{
System.out.println("===============================\n");
System.out.println("Encountered IllegalArgumentException...Details:");
System.out.println(iae.getMessage());
System.out.println("Check if proxy ref was passed OR flowComp " +
"resource was passed OR bitmap is invalid..." +
"\nIf so correct it and try again!!!");
System.out.println("==================================\n");
throw iae;
}
catch (DomainMonitoringDisabledException dmde)
{
// Statistics not available as monitoring is turned off at domain level.
System.out.println("==================================\n");
System.out.println("Statistics not available as monitoring " +
"is turned off at domain level.");
System.out.println("==============================\n");
throw dmde;
}
catch (MonitoringException me)
{
// Internal problem... May be aggregation server is crashed...
System.out.println("================================\n");
System.out.println("ERROR: Statistics is not available..." +
"Check if aggregation server is crashed...");
System.out.println("=================================\n");
throw me;
}
}

/**
* Saves statistics of all services from the specified map.
*
* @param statsMap     Map containing statistics for one or more services
*                     of the same type; i.e., business or proxy.
* @param resetReqTime Reset request time. This information will be
*                     written at the end of the file, provided it is not zero.
* @param fileName     Statistics will be saved in a file with this name.
*/
private void saveStatisticsToFile(
HashMap<Ref, ServiceResourceStatistic> statsMap,
long resetReqTime,
String fileName) throws Exception
{
if (statsMap == null)
{
System.out.println("\nService statistics map is null...Nothing to save.\n");
return;
}

if (statsMap.size() == 0)
{
System.out.println("\nService statistics map is empty...Nothing to save.\n");
return;
}

FileWriter out = new FileWriter(new File(fileName));

out.write("*********************************************\n");
out.write("This file contains statistics for " + statsMap.size() + " services.\n");
out.write("***********************************************\n");

Set<Map.Entry<Ref, ServiceResourceStatistic>> set = statsMap.entrySet();

System.out.println("\nWriting stats to the file - " + fileName +"\n");

// Print statistical information of each service
for (Map.Entry<Ref, ServiceResourceStatistic> mapEntry : set)
{
out.write("\n\n======= Printing statistics for service " +
mapEntry.getKey().getFullName() + "=======\n");

ServiceResourceStatistic serviceStats = mapEntry.getValue();
out.write("Statistic collection time is - " + new
Date(serviceStats.getCollectionTimestamp()) + "\n");

try
{
ResourceStatistic[] resStatsArray = serviceStats.getAllResourceStatistics();

for (ResourceStatistic resStats : resStatsArray)
{
// Print resource information
out.write("\nResource name: " + resStats.getName());
out.write("\tResource type: " + resStats.getResourceType().toString());

// Now get and print statistics for this resource
StatisticValue[] statValues = resStats.getStatistics();
for (StatisticValue value : statValues)
{
out.write("\n\t\tStatistic Name - " + value.getName());
out.write("\n\t\tStatistic Type - " + value.getType());

// Determine statistics type
if (value.getType() == StatisticType.INTERVAL)
{
StatisticValue.IntervalStatistic is =
(StatisticValue.IntervalStatistic) value;

// Print interval statistics values
out.write("\n\t\t\t\tCount Value - " + is.getCount());
out.write("\n\t\t\t\tMin Value - " + is.getMin());
out.write("\n\t\t\t\tMax Value - " + is.getMax());
out.write("\n\t\t\t\tSum Value - " + is.getSum());
out.write("\n\t\t\t\tAve Value - " + is.getAverage());
}
else if (value.getType() == StatisticType.COUNT)
{
StatisticValue.CountStatistic cs =(StatisticValue.CountStatistic)
value;

// Print count statistics value
out.write("\n\t\t\t\tCount Value - " + cs.getCount());
}
else if (value.getType() == StatisticType.STATUS)
{
StatisticValue.StatusStatistic ss = (StatisticValue.StatusStatistic)
value;
// Print count statistics value
out.write("\n\t\t\t\t Initial Status - " + ss.getInitialStatus());
out.write("\n\t\t\t\t Current Status - " + ss.getCurrentStatus());
}
}
}

out.write("\n=========================================\n");
}
catch (MonitoringNotEnabledException mnee)
{
// Statistics not available
out.write("WARNING: Monitoring is not enabled for this service... Do
something...");
out.write("=====================================\n");
}
catch (InvalidServiceRefException isre)
{
// Invalid service
out.write("ERROR: Invlaid Ref. May be this service is deleted. Do something...");
out.write("======================================\n");
}
catch (MonitoringException me)
{
// Statistics not available
out.write("ERROR: Failed to get statistics for this service...Details: " +
me.getMessage());
me.printStackTrace();
out.write("======================================\n");
}
}

if (resetReqTime > 0)
{
// Save reset request time.
out.write("\n*****************************************\n");
out.write("Statistics for all these services are RESET.\n");
out.write("RESET request time is "
+ new SimpleDateFormat("MM/dd/yyyy HH:mm:ss").format(new Date(resetReqTime)));
out.write("\n****************************************\n");
}

// Flush and close file.
out.flush();
out.close();
}

/**
* Init method.
*
* @param props Properties required for initialization.
*/
private void init(HashMap props) throws Exception
{
Properties properties = new Properties();
properties.putAll(props);

initServiceDomainMBean(properties.getProperty("HOSTNAME"),
Integer.parseInt(properties.getProperty("PORT", "7001")),
properties.getProperty("USERNAME"),
properties.getProperty("PASSWORD"));

serverName = properties.getProperty("SERVER_NAME");
}

/**
* Gets an instance of ServiceDomainMBean from the weblogic server.
*/
private void initServiceDomainMBean(String host, int port, String username, String password)
throws Exception
{
InvocationHandler handler = new ServiceDomainMBeanInvocationHandler(host, port, username,
password);

Object proxy = Proxy.newProxyInstance(
ServiceDomainMBean.class.getClassLoader(),
new Class[]{ServiceDomainMBean.class}, handler);

serviceDomainMbean = (ServiceDomainMBean) proxy;
}

/**
* Invocation handler class for ServiceDomainMBean class.
*/
public static class ServiceDomainMBeanInvocationHandler implements InvocationHandler
{
private String jndiURL = "weblogic.management.mbeanservers.domainruntime";
private String mbeanName = ServiceDomainMBean.NAME;
private String type = ServiceDomainMBean.TYPE;

private String protocol = "t3";
private String hostname = "localhost";
private int port = 7001;
private String jndiRoot = "/jndi/";

private String username = "weblogic";
private String password = "weblogic";

private JMXConnector conn = null;
private Object actualMBean = null;

public ServiceDomainMBeanInvocationHandler(String hostName, int port, String userName,
String password)
{
this.hostname = hostName;
this.port = port;
this.username = userName;
this.password = password;
}

/**
* Gets JMX connection
*/
public JMXConnector initConnection() throws IOException, MalformedURLException
{
JMXServiceURL serviceURL = new JMXServiceURL(protocol, hostname, port, jndiRoot +
jndiURL);
Hashtable<String, String> h = new Hashtable<String, String>();

if (username != null)
h.put(Context.SECURITY_PRINCIPAL, username);
if (password != null)
h.put(Context.SECURITY_CREDENTIALS, password);

h.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES, "weblogic.management.remote");

return JMXConnectorFactory.connect(serviceURL, h);
}

/**
* Invokes specified method with specified params on specified
* object.
*/
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable
{
if (conn == null)
conn = initConnection();

if (actualMBean == null)
actualMBean = findServiceDomain(conn.getMBeanServerConnection(), mbeanName, type,
null);

return method.invoke(actualMBean, args);
}

/**
* Finds the specified MBean object
*
* @param connection - A connection to the MBeanServer.
* @param mbeanName  - The name of the MBean instance.
* @param mbeanType  - The type of the MBean.
* @param parent     - The name of the parent Service. Can be NULL.
* @return Object - The MBean or null if the MBean was not found.
*/
public Object findServiceDomain(MBeanServerConnection connection,
String mbeanName,
String mbeanType,
String parent)
{
try
{
ObjectName on = new ObjectName(ServiceDomainMBean.OBJECT_NAME);
return (ServiceDomainMBean)
MBeanServerInvocationHandler.newProxyInstance(connection, on);
}
catch (MalformedObjectNameException e)
{
e.printStackTrace();
return null;
}
}
}

/**
* Timer task to keep retrieving and resetting service statistics.
*/
static class GetAndResetStatisticsTask extends TimerTask
{
private ServiceStatisticsRetriever collector;

public GetAndResetStatisticsTask(ServiceStatisticsRetriever col)
{
collector = col;
}

public void run()
{
System.out.println("\n**********************************");
System.out.println("Retrieving statistics for all monitored" + "business services.");

try
{
collector.getAndResetStatsForAllMonitoredBizServices();
System.out.println("Successfully retrieved and reset statistics for " +
"all monitored \n business services at " +
new SimpleDateFormat("MM/dd/yyyy HH:mm:ss").format(new
Date(System.currentTimeMillis())));
}
catch (Exception e)
{
System.out.println("Failed to retrieve and reset statistics for all monitored
business services...");
e.printStackTrace();
}
System.out.println("**********************************\n");
System.out.println("\n**********************************");
System.out.println("Retrieving statistics for all monitored proxy services.");

try
{
collector.getAndResetStatsForAllMonitoredProxyServices();
System.out.println("Successfully retrieved and reset statistics " +
"for all monitored \nproxy services at " +
new SimpleDateFormat("MM/dd/yyyy HH:mm:ss").format(new
Date(System.currentTimeMillis())));
}
catch (Exception e)
{
System.out.println("Failed to retrieve and reset statistics " +
"for all monitored proxy services...");
e.printStackTrace();
}

System.out.println("*********************************\n");
}
}

/**
* The main method to start the timer task to extract, save, and reset
* statistics for all monitored business and proxy services. It uses
* the following system properties.
* 1. hostname - Hostname of admin server
* 2. port - Listening port of admin server
* 3. username - Login username
* 4. password - Login password
* 5. period - Frequency in hours. This will be used by the timer
* to determine the time gap between two executions.
*
* @param args Not used.
*/
public static void main(String[] args)
{
try
{
Properties p = System.getProperties();

HashMap<String, String> map = new HashMap<String, String>();

map.put("HOSTNAME", p.getProperty("hostname", "localhost"));
map.put("PORT", p.getProperty("port", "7001"));
map.put("USERNAME", p.getProperty("username", "weblogic"));
map.put("PASSWORD", p.getProperty("password", "weblogic"));

//set a server name if you want to get the uri status statistics in a cluster
map.put("SERVER_NAME", p.getProperty("server_name", "AdminServer"));

String periodStr = p.getProperty("period", "1");
int periodInHour = Integer.parseInt(periodStr);
long periodInMilliSec = periodInHour * 60 * 60 * 1000;

ServiceStatisticsRetriever collector = new ServiceStatisticsRetriever();
collector.init(map);

// Start timer.
Timer timer = new Timer();
timer.scheduleAtFixedRate(new GetAndResetStatisticsTask(collector),
0, periodInMilliSec);
}
catch (Exception e)
{
e.printStackTrace();
}
}
}

B Oracle Service BusデプロイメントAPIの使用

Service Bus MBeansをJavaプログラムおよびWLSTスクリプトで使用すると、開発環境からテスト環境、ステージング環境を経て、最終的に本番環境に至るまで、Service Bus構成のプロモーションを自動化できます。

この付録の内容は次のとおりです。

- デプロイメントMBeanの概要

- プログラムとスクリプトを使用したセッションの管理

- プログラムとスクリプトを使用した構成タスクの管理

ヒント:

Service Bus APIは、Oracle Service Bus Java APIリファレンスを参照してください。

B.1 デプロイメントMBeanの概要

これらのMBeanは、Service Busシステムのセッションおよび構成を管理する際に役立つデプロイメント機能を提供します。

- SessionManagementMBean: このMBeanは、セッションの作成、アクティブ化、破棄、または既存のセッションの名前を返すために使用します。

- ALSBConfigurationMBean: このMBeanは、Service Bus構成のインポートとエクスポート、環境固有の情報(エンドポイントURIなど)の更新およびService Bus構成とリソースの問合せを行うために使用します。
デプロイメント時に様々なカスタマイズ・オプションを適用できます。様々な環境変数を使用して、環境を移行する際の設定を保持または調整することが可能です。

これらのインタフェースは、com.bea.wli.sb.management.configurationパッケージ内にあります。

B.2 プログラムとスクリプトを使用したセッションの管理

Service Busセッションを使用すると、異なるユーザーが相互に干渉することなく構成データの個々の部分を更新できます。

セッションとは、基本的には名前付きのサンドボックスであり、ここでの変更内容はアクティブ化されるまで、他のユーザーおよびコア・データ(Service Busの実行対象のデータ)から分離されます。リソースとService Busの構成を変更するには、セッションを作成し、作成したセッションで変更を実行する必要があります。セッションをアクティブ化した場合にのみ、変更はコア・データに反映されます。セッションの名前が同じでない限り、複数のセッションを作成できます。

各MBeanタイプ(SessionManagementMBeanを除く)には、セッションごとに1つのインスタンスがあります。セッションが作成されると、新しい一連のMBeanインスタンス(MBeanタイプごとに1つ)が自動的に生成されます。各MBeanタイプの1つのインスタンスが、Service Busデータ・キャッシュに保存されているコア・データを操作します。セッションが破棄またはアクティブ化されると、セッションに作成されたMBeanインスタンスは破棄されます。ただし、コア・データで動作するMBeanインスタンスは破棄されません。コア・データで動作するMBeanインスタンスでは、更新操作はサポートされていません。

B.2.1 セッションの作成、アクティブ化、破棄、検索

Service BusセッションはOracle Service Busコンソールを使用して作成します。SessionManagementMBeanインタフェースのメソッドは、コンソールで提供される対話機能と直接的に対応していて、それらの機能のコンソールと同じ順序で実行する必要があります。次の表に、SessionManagementMBeanインタフェースで使用できるメソッド、およびメソッドによって実行されるタスクを示します。

表B-1 セッション管理メソッド

作業内容

使用するメソッド

ユーザー指定の名前が付いた新しいセッションを作成します。

createSession(String session)

セッションをアクティブ化します。

activateSession(String session, String description)

変更をアクティブ化せずにセッションを削除します。

discardSession(String session)

特定のセッション名のセッションが存在しているかどうかを確認します。このメソッドは、そのセッションが存在しない場合にtrueを返します。

sessionExists(String session)

SessionManagementMBeanインタフェースのリファレンス資料、Javaの使用例、およびJavaクライアントやスクリプトでMBeanを使用する方法を示したサンプル・コードは、Oracle Service Bus Java APIリファレンスのcom.bea.wli.sb.management.configuration.SessionManagementMBeanのドキュメントを参照してください。このドキュメントには、セッションの作成方法、セッションを作成するためのSessionManagementMBeanの取得方法、作成したセッションとコア・データを操作するためのALSBConfigurationMBeanの取得方法などを示すコード例も含まれています。

B.3 プログラムとスクリプトを使用した構成タスクの管理

ALSBConfigurationMBeanインタフェースを使用すると、Service Busドメインで、リソースの問合せ、エクスポートおよびインポート、検証エラーの取得、環境値の取得と設定、リソース構成の全般的な管理をプログラムで実行できるようになります。

Service Bus構成は、プロキシ・サービス、WSDLファイル、ビジネス・サービスなど、Service Busリソースを含む単純なJARとしてパッケージ化されています。これらのリソースは、複数のプロジェクトにまたがるものにしたり、構成情報の一部だけを含めたりできます。たとえば、プロジェクトのサブセットだけをエクスポートしたり、プロジェクト全体をエクスポートしたり、多数のプロジェクトのリソースのサブセットをエクスポートしたりできます。

ALSBConfigurationMBeanインタフェースのリファレンス資料は、Oracle Service Bus Java APIリファレンスのcom.bea.wli.sb.management.configuration.ALSBConfigurationMBeanのドキュメントを参照してください。

B.3.1 構成のインポート、エクスポートおよび問合せ

Service Busの構成は、Oracle Service Busコンソール、JDeveloperまたはFusion Middleware Controlを使用して作成されます。これらはJARファイルでエクスポートして保存されます。構成JARファイルをエクスポートしておくと、その構成を別のService Busドメインにインポートし、構成に含まれる環境固有の値を新しい環境の値に合せて変更することで、構成をプロモートできます。

ALSBConfigurationMBeanインタフェースのメソッドを使用すると、Service Busドメインで次のようなリソースの管理を行うことができます。

- リソースの問合せ、エクスポート、およびインポート(ZIPファイルからのリソースのインポート、およびプロジェクト・レベルでのリソースのエクスポートを含む)

- 環境値の取得と設定

- 新しいIDを持つプロジェクト、フォルダ、またはリソースのクローンを作成します。

- 指定したリストにあるすべてのリソースからの既存の参照を、新しい参照のセットに変更します。

- 複数のプロパティを同時にカスタマイズします。

- 検証エラーの取得

ALSBConfigurationMBeanインタフェースに用意されているメソッドの詳細は、Oracle Service Bus Java APIリファレンスを参照してください。

B.3.2 環境固有の情報の更新

ALSBConfigurationMBeanおよびCustomizationクラスのメソッドを使用して、環境固有の情報を更新できます。これには、次の作業が含まれます。

- プロキシ・サービスとビジネス・サービスの構成のエンドポイントの値を更新する

- ファイル、電子メールおよびFTPトランスポート構成のディレクトリ要素を更新する

- 環境値を直接設定する

- 問合せに指定されている環境固有の値を検索する

- 問合せに指定されている環境値を検索し、環境値パターンに一致するすべての値を特定のパラメータに置き換える

ALSBConfigurationMBeanおよびCustomizationのメソッドの詳細は、Oracle Service Bus Java APIリファレンスを参照してください。インポートのカスタマイズはALSBImportPlanクラスによってサポートされています。このドキュメントには、Service Busの構成のインポート方法とエクスポート方法、環境値の変更方法、リソースの問合せ方法などを示すコード例も含まれています。

セキュリティ構成と他のすべての環境固有の設定は、Fusion Middleware Controlを使用して対話的に更新する必要があります。

C Oracle Service Busシステムの監査

この付録では、Oracle Service Bus環境の監査に関する一般的なガイドラインについて説明します。

Oracle Service Busシステムでは、サービスをモニターするだけでなく、システムを監査して、システムに対する構成の変更履歴を確認し、実行時にOracle Service Busパイプラインを通過するメッセージのステータスを記録し、パイプライン内のメッセージのセキュリティ違反を記録できます。

この付録の内容は次のとおりです。

- 構成の変更の監査

- メッセージ・フローの監査証跡の作成

- セキュリティ違反の監査

C.1 構成の変更の監査

Oracle Service Busコンソールで構成を変更すると、変更の追跡記録が作成され、構成変更の記録がすべて保持されます。

以前のオブジェクトのイメージのみが保持されます。セッション中に変更された構成変更の履歴とリソースのリストは、Oracle Service Busコンソールを介してのみ、表示およびアクセスが可能です。ただし、構成のすべての情報にアクセスするには、セッションをアクティブ化する必要があります。

C.2 メッセージ・フローの監査証跡の作成

実行中にパイプライン全体を監査するのは時間がかかります。ただし、レポート・アクションを使用すると、実行中のパイプラインの監査を選択して実行できます。

パイプラインの必要なポイントにレポート・アクションを挿入し、必要な情報を抽出します。抽出された情報は、データベースに格納するか、監査レポートを作成するためにレポート・ストリームに送信できます。

C.3 セキュリティ違反の監査

メッセージがプロキシ・サービスに送信され、トランスポート・レベルの認証またはWebサービスのセキュリティの違反があった場合、Oracle WebLogic Serverは監査証跡を生成します。この監査証跡を生成するには、Oracle WebLogic Serverを構成する必要があります。

これにより、パイプラインで発生するすべてのセキュリティ違反を監査できます。また、ユーザーを認証するたびに監査証跡が生成されます。セキュリティの監査の詳細は、『Oracle Service Busでのサービスの開発』のOracle WebLogicセキュリティ・フレームワークの構成: 主な手順に関する項を参照してください。

D WSRPとの相互運用性

この付録では、Oracle Service Busを使用して、Web Services Remote Portlets (WSRP)を使用するアプリケーションでサービス・レベル・アグリーメント(SLA)をモニターする方法について説明しています。 WSRPは、マークアップ・フラグメントをリモート・システムで生成してローカルのポータル・アプリケーションで表示するメカニズムとして使用されます。

この付録の内容は次のとおりです。

- WSRPのプロデューサとコンシューマ

- WSRPのアーキテクチャ

- WSRP設計の概念

D.1 WSRPのプロデューサとコンシューマ

WSRPには、必須のコンポーネントが2つあります。1つはプロデューサであり、もう1つはコンシューマです。

- WSRPプロデューサ(このドキュメントではプロデューサと表記)は、SOAP over HTTP仕様を使用して標準ベースのWebサービスを実装するリモート・アプリケーションです。プロデューサは、WebLogic Portalまたはサード・パーティによるWSRP実装を使用して作成できます。

- WSRPコンシューマ(このドキュメントではコンシューマと表記)は、ポータル・アプリケーションです。通常、コンシューマ・アプリケーションは、ポータル設計時にプロデューサのWSDLドキュメントを参照し、コンシューマはプロデューサに直接アクセスします。

D.2 WSRPのアーキテクチャ

この項では、WSRPのアーキテクチャについて説明し、Oracle Service Busを追加してこのアーキテクチャを拡張する方法を示します。

次の図は、プロデューサ・アプリケーションとコンシューマ・アプリケーション間のWSRP SOAP要求および応答フローを示しています。

図D-1 プロデューサ・アプリケーションとコンシューマ・アプリケーション間の基本のリクエスト/レスポンス・フロー

D.2.1 Oracle Service Busを使用した拡張アーキテクチャ

次の図は、Service Busを使用してプロデューサとコンシューマを仲介することにより、サービス・レベル・アグリーメント(SLA)モニター機能を提供する方法を示しています。

図D-2 Oracle Service Busを使用して拡張されたWSRPのリクエスト/レスポンス・フロー

WSRP SOAPリクエスト/レスポンス・フローは次の順序で行われます。

1. インバウンド・リクエスト: コンシューマがService Busでプロキシ・サービスを呼び出します。

2. アウトバウンド・リクエスト: プロキシ・サービスがリクエスト(SOAP本体とトランスポート・ヘッダーを含むメッセージ)をプロデューサにルーティングします。

3. アウトバウンド・レスポンス: プロデューサがレスポンスをService Busに送信します。

4. インバウンド・レスポンス: プロキシ・サービスがレスポンスをコンシューマに送信します。レスポンスとは、SOAP本体とトランスポート・ヘッダーを含むメッセージです。

Service Busコンポーネントの実際の構成の詳細は、「WSRP対応Oracle Service Busの構成」を参照してください。

D.3 WSRP設計の概念

WSRP設計における2つの主要なコンポーネントは、サービスを記述するWSDLドキュメントと、メッセージング形式を記述するWSDLドキュメントです。

- WSRP WSDLドキュメント

- WSRPメッセージ

D.3.1 WSRP WSDLドキュメント

次の表では、WSDLドキュメントで提供される各種サービスについて説明しています。WSDLドキュメントは、プロデューサと表記しています。

表D-1 プロデューサ・サービス

サービス

説明

サービス記述

必須サービス。プロデューサがコンシューマに使用できるようにする、プロデューサとポートレットについて記述されます。

マークアップ

必須サービス。リモート・ポートレットとのユーザーの対話を管理し、ポートレットのレンダリングに使用されるHTMLマークアップを返します。

登録

オプション・サービス。複雑なプロデューサでは必須です。これを使用してコンシューマがプロデューサに自己登録できます。

管理

オプション・サービス。複雑なプロデューサでポートレットのカスタマイズとポートレットのプリファレンスを管理するために提供されます。

マークアップ拡張機能

Oracle WebLogic Portalプロデューサでマークアップ・サービスのかわりに提供されます。マークアップ拡張機能では、HTMLマークアップ・コンテンツの送信でマルチ・パートMIMEメッセージを使用すると、メッセージ処理の効率が上がります。

各プロデューサは、少なくとも2つのサービス(サービス記述とマークアップなど)を実装します。単純なプロデューサは、これら2つのサービスのみを提供します。複雑なプロデューサは、この他に2つのサービス(登録と管理など)を提供します。また、WebLogic Portalプロデューサは、標準のマークアップ・サービスのかわりに使用できる拡張機能サービス(マークアップ拡張機能など)も実装します。

これらのサービスは、標準のWSDL形式で記述されます。プロデューサは、WSDLドキュメントの取得用に1つのURLを提供します。WSDLには、そのプロデューサが提供するすべてのサービスが記述されています。各サービスのエンド・ポイントによって、コンシューマがプロデューサとの通信にトランスポート・レベルのセキュリティ(HTTPs)を使用する必要があるかどうかが指定されます。

D.3.2 WSRPメッセージ

WSRPは、プロデューサとコンシューマの間で交換されるすべてのメッセージでSOAP over HTTPを使用します。SOAP本体で標準メッセージ形式を使用するだけでなく、WSRPでは、コンシューマは、少なくとも、SOAPActionヘッダー、Cookieヘッダー、および通常のHTTPヘッダー(Content-Typeなど)を設定する必要があります。プロデューサは、セッションCookieとアプリケーション固有のCookieを、レスポンスのHTTPトランスポート・ヘッダーで返します。コンシューマは、後続のリクエスト・メッセージでそのセッションCookieを返す必要があります。

D.4 WSRP対応Oracle Service Busの構成

Service Busのコンポーネントは、Oracle JDeveloperとOracle Service Busコンソールのどちらでも構成できます。

WSRP対応のService Busの構成には、次のタスクが含まれます。

- コンシューマが特定のプロデューサに対応するWSDLドキュメントを取得するために呼び出すことができるサービスを実装する。

- コンシューマのリクエストをプロデューサに渡し、レスポンスをコンシューマに返す詳細を実装する。

次の各項では、プロキシ・サービスを通じてWSRPサービスにリクエストを送信するように、Service Busコンポーネントを構成する方法について説明します。プロデューサで提供されるサービスや、Service Busコンポーネントの構成に使用する必要があるWSRPのその他の属性についても説明します。最後には、詳細度の高いプロデューサのモニタリングと、WSRPによるロード・バランシングおよびフェイルオーバーについての情報を示します。

Oracle WebLogic Portalを使用してWSRP対応ポータルを作成する方法の詳細は、を参照してください。

D.4.1 プロデューサWSDLドキュメントの取得

通常、コンシューマは、プロデューサに直接アクセスしてWSDLドキュメントを取得します。ただし、Service Busをプロキシ・サービスとして使用している場合、プロデューサへのすべてのアクセスはService Busを介して行われます。このため、コンシューマ用のプロキシ・サービスを実装します。このプロキシ・サービスは、プロデューサの実際のURLを呼び出してプロデューサWSDLファイルを取得します。次のようにプロキシ・サービスは結果を変換します。

- プロデューサのエンドポイントのアドレスを、Service BusのIPアドレスとポート番号を参照するように再作成する。

- エンドポイントURIを変更し、必要なモニター・レベルを反映したプロキシ・サービスを参照する(「WSRPアプリケーションのモニター」を参照)。

- エンドポイントのプロトコルとポート番号を変更し、コンシューマとプロキシ・サービスの間でトランスポート・セキュリティを使用するかどうかを反映する。

D.4.2 WSRPプロデューサによるSSLの使用

プロデューサの作成時に、そのプロデューサがSSLを要求するように構成できます("secure=true")。また、Service Bus管理者は、Service Bus構成でコンシューマに対するセキュリティ要件を変更できます。たとえば、プロデューサがSSLを要求しない場合は、次の手順を実行して、コンシューマにSSLの使用を要求できます。

- WSDLファイルを変更して、HTTP(s)を指定します。

- HTTP(s)を使用するように、WSRPプロキシ・サービスを構成します。

このように構成すると、Service Busは、コンシューマからの安全なメッセージとプロデューサが使用する安全でないメッセージを自動的に橋渡しします。

D.4.3 コンシューマとプロデューサの間でのメッセージのルーティング

WSDLファイルのコピーを取得した後、コンシューマはWSDLの定義を使用してサービス・リクエストを作成し、Service Busを使用してプロデューサに送信します。WSRPのリクエスト/レスポンス・プロセスの手順は次のとおりです。

1. コンシューマが、プロデューサ・サービスに対応するService Busプロキシ・サービスにメッセージを送信します。

2. プロキシ・サービスは、メッセージをパイプラインに送信します。このパイプラインは、メッセージを(そのままの状態で)実際のプロデューサ・サービスにルーティングする、単純なメッセージ・フローを実行します。

3. プロデューサはレスポンスを作成し、Service Busを介してコンシューマに送信します。

4. コンシューマは、プロデューサからのレスポンスを(そのままの状態で)受信します。

WSRP Webサービスはポートレットを公開します。それらのポートレットはHTTPのCookieとセッションに依存する場合があります。そのため、HTTPトランスポート・ヘッダー(SOAPActionやCookieなど)を伝播するには、Service Busを構成する必要があります。ただし、プロキシ・サービスとビジネス・サービスが同じトランスポートを使用するとはかぎらないため、デフォルトでは、Service Busは、プロキシ・サービスからビジネス・サービスにトランスポート・ヘッダーを渡しません。そのため、リクエスト・ヘッダーを着信リクエストから発信リクエストにコピーするように、パイプラインを構成する必要があります。同様に、ビジネス・サービスのレスポンス・ヘッダーも、プロキシ・サービスからコンシューマへのレスポンスにコピーする必要があります。

プロキシ・サービスとビジネス・サービスの間で、すべての転送ヘッダーをコピーすることもできますが、選択的に転送ヘッダーコピーすることでエラーを回避できます。Set-CookieヘッダーとCookieヘッダーをコピーする必要があります。Service Busは最終メッセージをアセンブルして送信するため、最終メッセージには、いくつかの独自のヘッダー(Content-Lengthなど)が必要になります。たとえば、メッセージ・フローでContent-Lengthヘッダーをプロキシ・サービスからビジネス・サービスにコピーすると、処理中にメッセージの長さが変化したためにエラーになることがあります。そのため、Service Busはこのヘッダーを独自のものにする必要があります。

D.4.4 WSRPアプリケーションのモニター

WSRPアプリケーションをモニターすることによって、プロデューサの個々のサービスと処理の使用状況を追跡します。WSRPサービスのメッセージ・フローのオーバーヘッドは非常に少なく、プロキシ・サービスとプロデューサ間のマッピング、およびビジネス・サービスとプロデューサ間のマッピングは容易に構成できます。そのため、SLA要件を満たすには、プロキシ・サービスをモニターするだけで十分です。

D.4.5 ロード・バランシングとフェイルオーバー

Service Busでは、ビジネス・サービスに、同じWebサービスを提供する複数のエンドポイントを定義できます。複数のエンドポイントを定義すると、Service Busでは、エンドポイント間でリクエストのロード・バランスを自動的に分散できます。また、1つのエンドポイントがアクセスできなくなると、リクエストを自動的にフェイルオーバーすることもできます。

D.4.5.1 セッション固定性を持たないWSRPの制限

ポートレットは、アプリケーションにユーザー・インタフェースを公開する手段であるため、通常、そのポートレットに関連付けられたセッション・データを保持します。セッション・データを保持するために、ポートレットへのリクエストは、元のリクエストを処理したものと同じサーバー(またはクラスタ)に送信される必要があります。この要件により、ビジネス・プロセスがHTTPセッション固定性に対応するように構成されていないかぎり、Service Busを介したロード・バランシングは不適切になります。ビジネス・サービスの複数のエンドポイントは、通常、異なるサーバーまたはクラスタをターゲットとします。構成されたセッション固定性がなければ、セッションを保存する方法はありません。これは、別々のクラスタにある複数のサーバー間で通信が行われないからです。そのため、WSRPビジネス・サービスに複数のエンドポイントを定義しており、セッション固定性を有効にしていない場合は、ロード・バランシングのアルゴリズムをnoneに設定する必要があります。

特定の環境では、複数のエンドポイントを使用して冗長性を確保し、エンドポイントの1つが使用できなくなった場合に備えることができます。2つ目のエンドポイントでWSRPサービスを利用できます。ただし、最初のエンドポイントが使用できなくなった時点のセッション・データは、他のエンドポイントでは使用できません。このフェイルオーバー構成は、単純なプロデューサのみのオプションであり、複雑なプロデューサでは使用できません(「WSRP WSDLドキュメント」を参照)。複雑なプロデューサでは、サービス・リクエストを送信する前に、コンシューマでプロデューサに登録する必要があります。プロデューサは登録ハンドルを返します。コンシューマは、そのプロデューサへの各リクエストにこのハンドルを含める必要があります。ビジネス・サービスに複数のエンドポイントが定義されている場合、各エンドポイントに個別の登録ハンドルが必要です。

ただし、Service Busは、リクエストとリクエストの間はステートレスであるため、特定のエンドポイントに送信するための正しいハンドルのマッピングは保持されません。実際、登録リクエストは1つのエンドポイントに送信されるので、コンシューマは1つのプロデューサにのみ登録されます。このプロデューサを使用できない場合、Service Busはサービス・リクエストをそのビジネス・サービスに定義されている別のエンドポイントにルーティングします。この新しいプロデューサにはコンシューマが登録されていないため、リクエストはInvalidRegistrationエラーで失敗します。

この状態データを維持するために、登録ハンドルの管理にはService Bus以外のアプリケーションが必要になるため、登録要件では複雑なプロデューサに対して複数のエンドポイントを定義しないでください。単純なプロデューサは、登録サービスをサポートしないため、ビジネス・サービスに対して複数のエンドポイントを定義するフェイルオーバー構成が可能です(ただし、フェイルオーバーの際にセッション・データが失われます)。

D.4.5.2 HTTPセッション固定性を持つWSRPの使用法

複数のエンドポイントを持つHTTPビジネス・サービスでのロード・バランシングの場合、セッション固定性を使用するようにサービスを構成できます(セッション・アフィニティとも呼ばれます)。固定セッションを使用するときには、そのセッションで最初のリクエストを処理したサーバーによってすべてのメッセージが処理されます。セッション固定性はサーバーを再起動する必要なく、実行時に構成できます。

そのセッションで最初のリクエストが送信されると、それはロード・バランシング・アルゴリズムに基づいて最初のURIエンドポイントに送られます。セッションIDは最初のリクエストを処理するURIエンドポイントと結び付けられ、URI表のセッションはそのURIインデックスにマップされます。同じセッション内の後続のリクエストは、ロード・バランシング・アルゴリズムに基づき選択されたはずのURIエンドポイントのかわりに、そのURIエンドポイントに送られます。

セッション固定性はビジネス・サービスの構成に応じて次のように動作します。

- メッセージは、ビジネス・プロセスの再試行構成に基づき、同じURIエンドポイントで再試行されます。最大再試行回数に達するとURIエンドポイントはオフラインとマークされ、Service Busは例外をスローします。

- ビジネス・サービスのURIエンドポイントがメッセージ・フローから動的に構成される場合、セッション固定性が有効になっていてもセッションは固定されません。

- URIエンドポイントがオフラインの場合、セッション固定性はそれ以上維持されません。

- サービスのURI表がセッションの途中で変更され、インデックスがURI表から外れると、TransportExceptionがエラー・コードTransportManager.TRANSPORT_STATUS_APPLICATION_ERRORとともにスローされます。

セッション固定性を持つようにビジネス・プロセスを構成するときには、リクエスト用のCookieヘッダーをインバウンドからアウトバウンドに、およびレスポンス用のCookieヘッダーをアウトバウンドからインバウンドに必ず転送してください。

window.name='GUID-C54BF9DE-02DD-4FFA-946D-7D4755738683' function footdisplay(footnum,footnote) { var msg = window.open('', 'NewWindow' + footnum, 'directories=no,height=120,location=no,menubar=no,resizable=yes,' + 'scrollbars=yes,status=no,toolbar=no,width=598'); msg.document.open('text/html'); }
E Oracle Service Busでのロール・ベースのアクセス

この付録では、Service Busの各セキュリティ・ロールが、Oracle Service BusコンソールおよびFusion Middleware Controlで実行できるアクションのリストを示します。セキュリティ構成の権限は、Oracle WebLogic Server管理者ロールのみに付与されています。

この付録の内容は次のとおりです。

- アプリケーション・セキュリティ・ロール

- エンタープライズ・セキュリティ・ロール

- ロール・ベースのセキュリティ構成アクセス

この付録には、WebLogic ServerまたはFusion Middleware Controlに定義された各ロールにより付与される権限のみを示します。Service Busでのセキュリティの構成方法およびロールの使用方法の詳細は、「Oracle Service Busのアクセス・セキュリティの定義」を参照してください。

E.1 アプリケーション・セキュリティ・ロール

アプリケーション・セキュリティ・ロールは、ユーザーがOracle WebLogic ServerのMonitorsグループのメンバーでもある場合に、Fusion Middleware ControlおよびOracle Service Busコンソールの機能へのアクセスを提供します。

Fusion Middleware ControlのService Busの「セキュリティ」ページから、アプリケーション・ロールをユーザーに割り当てることができます。

E.1.1 Oracle Service Busコンソールでのアプリケーション・ロール・ベースのアクセス

次の各項では、アプリケーション・ロールにより付与されるOracle Service Busコンソールでの権限について説明します。

- リソース・アクションへのアプリケーション・ロール・ベースのアクセス

- 管理機能へのアプリケーション・ロール・ベースのアクセス

- セッション管理へのアプリケーション・ロール・ベースのアクセス

E.1.1.1 リソース・アクションへのアプリケーション・ロール・ベースのアクセス

次の表では、Oracle Service BusコンソールでService Busリソースを操作するために、アプリケーション・ロールにより付与される権限について説明します。次の表でのリソースとは、すべてのService Busリソース(プロキシ・サービス、XMLスキーマ、JNDIプロバイダなど)を指しています。ただし、アラート宛先は除きます。

表E-1 リソースへのアプリケーション・ロール・ベースのアクセス

アクション

Middleware Administrator

Developer

Composer

Deployer

Tester

Middleware Operator

Application Operator

Monitor

リソースの作成

Y

Y

N

N

N

N

N

N

リソースの表示

Y

Y

Y

Y

Y

Y

Y

Y

リソースの編集

Y

Y

N

N

N

N

N

N

リソースの削除

Y

Y

N

Y

N

N

N

N

リソースの移動(システム・リソースを除く)

Y

Y

N

N

N

N

N

N

リソース名の変更

Y

Y

N

N

N

N

N

N

リソースのクローンの作成(UDDIレジスタを除く)

Y

Y

N

N

N

N

N

N

アラート宛先の作成

Y

Y

N

N

N

Y

N

N

アラート宛先の表示

Y

Y

Y

Y

Y

Y

Y

Y

アラート宛先の編集

Y

Y

N

N

N

Y

N

N

アラート宛先の削除

Y

Y

N

Y

N

Y

N

N

アラート宛先の移動

Y

Y

N

N

N

Y

N

N

アラート宛先名の変更

Y

Y

N

N

N

Y

N

N

アラート宛先のクローン作成

Y

Y

N

N

N

Y

N

N

アラート・ルールの作成

Y

Y

N

N

N

Y

N

N

SLAアラート・ルールの表示

Y

Y

Y

Y

Y

Y

Y

Y

SLAアラート・ルールの編集

Y

Y

N

N

N

Y

N

N

SLAアラート・ルールの削除

Y

Y

N

N

N

Y

N

N

プロジェクトおよびフォルダの作成

Y

Y

N

N

N

N

N

N

プロジェクトおよびフォルダの表示

Y

Y

Y

Y

Y

Y

Y

Y

プロジェクトおよびフォルダの編集

Y

Y

N

N

N

N

N

N

プロジェクトおよびフォルダの削除

Y

Y

N

Y

N

N

N

N

テスト・コンソールの実行

Y

Y

N

N

Y

N

N

N

E.1.1.2 管理機能へのアプリケーション・ロール・ベースのアクセス

次の表では、Oracle Service Busコンソールの管理機能に対して、アプリケーション・ロールにより付与される権限について説明します。

表E-2 管理機能へのアプリケーション・ロール・ベースのアクセス

アクション

Middleware管理者

Developer

Composer

Deployer

Tester

Middlewareオペレータ

アプリケーション・オペレータ

Monitor

リソースを構成ファイルまたはZIPファイルからインポート

Y

Y

N

N

N

N

N

N

リソースを構成またはZIPからエクスポート

Y

Y

N

N

N

N

N

N

リソースをURLからインポート

Y

Y

N

N

N

N

N

N

リソースをURLからエクスポート

Y

Y

N

N

N

N

N

N

UDDIからインポート

Y

Y

N

N

N

N

N

N

自動インポート・ステータスの同期化

Y

Y

N

N

N

N

N

N

UDDIのリンク解除

Y

Y

N

N

N

N

N

N

UDDIにパブリッシュ

Y

Y

N

N

N

N

N

N

自動パブリッシュ・ステータス

Y

Y

N

N

N

N

N

N

自動パブリッシュ・ステータスのパブリッシュ

Y

Y

N

N

N

N

N

N

検索置換

Y

Y

N

N

N

N

N

N

構成ファイルの作成

Y

Y

N

N

N

N

N

N

構成ファイルの実行

Y

Y

N

N

N

N

N

N

E.1.1.3 セッション管理へのアプリケーション・ロール・ベースのアクセス

次の表では、アプリケーション・ロールにより付与されるOracle Service Busコンソールでのセッション・アクティビティの権限について説明します。

表E-3 セッション管理へのアプリケーション・ロール・ベースのアクセス

アクション

Middleware管理者

Developer

Composer

Deployer

Tester

Middlewareオペレータ

アプリケーション・オペレータ

Monitor

セッションの編集

Y

Y

N

Y

N

Y

N

N

すべてのセッションの表示

Y

Y

N

Y

N

Y

N

N

変更履歴の表示

Y

Y

N

Y

N

Y

N

N

変更のアクティブ化

Y

Y

N

Y

N

Y

N

N

変更の破棄

Y

Y

N

Y

N

Y

N

N

セッションの終了

Y

Y

N

Y

N

Y

N

N

E.1.2 Fusion Middleware Controlでのアプリケーション・ロール・ベースのアクセス

次の表では、アプリケーション・ロールにより付与されるFusion Middleware ControlのService Busモニター機能と管理機能に対する権限について説明します。

表E-4 Fusion Middleware Controlでのアプリケーション・ロール・ベースのアクセス

アクション

Middleware管理者

Developer

Composer

Deployer

Tester

Middlewareオペレータ

アプリケーション・オペレータ

Monitor

統計の表示

Y

Y

Y

Y

Y

Y

Y

Y

統計のリセット

Y

Y

Y

Y

N

Y

N

N

アラートの表示

Y

Y

Y

Y

Y

Y

Y

Y

アラートの削除

Y

Y

Y

Y

N

Y

N

N

アラート注釈の更新

Y

Y

Y

Y

N

Y

N

N

アラート履歴の表示

Y

Y

Y

Y

Y

Y

Y

Y

グローバル設定の更新

Y

Y

Y

Y

N

Y

N

N

グローバル設定の表示

Y

Y

Y

Y

Y

Y

Y

Y

操作設定の更新

Y

Y

Y

Y

N

Y

N

N

操作設定の表示

Y

Y

Y

Y

Y

Y

Y

Y

メッセージ・レポートの表示

Y

Y

Y

Y

Y

Y

Y

Y

メッセージのパージ

Y

Y

Y

Y

N

Y

N

N

URIのオンライン化またはオフライン化

Y

Y

Y

Y

N

Y

N

N

構成JARファイルのインポートおよびエクスポート

Y

Y

N

Y

N

N

N

N

セキュリティ・ポリシーの更新脚注 1

Y

Y

Y

N

N

N

N

N

リシーケンス・グループの表示

Y

Y

Y

Y

Y

Y

Y

Y

リシーケンス・グループのエラーの解決

Y

Y

Y

N

N

N

Y

N

テスト・コンソールの起動

Y

Y

Y

Y

Y

N

N

N

脚注 1

これらのロールはセキュリティ・ポリシーを更新するためには、WebLogic ServerのAdministratorsグループのメンバーである必要があります。

E.2 エンタープライズ・セキュリティ・ロール

エンタープライズ・セキュリティ・ロールは、ユーザーがOracle WebLogic ServerのMonitorsグループのメンバーでもある場合に、Fusion Middleware ControlおよびOracle Service Busコンソールの機能へのアクセスを提供します。

Fusion Middleware ControlのService Busの「セキュリティ」ページから、アプリケーション・ロールをユーザーに割り当てることができます。

E.2.1 Oracle Service Busコンソールでのエンタープライズ・ロール・ベースのアクセス

次の各項では、エンタープライズ・ロールにより付与されるOracle Service Busコンソールでの権限について説明します。

- リソース・アクションへのエンタープライズ・ロール・ベースのアクセス

- 管理機能へのエンタープライズ・ロール・ベースのアクセス

- セッション管理へのエンタープライズ・ロール・ベースのアクセス

E.2.1.1 リソース・アクションへのエンタープライズ・ロール・ベースのアクセス

次の表では、Oracle Service BusコンソールでService Busリソースを操作するために、エンタープライズ・ロールにより付与される権限について説明します。次の表でのリソースとは、すべてのService Busリソース(プロキシ・サービス、XMLスキーマ、JNDIプロバイダなど)を指しています。ただし、アラート宛先は除きます。

表E-5 リソース・アクションへのエンタープライズ・ロール・ベースのアクセス

アクション

Integration Admin

Integration Deployer

Integration Operator

Integration Monitor

リソースの作成

Y

Y

N

N

リソースの表示

Y

Y

Y

Y

リソースの編集

Y

Y

N

N

リソースの削除

Y

Y

N

N

リソースの移動(システム・リソースを除く)

Y

Y

N

N

リソース名の変更

Y

Y

N

N

リソースのクローンの作成(UDDIレジスタを除く)

Y

Y

N

N

アラート宛先の作成

Y

Y

Y

N

アラート宛先の表示

Y

Y

Y

Y

アラート宛先の編集

Y

Y

Y

N

アラート宛先の削除

Y

Y

Y

N

アラート宛先の移動

Y

Y

Y

N

アラート宛先の名前変更

Y

Y

Y

N

アラート宛先のクローン作成

Y

Y

Y

N

アラート・ルールの作成

Y

Y

Y

N

SLAアラート・ルールの表示

Y

Y

Y

Y

SLAアラート・ルールの編集

Y

Y

Y

N

SLAアラート・ルールの削除

Y

Y

Y

N

プロジェクトおよびフォルダの作成

Y

Y

N

N

プロジェクトおよびフォルダの表示

Y

Y

Y

Y

プロジェクトおよびフォルダの編集

Y

Y

N

N

プロジェクトおよびフォルダの削除

Y

Y

N

N

テスト・コンソールの実行

Y

Y

N

N

E.2.1.2 管理機能へのエンタープライズ・ロール・ベースのアクセス

次の表では、Oracle Service Busコンソールの管理機能に対して、エンタープライズ・ロールにより付与される権限について説明します。

表E-6 管理機能へのエンタープライズ・ロール・ベースのアクセス

アクション

Integration Admin

Integration Deployer

Integration Operator

Integration Monitor

リソースを構成ファイルまたはZIPファイルからインポート

Y

Y

N

N

リソースを構成またはZIPからエクスポート

Y

Y

N

N

リソースをURLからインポート

Y

Y

N

N

リソースをURLからエクスポート

Y

Y

N

N

UDDIからインポート

Y

Y

N

N

自動インポート・ステータスを同期化

Y

Y

Y

Y

UDDIのリンク解除

Y

Y

N

N

UDDIにパブリッシュ

Y

Y

N

N

自動パブリッシュ・ステータス

Y

Y

Y

Y

自動パブリッシュ・ステータスのパブリッシュ

Y

Y

N

N

検索置換

Y

Y

N

N

構成ファイルの作成

Y

Y

N

N

構成ファイルの実行

Y

Y

N

N

E.2.1.3 セッション管理へのエンタープライズ・ロール・ベースのアクセス

次の表では、エンタープライズ・ロールにより付与されるOracle Service Busコンソールでのセッション・アクティビティの権限について説明します。

表E-7 セッション管理へのエンタープライズ・ロール・ベースのアクセス

アクション

Integration Admin

Integration Deployer

Integration Operator

Integration Monitor

セッションの編集

Y

Y

Y

N

すべてのセッションを表示

Y

Y

N

N

変更履歴の表示

Y

Y

Y

N

変更のアクティブ化

Y

Y

Y

N

変更の破棄

Y

Y

Y

N

セッションの終了

Y

Y

Y

N

E.2.2 Fusion Middleware Controlでのエンタープライズ・ロール・ベースのアクセス

次の表では、エンタープライズ・ロールにより付与されるFusion Middleware ControlのService Busモニター機能と管理機能に対する権限について説明します。

表E-8 エンタープライズ・ロール・ベースのモニターおよび管理アクセス

アクション

Integration Admin

Integration Deployer

Integration Operator

Integration Monitor

統計の表示

Y

Y

Y

Y

統計のリセット

Y

Y

Y

N

アラートの表示

Y

Y

Y

Y

アラートの削除

Y

Y

Y

N

アラート注釈の更新

Y

Y

Y

N

アラート履歴の表示

Y

Y

Y

Y

グローバル設定の更新

Y

Y

Y

N

グローバル設定の表示

Y

Y

Y

Y

操作設定の更新

Y

Y

Y

N

操作設定の表示

Y

Y

Y

Y

メッセージ・レポートの表示

Y

Y

Y

Y

メッセージのパージ

Y

Y

Y

N

URIのオンライン化またはオフライン化

Y

Y

Y

N

構成JARファイルのインポートおよびエクスポート

Y

Y

N

N

セキュリティ・ポリシーの更新

Y

Y

N

N

リシーケンス・グループの表示

Y

Y

Y

Y

リシーケンス・グループのエラーの解決

Y

Y

N

N

テスト・コンソールの起動

Y

Y

N

N

E.3 ロール・ベースのセキュリティ構成アクセス

この項では、ユーザー、グループおよびロールのアクセス・セキュリティの定義を実行するタスクの権限について説明します。

表E-9 ロール・ベースのセキュリティ構成アクセス

アクション

Integration Admin

Integration Deployer

Integration Operator

Integration Monitor

ユーザーの作成

N

N

N

N

ユーザーの表示

Y

Y

Y

Y

ユーザーの編集

N

N

N

N

ユーザーの削除

N

N

N

N

グループの作成

N

N

N

N

グループの表示

Y

Y

Y

Y

グループの編集

N

N

N

N

グループの削除

N

N

N

N

ロールの作成

N

N

N

N

ロールの表示

Y

Y

Y

Y

ロールの編集

N

N

N

N

ロールの削除

N

N

N

N

ポリシーの作成

N

N

N

N

ポリシーの表示

Y

Y

Y

Y

ポリシーの編集

N

N

N

N

ポリシーの削除

N

N

N

N

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利について

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

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 Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

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

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

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

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

Oracle Supportへのアクセス

サポートをご契約のお客様には、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を参照してください。