49 SOAコンポジット・アプリケーションのデバッグおよび監査
この章の内容は次のとおりです。
49.1 SOAデバッガの概要
Oracle JDeveloperでは、SOAデバッガを使用して、SOAコンポジット・アプリケーションをテストおよびデバッグできます。SOAデバッガは、Oracle JDeveloper内でトラブルシューティング環境を提供することによって、SOAコンポジット・アプリケーションの開発サイクルを短縮します。これにより、SOAコンポジット・アプリケーションをOracle JDeveloperでビルドし、それをSOAインフラストラクチャにデプロイし、Oracle Enterprise Manager Fusion Middleware Controlを起動して監査証跡とフロー・トレースのテストまたは表示を行ってから、Oracle JDeveloperに戻って作業を繰り返すという時間のかかるプロセスが必要なくなります。かわりに、次に示すコンポーネントのトラブルシューティングのために、Oracle JDeveloperでブレークポイントを設定できます。
-
SOAコンポジット・アプリケーションのバインディング・コンポーネントとサービス・コンポーネント
-
同期および非同期BPELプロセス
-
Oracle BPMプロセス
-
Oracle Service Busパイプライン(『Oracle Service Busでのサービスの開発』のOracle Service Busアプリケーションのデバッグに関する項を参照)
SOAデバッガを使用する際には、次のガイドラインに注意してください。
-
SOAコンポジット・アプリケーション名とOracle JDeveloperのプロジェクト名は同じである必要があります。
-
デバッグ・セッション中に発生したすべてのSOAコンポジット・アプリケーションは、Oracle JDeveloperの現在アクティブなワークスペースに存在する必要があります。
-
デバッグはOracle JDeveloperの設計ビューでのみ実行できます。Oracle Enterprise Manager Fusion Middleware ControlではSOAデバッガを実行できません。
-
デバッグは、ローカライズされたユーザー操作です。別のタスク(インスタンスの検索やOracle Enterprise Manager Fusion Middleware Controlの同じコンポジットの新しいインスタンスの起動など)に切り替える場合は、デバッグ・セッションを閉じます。
-
RESTサービスにブレークポイントは設定できません。
-
Oracle JDeveloperの1つのインストールのSOAコンポジット・アプリケーションでデバッグするために作成したブレークポイントは、他のOracle JDeveloperインストールでは使用できません。ブレークポイントをデバッグ用に再度作成する必要があります。
-
埋込み統合WebLogic Serverを使用しているデバッグ・セッション中に、埋込みサーバーに含まれるOracle Enterprise Manager Fusion Middleware Controlのバージョンを使用して新しいインスタンスを生成したりインスタンスを問い合せることはできません。統合WebLogic Serverの詳細は、『SOA SuiteおよびBusiness Process Management SuiteのQuick Start for Developersのインストール』を参照してください。
-
Java
exec
アクティビティ、XSLTおよびXQueryの変換などの、言語間機能はデバッグできません。 -
Oracle SOA Suiteがインストールされているサーバー上で、SOAコンポジット・アプリケーションをデバッグできます。たとえば、Oracle SOA Suiteが管理対象サーバー上で実行されている場合、クライアントは管理対象サーバーのホストとポートを使用して接続する必要があります。
-
一度に1つのクライアントのみがSOAデバッガに接続できます。
-
同じSOAコンポジット・アプリケーションの複数インスタンスを同時にデバッグできません。ただし、Oracle JDeveloperによってこのアクションは制限されません。これは正しい方法ではありません。SOAデバッガは開発ツールです。ユーザーの責任で、同時にデバッグされるインスタンスをただ1つに保つ必要があります。
-
アダプタ・エンドポイント・エラーは、Oracle JDeveloperのSOAデバッガには表示されません。これらのエラーは、ログ・ファイルに記録されます。
-
サーバーが開発モードの場合にのみデバッグできます。本番モードでのデバッグはサポートされていません。
-
Oracle B2BおよびOracle SOAのHealthcareサービス・コンポーネントおよび参照バインディング・コンポーネントは、両方のコンポーネントでデバッグ・ポイントを設定できる場合でも、SOAデバッガを使用してデバッグすることはできません。
-
SOAコンポジット・アプリケーション対SOAコンポジット・アプリケーションのデバッグはサポートされていません。
49.2 SOAコンポジット・アプリケーションのデバッグ
この項では、Oracle JDeveloperでSOAコンポジット・アプリケーションのブレークポイントを作成し、デバッグする方法を説明します。
ノート:
非常に大きなペイロードを持つSOAコンポジット・アプリケーションのデバッグを試みないでください。このようなデバッグを試みると、SOAデバッガのブレークポイントがアウトバウンド方向でハングします。
49.2.1 SOAデバッガを開始する方法
SOAデバッガを開始するには:
-
統合WebLogic Serverを起動します。Start Server Instanceオプションを使用した統合WebLogic Serverの起動の詳細は、『SOA SuiteおよびBusiness Process Management SuiteのQuick Start for Developersのインストール』の「Oracle SOA Suite Quick Start for Developersのインストール」を参照してください。
-
次のいずれかの方法でSOAデバッガを起動します。これは、単一コンポジットのデバッグに制限されます。
-
SOAコンポジット・エディタ上部にあるデバッガ・アイコン(図49-1を参照)をクリックします。
-
「アプリケーション」ウィンドウでSOAコンポジット・アプリケーションを右クリックして、「デバッグ」を選択します。図49-2に詳細を示します。
図49-2 「アプリケーション」ウィンドウのSOAコンポジット・アプリケーションの「デバッグ」メニュー・オプション
「図49-2 「アプリケーション」ウィンドウのSOAコンポジット・アプリケーションの「デバッグ」メニュー・オプション」の説明
図49-3に示すように、「SOAデバッガ接続設定」ダイアログが表示されます。このダイアログにより、使用するSOAデバッグ・サーバーを定義できます。
-
-
環境に適した値を入力し、「OK」をクリックします。表49-1に詳細を示します。
表49-1 「SOAデバッガ接続設定」ダイアログ
フィールド 説明 ホスト
接続するデバッグ・サーバーを選択します。デフォルトでは、ローカル・ホストの名前が表示されます。これはOracle JDeveloperの埋込み統合WebLogic Serverです。リモート・サーバーを入力することもできます。プロジェクトが別のホストからインポートされると、そこで使用されていたホストがここに表示されます。
ポート
デバッグ・エージェントがリスニングするポートを入力します。デフォルト値は
5004
です。Oracle SOA Suiteの開発者用クイック・インストールを実行すると、デバッグが開発環境で自動的に有効になります。デバッガは、本番モードまたはサーバーがクラスタの一部の場合は有効にできません。開発環境では、setDomainEnv.sh
ファイルに次のプロパティ設定を追加することでデバッガをオーバーライドできます。export SOA_DEBUG_FLAG="true" export SOA_DEBUG_PORT="5004"
タイムアウト
デバッグ・セッションの確立を試みる際に、停止する前にクライアントが待機する必要のある時間を秒単位で指定します。デフォルト値は
5
分です。同期プロセスの場合は、次のようにデフォルト値を増やすことができます。-
Oracle Enterprise Manager Fusion Middleware ControlのSyncMaxWaitTimeプロパティを増やします。詳細は、「トランザクションのタイムアウト値の指定方法」を参照してください。
-
Oracle WebLogic Server管理コンソールで、Enterprise JavaBeansプロパティBPELDeliveryBeanの「アイドル・タイムアウト」と「トランザクション・タイムアウト」の値を増やします。これらのプロパティへのアクセスの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のリモートWebサービスのエラー出力の長時間実行同期コール、または非同期トランザクションが、長時間経過した後にエラーを出して戻る場合に関する項を参照してください。
-
Oracle WebLogic Server管理コンソールのホームページにある「JTA」リンクで、Java Transaction API (JTA)のタイムアウト値を増やしてください。
次回にこのページを表示しない
次にデバッガ・セッションを開始するときにこのダイアログを表示しない場合に選択します。前に定義した設定が使用されます。
「アプリケーション」ウィンドウでプロジェクトを右クリックすることで、このダイアログを再度表示できます。「プロジェクト・プロパティ」→「実行/デバッグ」→「編集」→「ツール設定」→「デバッガ」→「リモート」の順に選択し、「デバッガ接続前にダイアログ・ボックスを表示」チェック・ボックスを選択します。
ノート:
これらのプロパティは、「アプリケーション」ウィンドウでプロジェクトを右クリックし、「プロジェクト・プロパティ」→「実行/デバッグ」→「編集」→「ツール設定」→「デバッガ」→「リモート」の順に選択しても編集できます。
デバッグ対象として選択されたSOAコンポジット・アプリケーションがデプロイされているかどうかを判別するチェックが行われます。表49-2に詳細を示します。
表49-2 SOAコンポジット・アプリケーションがデプロイ済かどうか判別するためのチェック
SOAコンポジット・アプリケーションの状況 結果 デプロイ済
サービス・バインディング・コンポーネントの右側のハンドルに、次のメッセージが表示されます。
Use context menu to initiate WS debugging
このメッセージの例は図49-5を参照してください。
デバッグを開始する準備ができました。「ブレークポイントを設定してデバッグを開始する方法」に進みます。
-
未デプロイ
-
デプロイ済、ただしデプロイ後にコンポジット内で設計変更があった。
ノート: 「同じリビジョンIDで既存のコンポジットを上書きします。」チェック・ボックスを選択して2度目にデプロイされたコンポジットには、追加のデプロイメントは必要ありません。
-
デプロイ済、ただしOracle JDeveloperのシステム・フォルダを削除した。システム・フォルダは、「ヘルプ」→「情報」→「プロパティ」を選択して、ide.system.dirを検索することで特定されます。
-
1つのOracle JDeveloperでデプロイされたが、SOAコンポジット・アプリケーションのZIPファイルはOracle JDeveloperの別のインストールで開かれた。
「Project_Nameのデプロイ」ウィザードの「デプロイメント・アクション」ページが表示され、コンポジットをデプロイする必要があります。
-
「アプリケーション・サーバーにデプロイ」を選択します。
-
ウィザードの各ページの指示に従って、SOAコンポジット・アプリケーションをアプリケーション・サーバーにデプロイします。
SOAコンポジット・アプリケーションのデプロイの詳細は、「プロファイルのデプロイ」を参照してください。
-
デプロイメントが完了したら、「ブレークポイントを設定してデバッグを開始する方法」に進みます。
ログ・ウィンドウに次のメッセージが表示されたら、デバッグ・セッションを開始する準備ができています。
Debugger attempting to connect to remote process at host_name 5004 Debugger connected to remote process at host_name 5004 Debugger process virtual machine is SOA Debugger.
-
49.2.2 ブレークポイントを設定してデバッグを開始する方法
ブレークポイントは、SOAコンポジット・アプリケーション内でデバッグのために設定する意図的な一時停止位置です。次のコンポーネントに対してブレークポイントを設定できます。
-
サービス・バインディング・コンポーネント
-
BPELプロセス・アクティビティおよびBPMプロセスのサービス・コンポーネントのインバウンド部分とアウトバウンド部分
-
Webサービス、JCAアダプタなどの参照バインディング・コンポーネント
-
Oracle Service Busサービス(『Oracle Service Busでのサービスの開発』のOracle Service Busアプリケーションのデバッグに関する項を参照)
ブレークポイントが設定されているコンポーネントは、赤のリクエスト(アウトバウンド)アイコン、リプライ(インバウンド)アイコン、またはリクエスト/リプライ(アウトバウンド/インバウンド)アイコンによって示されます。図49-4に、ブレークポイント・アイコンが設定されているSOAコンポジット・アプリケーションの例を示します。
ブレークポイントを設定してデバッグを開始するには:
-
表49-3に示すように、ブレークポイントを設定するコンポーネントを選択します。
-
サービス・バインディング・コンポーネントにブレークポイントを設定する手順は、次のとおりです。
-
次のメッセージが表示されているサービスの右側のハンドルを右クリックします。
Use context menu to initiate WS debugging
このアクションにより、図49-5に示すコンテキスト・メニューが開きます。
-
表49-4に示すものから、該当するブレークポイント相互作用オプションを選択します。
表49-4 ブレークポイント相互作用オプション
オプション 説明 ブレークポイント・ペアの作成
リクエスト/リプライ(アウトバウンド/インバウンド)相互作用の場合に設定します。これは、リクエストとリプライの両方が重要であるシナリオに役立ちます。
リクエスト・ブレークポイントの作成
リクエスト(アウトバウンド)相互作用の場合に設定します。これは、リクエストのみが重要であるシナリオに役立ちます。
リプレイ・ブレークポイントの作成
リプライ(インバウンド)相互作用の場合に設定します。これは、リプライのみが重要であるシナリオに役立ちます。
WSデバッグの開始
デバッグ・セッションを開始します。たとえば、デバッグ・セッションには、WebサービスからBPELプロセス、アダプタ参照バインディング・コンポーネントへの開始SOAPリクエストが含まれます。
相互作用の選択項目を表す赤のアイコンが追加されます。
たとえば、「ブレークポイント・ペアの作成」を選択した場合は、リクエストとリプライのブレークポイント・アイコンが追加されます。図49-6に詳細を示します。
図49-6 サービス・バインディング・コンポーネントのリクエストおよびリプライのブレークポイント・アイコン
「図49-6 サービス・バインディング・コンポーネントのリクエストおよびリプライのブレークポイント・アイコン」の説明 -
ステップ5に進みます。
-
-
参照バインディング・コンポーネントにブレークポイントを設定する手順は、次のとおりです。
-
サービス・コンポーネントにブレークポイントを設定する手順は、次のとおりです(この例では、BPELプロセスが選択されています)。
-
図49-8に示すように、「編集」を選択します。
これにより、Oracle BPELデザイナでBPELプロセスが開きます。
-
ブレークポイントを設定するBPELアクティビティを右クリックして、「ブレークポイントの切替え」を選択します。図49-9に詳細を示します。
アイコンがアクティビティに追加されます。これらのブレークポイント・アイコンは、単なる赤い点です。これは、フローが必ず1方向に進むからです。ブレークポイントは、常に、非同期BPELプロセス内の最初のアクティビティに設定することをお薦めします。
-
ブレークポイントを無効にするには、右クリックして「ブレークポイントの切替え」を再び選択します。赤いドットが削除されます。BPELプロセス内のすべてのブレークポイントのリストを表示するには、アクティビティを右クリックして「ブレークポイント」を選択します。このダイアログでは、ブレークポイントを有効化および無効化することもできます。
-
ステップ5に進みます。
-
-
SOAコンポジット・アプリケーションのデバッグを開始するには、図49-5に示すサービス・バインディング・コンポーネントの右側のハンドルを右クリックして、メニューから「WSデバッグの開始」を選択します。
これによりHTTPアナライザが起動します。
-
送信するリクエスト・メッセージ・データを入力して「リクエストの送信」をクリックするか、「HTTPコンテンツ」をクリックし、XMLファイルからコンテンツをコピーして貼り付けます。フィールドごとにデータを入力するか、XMLドキュメントをコピー・アンド・ペーストできます。図49-10に詳細を示します。
デバッガは、最初に設定したブレークポイントで停止します(この例では、サービス・バインディング・コンポーネントで)。
-
Oracle JDeveloperの下部にあるログ・ウィンドウで、「データ」をクリックします。
-
メッセージのコンテンツを展開します。図49-11に詳細を示します。値をダブルクリックして変更できます。XML以外の変数では、右クリックして「値の表示」を選択します(たとえば、データベース・アダプタから返されるメッセージ)。
49.2.3 デバッグ・セッションでのステップ実行方法
ブレークポイントを作成すると、図49-12に示すように、対応するフレームが「構造」ウィンドウに作成されます。このフレームは、サービス・バインディング・コンポーネントのリクエスト/リプライ・エントリ・ポイント用に作成されたものです。
フレームとは場所のことです。フレームのスタックは、現在の場所までの各場所のブレッド・クラム証跡です。これは、スタック・トレースと同じです。自分の場所およびそこに進むための方法を示します。フレームは、ブレークポイントとは関係なく作成されます。ブレークポイントで停止すると、「構造」ウィンドウでそれまでに作成したすべてのフレームが表示されます。スタック・フレームにも、その時点に存在したデータが含まれています。「構造」ペインで別のスタック・フレームをクリックしても、「データ」タブが更新されます。
たとえば、参照用にBPELプロセスに接続されたWebサービスがあるときに、参照にブレークポイントを設定した場合、スタックは多くの場合、次のように表示されます。
-
参照
-
BPEL起動
-
BPELスコープ
-
Webサービス
「Webサービス」フレームをクリックすると、「データ」タブにSOAPペイロードが表示されます。次に「BPEL起動」フレームをクリックすると、様々なBPEL変数およびその他の詳細が「データ」タブに表示されます。
フレームをステップ実行して、別のロケーション(別のブレークポイントなど)からデバッグを開始できます。この例では、LoanProcess BPELプロセスから開始します。デバッグに進むと、次のフレームが作成されます。フレームは、変数が存在する場所です。
-
「スコープ」フレーム: スコープ変数が含まれています。
-
「プロセス」フレーム: グローバル変数が含まれています。
変数は、上のフレームから下のフレームまで、プロセスから参照できます。フレームは、「構造」ウィンドウに表示されます。
デバッグ・セッションでステップ実行するには:
49.3 HTTPアナライザを使用したSOAコンポジット・アプリケーションのテスト
Oracle JDeveloperのHTTPアナライザを使用して、SOAコンポジット・アプリケーション内のHTTPリクエストとレスポンスをテストできます。HTTPアナライザを使用して、HTTPリクエスト/レスポンス・パッケージ・ペアのコンテンツを検査できます。リクエスト・パッケージの内容を編集して再送信し、戻されるレスポンス・パケットを確認できます。HTTPアナライザの詳細は、Oracle JDeveloperによるアプリケーションの開発の「Javaプロジェクトの監査と監視」を参照してください。
HTTPアナライザを使用してSOAコンポジット・アプリケーションをテストするには:
「Webサービスのテスト」ページを使用してもテストを実行できます。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のビジネス・フローのテスト・インスタンスの起動に関する項を参照してください。
49.4 BPELアクティビティ・レベルでのSOAコンポジット・アプリケーションの監査
監査証跡データは、データベースに永続保存される状態データの大きな割合を占めることがよくあります。永続保存される状態データの量を削減するために、BPELプロセス・アクティビティ・レベルで細分性の高い監査レベルを指定できます。これらの設定は、サービス・コンポーネント、SOAコンポジット・アプリケーション、BPELプロセス・サービス・エンジン、およびSOAインフラストラクチャのレベルで構成された監査証跡設定より優先されます。
次の手順を実行します。
-
SOAコンポジット・アプリケーション内でBPELアクティビティに対して実行する監査のレベルを定義する、監査ポリシーXMLファイルを作成および構成します。
-
監査ポリシーをBPELプロセスにバインドする監査ポリシー・バインディングXMLファイルを作成し、構成します。
-
composite.xml
ファイルと同じディレクトリ・ロケーション、またはcomposite.xml
ファイル内のプロパティで指定した別のディレクトリに、これらのファイルを配置します。 -
SOAコンポジット・アプリケーションをSOAインフラストラクチャにデプロイします。
-
Oracle Enterprise Manager Fusion Middleware ControlのSOAコンポジット・アプリケーションのフロー・トレース内で、BPELプロセス・アクティビティの監査証跡を表示します。
次のガイドラインに留意してください。
-
監査ポリシーは、標準のBPEL 1.1および2.0のアクティビティおよびスコープと、BPEL拡張アクティビティ(たとえば、電子メール、通知、その他すべて)の両方の監査をサポートします。親スコープ内で、監査対象にする特定の子スコープ、および監査対象にしないその他の子スコープを構成できます。
-
サポートされる監査レベルを表49-7に示します。
表49-7 監査レベル
レベル 説明 Inherit
ロギングは、Oracle Enterprise Manager Fusion Middleware Controlの「SOAインフラストラクチャの共通プロパティ」ページで設定したSOAインフラストラクチャ監査レベルと一致します。これがデフォルトの設定です。
Production
ビジネス・フロー・インスタンスに関する最小限の情報が収集されます。たとえば、BPELプロセス・サービス・エンジンはペイロードを収集しません。したがって、フローの監査証跡でペイロード詳細は使用できません。このレベルは、標準の操作とテストに最適です。
Development
BPELプロセス・アクティビティに関する完全な情報が収集されます。このオプションを選択すると、コンポジット・インスタンスのトラッキングとペイロード・トラッキングの両方が実行されます。ただし、メッセージ・フローの各ステップでペイロードが格納されるため、パフォーマンスに影響を与える可能性があります。この設定は、デバッグする際に便利です。
Off
ロギングは実行されません。コンポジット・インスタンスのトラッキング情報とペイロード・トラッキング情報は収集されません。
-
フォルト・ポリシー・バインディング・ファイルでは、プロセス名とリビジョン番号のワイルドカード・マッチングがサポートされています。たとえば:
-
Order*
と入力すると、コンポジットOrderProcess
、OrderRejected
、およびOrderConfirmed
に含まれるBPELプロセス・サービス・コンポーネントに一致します。<process auditPolicy="noLoops" name="Order*"/>
-
1*
と入力すると、コンポジット・リビジョン1.0
、1.1
、および1.2
に一致します。<process auditPolicy="noAssign" name="*" revision="1.*"/>
-
次の例は、使用する監査ポリシー・スキーマを示しています。
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="http://schemas.oracle.com/bpel/auditpolicy" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://schemas.oracle.com/bpel/auditpolicy" elementFormDefault="qualified"> <!-- activity can have a type or a name as optional attribute.--> <!-- Audit rules apply to all activities if no specific type or name is --> <!-- provided --> <xs:complexType name="Activity"> <xs:attribute name="type" type="xs:QName" use="optional"/> <xs:attribute name="name" type="tns:idType" use="optional"/> <xs:attribute name="auditLevel" type="tns:auditLevelType" use="required"/> </xs:complexType> <xs:simpleType name="idType"> <xs:restriction base="xs:string"> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="auditLevelType"> <xs:restriction base="xs:string"> <xs:enumeration value="off"/> <xs:enumeration value="minimal"/> <xs:enumeration value="production"/> <xs:enumeration value="development"/> </xs:restriction> </xs:simpleType> <xs:element name="auditPolicy"> <xs:complexType> <xs:sequence> <xs:element name="activity" type="tns:Activity" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="id" type="tns:idType" use="required"/> <xs:attribute name="version" type="xs:string" default="1.0"/> </xs:complexType> <!-- we restrict users to provide mulitple rules for same activity --> <xs:key name="UniqueActivity"> <xs:selector xpath="tns:activity"/> <xs:field xpath="@type"/> <xs:field xpath="@name"/> </xs:key> </xs:element> </xs:schema>
次の例は、使用する監査ポリシー・バインディング・スキーマを示しています。
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="http://schemas.oracle.com/bpel/auditpolicyBinding" xmlns:tns="http://schemas.oracle.com/bpel/auditpolicy" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:complexType name="Process"> <xs:attribute name="auditPolicyId" type="tns:idType" use="optional"/> <xs:attribute name="name" type="tns:idType" use="optional"/> <xs:attribute name="revision" type="tns:idType" use="optional"/> </xs:complexType> <xs:simpleType name="idType"> <xs:restriction base="xs:string"> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> <xs:element name="auditPolicyBinding"> <xs:complexType> <xs:sequence> <xs:element name="process" type="tns:Process" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="version" type="xs:string" default="1.0"/> </xs:complexType> <xs:key name="UniqueActivity"> <xs:selector xpath="tns:process"/> <xs:field xpath="@name"/> <xs:field xpath="@revision"/> </xs:key> </xs:element> </xs:schema>