この章の内容は次のとおりです。
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コンポジット・アプリケーションのデバッグはサポートされていません。
この項では、Oracle JDeveloperでSOAコンポジット・アプリケーションのブレークポイントを作成し、デバッグする方法を説明します。
注意:
非常に大きなペイロードを持つSOAコンポジット・アプリケーションのデバッグを試みないでください。このようなデバッグを試みると、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-3に示すように、「SOAデバッガ接続設定」ダイアログが表示されます。このダイアログにより、使用するSOAデバッグ・サーバーを定義できます。
環境に適した値を入力し、「OK」をクリックします。表49-1に詳細を示します。
表49-1 「SOAデバッガ接続設定」ダイアログ
フィールド | 説明 |
---|---|
ホスト |
接続するデバッグ・サーバーを選択します。デフォルトでは、ローカル・ホストの名前が表示されます。これはOracle JDeveloperの埋込み統合WebLogic Serverです。リモート・サーバーを入力することもできます。プロジェクトが別のホストからインポートされると、そこで使用されていたホストがここに表示されます。 |
ポート |
デバッグ・エージェントがリスニングするポートを入力します。デフォルト値は export SOA_DEBUG_FLAG="true" export SOA_DEBUG_PORT="5004" |
タイムアウト |
デバッグ・セッションの確立を試みる際に、停止する前にクライアントが待機する必要のある時間を秒単位で指定します。デフォルト値は
|
次回にこのページを表示しない |
次にデバッガ・セッションを開始するときにこのダイアログを表示しない場合に選択します。前に定義した設定が使用されます。 「アプリケーション」ウィンドウでプロジェクトを右クリックすることで、このダイアログを再度表示できます。「プロジェクト・プロパティ」→「実行/デバッグ」→「編集」→「ツール設定」→「デバッガ」→「リモート」の順に選択し、「デバッガ接続前にダイアログ・ボックスを表示」チェック・ボックスを選択します。 |
注意:
これらのプロパティは、「アプリケーション」ウィンドウでプロジェクトを右クリックし、「プロジェクト・プロパティ」→「実行/デバッグ」→「編集」→「ツール設定」→「デバッガ」→「リモート」の順に選択しても編集できます。
デバッグ対象として選択されたSOAコンポジット・アプリケーションがデプロイされているかどうかを判別するチェックが行われます。表49-2に詳細を示します。
表49-2 SOAコンポジット・アプリケーションがデプロイ済かどうか判別するためのチェック
SOAコンポジット・アプリケーションの状況 | 結果 |
---|---|
デプロイ済 |
サービス・バインディング・コンポーネントの右側のハンドルに、次のメッセージが表示されます。 Use context menu to initiate WS debugging このメッセージの例は図49-5を参照してください。 デバッグを開始する準備ができました。「ブレークポイントを設定してデバッグを開始する方法」に進みます。 |
|
「Project_Nameのデプロイ」ウィザードの「デプロイメント・アクション」ページが表示され、コンポジットをデプロイする必要があります。
|
ログ・ウィンドウに次のメッセージが表示されたら、デバッグ・セッションを開始する準備ができています。
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.
ブレークポイントは、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 サービス・バインディング・コンポーネントのリクエストおよびリプライのブレークポイント・アイコン
ステップ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-12に示すように、対応するフレームが「構造」ウィンドウに作成されます。このフレームは、サービス・バインディング・コンポーネントのリクエスト/リプライ・エントリ・ポイント用に作成されたものです。
フレームとは場所のことです。フレームのスタックは、現在の場所までの各場所のブレッド・クラム証跡です。これは、スタック・トレースと同じです。自分の場所およびそこに進むための方法を示します。フレームは、ブレークポイントとは関係なく作成されます。ブレークポイントで停止すると、「構造」ウィンドウでそれまでに作成したすべてのフレームが表示されます。スタック・フレームにも、その時点に存在したデータが含まれています。「構造」ペインで別のスタック・フレームをクリックしても、「データ」タブが更新されます。
たとえば、参照用にBPELプロセスに接続されたWebサービスがあるときに、参照にブレークポイントを設定した場合、スタックは多くの場合、次のように表示されます。
参照
BPEL起動
BPELスコープ
Webサービス
「Webサービス」フレームをクリックすると、「データ」タブにSOAPペイロードが表示されます。次に「BPEL起動」フレームをクリックすると、様々なBPEL変数およびその他の詳細が「データ」タブに表示されます。
フレームをステップ実行して、別のロケーション(別のブレークポイントなど)からデバッグを開始できます。この例では、LoanProcess BPELプロセスから開始します。デバッグに進むと、次のフレームが作成されます。フレームは、変数が存在する場所です。
「スコープ」フレーム: スコープ変数が含まれています。
「プロセス」フレーム: グローバル変数が含まれています。
変数は、上のフレームから下のフレームまで、プロセスから参照できます。フレームは、「構造」ウィンドウに表示されます。
デバッグ・セッションでステップ実行するには:
Oracle JDeveloperのHTTPアナライザを使用して、SOAコンポジット・アプリケーション内のHTTPリクエストとレスポンスをテストできます。HTTPアナライザを使用して、HTTPリクエスト/レスポンス・パッケージ・ペアのコンテンツを検査できます。リクエスト・パッケージの内容を編集して再送信し、戻されるレスポンス・パケットを確認できます。HTTPアナライザの詳細は、Oracle JDeveloperによるアプリケーションの開発の「Javaプロジェクトの監査と監視」を参照してください。
HTTPアナライザを使用してSOAコンポジット・アプリケーションをテストする手順は、次のとおりです。
「Webサービスのテスト」ページを使用してもテストを実行できます。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のビジネス・フローのテスト・インスタンスの起動に関する項を参照してください。
監査証跡データは、データベースに永続保存される状態データの大きな割合を占めることがよくあります。永続保存される状態データの量を削減するために、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 監査レベル
レベル | 説明 |
---|---|
|
ロギングは、Oracle Enterprise Manager Fusion Middleware Controlの「SOAインフラストラクチャの共通プロパティ」ページで設定したSOAインフラストラクチャ監査レベルと一致します。これがデフォルトの設定です。 |
|
ビジネス・フロー・インスタンスに関する最小限の情報が収集されます。たとえば、BPELプロセス・サービス・エンジンはペイロードを収集しません。したがって、フローの監査証跡でペイロード詳細は使用できません。このレベルは、標準の操作とテストに最適です。 |
|
BPELプロセス・アクティビティに関する完全な情報が収集されます。このオプションを選択すると、コンポジット・インスタンスのトラッキングとペイロード・トラッキングの両方が実行されます。ただし、メッセージ・フローの各ステップでペイロードが格納されるため、パフォーマンスに影響を与える可能性があります。この設定は、デバッグする際に便利です。 |
|
ロギングは実行されません。コンポジット・インスタンスのトラッキング情報とペイロード・トラッキング情報は収集されません。 |
フォルト・ポリシー・バインディング・ファイルでは、プロセス名とリビジョン番号のワイルドカード・マッチングがサポートされています。次に例を示します。
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>