この章では、メッセージ・フローでブレークポイントを設定し、JDeveloperデバッガを使用して、Service Busのパイプラインおよび分割-結合をデバッグする方法を説明します。次の項が含まれます:
JDeveloperは、Service Busプロジェクト・コンポーネントを評価し強化するために役立つ包括的な統合デバッガを提供します。デバッガは、開発環境内に直接トラブルシューティング機能を提供することで、開発サイクルを短縮します。つまり、JDeveloperでService Busアプリケーションを構築して実行し、JDeveloperに戻って問題を修正し、これらの手順を繰り返すという必要はありません。かわりに、パイプラインと分割-結合をトラブルシューティングするためのブレークポイントをJDeveloper内で直接設定できます。
デバッガでは、Javaコールアウトを処理できます。また、並列処理を使用する分割-結合でのマルチ・スレッド・デバッグをサポートします。デバッガを使用するときは次のガイドラインに留意してください。
デバッグは、JDeveloperのデザイン・ビューに制限されています。
Javaコールアウト・アクション、XQueryの変換など、ほとんどの言語間機能はデバッグできません。XSLTマップのデバッグは、12.2.1リリースで新しくサポートされています。詳細は、「XSLTエディタのデバッグ・サポート」を参照してください。
一度に1つのクライアントのみがデバッガに接続できます。
サーバーが開発モードの場合にのみデバッグできます。
デバッガは本番モード、あるいはサーバーがクラスタの一部か非クラスタドメインの管理サーバーと1つ以上の管理対象サーバーの場合には有効にできません。
SOAデバッガを使用するその他のガイドラインについては、Oracle SOA SuiteでのSOAアプリケーションの開発のSOAデバッガの概要に関する項を参照してください。
デバッガ・ウィンドウの一般的な情報は、『Oracle JDeveloperによるアプリケーションの開発』のJavaプロジェクトの実行およびデバッグに関する項を参照してください。
統合またはスタンドアロンのWebLogic ServerにデプロイされているService Busコンポーネントをデバッグできます。JDeveloperではローカル統合WebLogic Serverインスタンスのライフサイクルを管理できます。ローカル統合サーバーを構成する場合は、「JDeveloperでこのサーバー・インスタンスのライフサイクルを管理します」を選択できます。この構成では、JDeveloperは、ユーザーが実行コマンドまたはデバッグ・コマンドを選択したときにサーバーを起動します。統合サーバーがJDeveloperによって管理されるように構成されていない場合は、サーバーを手動で起動および停止する必要があります。ただし、引き続き実行コマンドを使用して、テストするサービスをサーバーにデプロイできます。統合サーバーがリモートの場合、「JDeveloperでこのサーバー・インスタンスのライフサイクルを管理します」は選択しないでください。
デバッグ用にスタンドアロン・サーバーを使用する場合は、それがローカルであるか、リモートであるかに関係なく構成は同じです。アプリケーション・プロパティでサーバーを構成する必要はありません。スタンドアロン・サーバーでは、アプリケーション・ナビゲータから実行コマンドを使用できません。そのかわりに、デプロイ・コマンドを使用してService Busアプリケーションをサーバーに手動でデプロイし、テスト・コンソールを手動で起動する必要があります。
デバッグは、ローカルまたはリモートのいずれかのWebLogic Serverで実行できます。ローカルのデバッグ・セッションは、ソース・ファイルにブレークポイントを設定してからデバッガを起動することで、開始されます。Service Busコンポーネントのデバッグ時には、実行フローを完全に制御し、変数の値を表示および変更できます。
リモート・デバッグには、デバッガとデバッグ対象の2つのJDeveloperプロセスが必要です。デバッグ対象は実行中のサーバーで、JDeveloperで定義されている場合もあれば定義されていない場合もあり、異なるプラットフォームに常駐していることもあります。デバッグ対象サーバーには、Service Busアプリケーションがデプロイされている必要があります。リモート・デバッグを実行するには、「リモート・デバッグ用実行構成の作成方法」に説明されているとおり、プロジェクト・プロパティで実行構成を構成する必要があります。
ブレークポイントは、パイプラインまたは分割-結合内でメッセージ処理を一時停止するポイントをマークします。これによって、一部またはすべてのメッセージ変数の値を確認できます。メッセージ・フローの考えられる問題領域にブレークポイントを設定することで、デバッグする位置に達するまでメッセージ・フローを通じてデータを実行できます。ブレークポイントに達すると、メッセージ処理は一時停止し、デバッガはソース・エディタ内のブレークポイントを含むアクションに着目します。その後、デバッガを使用してプログラムの状態を表示できます。ブレークポイントは、デバッグを開始する前に、またはデバッグ中に随時、柔軟に設定できます。
ブレークポイントは、パイプライン上の次のノードに追加できます。
ルート・ノード
ルート・アクション
ブランチ・ノード
パイプライン・ペア・パス(リクエストまたはレスポンス)
ステージ(パイプライン・ペアとエラー・ハンドラの両方)
ステージ・アクション(パイプライン・ペアとエラー・ハンドラの両方)
すべての分割-結合アクションにブレークポイントを追加できますが、Ifノードでブレークポイントを切り替えると、Ifノード自体ではなく、Ifノード内のIf条件のブレークポイントが切り替わります。
指定した条件がtrueのとき、条件ブレークポイントでコード実行が停止します。条件ブレークポイントは、このリリースのService BusおよびJDeveloperでサポートされています。Service Busアプリケーションのデバッグに使用するブレークポイントには、条件を追加できます。
trueまたはfalseを評価する有効なJavaScript式を、ブレークポイントの条件式として使用できます。式がtrueと評価された場合、または式が無効であるか、ブール値として評価されない場合は、実行が停止されます。ブレークポイントに有効な条件式は1つのみにしてください。
また、パス数を使用すると、トリガーされなくても、指定した回数までブレークポイントをパスした場合にコード実行が停止されます。条件式とパス数は同時に使用できます。
詳細は、次のトピックを参照してください。
ブレークポイント・オプションの編集方法: ブレークポイントの「条件」タブの編集による、条件式またはパス数の追加
条件式の動作: JDeveloperでの条件式の動作
パス数について: JDeveloperでのパス数の動作
条件式およびパス数の同時使用: 条件式とパス数の同時使用
JDeveloperでService Busコンポーネントをデバッグする場合に、ブレークポイントに条件式を作成するときは、これらのガイドラインに従います。
式は最上位のスタック・フレームのデータ値のみを参照する可能性があります。図57-1に示す例について考えます。
この例では、次の式のいずれも有効な条件式になります。
$inbound.security.transportClient.username == “fred”
$body.search(“aqz3”)
$messageID.indexOf(“8087”) > -1
Service Busのほとんどのデータ値がXMLタイプであるため、1つの親の元に同じ名前のアイテムが複数ある場合があります。この構造のタイプは、条件式で配列として扱います。図57-1の$inbound.security.transportClient.principals
の構造について考えます。この場所には、4つの要素があります。このグループの特定の要素にアクセスするには、次の条件式を使用できます。
$inbound.security.transportClient.principals[0] == “AdminChannelUsers”
$inbound.security.transportClient.principals[3] == “Monitors”
図57-1では、$outbound
変数の値はnull
です。この場合、null
は文字列値です。null
文字列値を表現する、正しい条件式は$outbound == “null”
です。$outbound
変数の値がない場合は、正しい条件式は$outbound == “”
になります。
条件式では、空白は変数名の文字として使用できません。変数名の空白は、アンダースコア(_)に変更する必要があります。図57-1のJava Repository
変数を例として使用すると、変数は、条件式でJava_Repository.jcid:null == “ref”
のように参照され、変数名(Java Repository
)はアンダースコアに置換されます(Java_Repository
)。
条件式が(論理的または構文上)無効な式の場合や、なんらかの理由でブール値として評価されない場合、評価に失敗したことが通知されます。
これらの通知は、クリアしなければ、残りのJDeveloperセッションにも使用できます。通知の他にも、JDeveloperは条件式の評価エラーをログに記録します。
パス数は、停止するまでにブレークポイントをパスする実行中の回数を指定する値です。この値に達すると、ブレークポイントでコード実行を停止します。パス数は、このバージョンのService BusおよびJDeveloperのブレークポイントでサポートされています。
「パス数」が設定されているブレークポイントをプロセスの実行に使用する場合、デバッガはカウント数を1ずつ減らし、それを0と比較します。結果がゼロでない場合、実行はそのブレークポイントで停止せずに続行されます。結果がゼロの場合、実行はそのブレークポイントで停止します。パス数が一致した後、現在のプロセスの残りについてもブレークポイントごとに実行が停止します。
注意:
パス数がゼロに達した後、次に示すように、パス数がリセットまたはクリアされるまでブレークポイントごとに実行が停止します。
パス数は次の場合にリセットされます。
デバッグ・セッションが終了し、再開したとき。
「ブレークポイントの編集」ダイアログの「パスの回数」フィールドの値を更新したとき。
ブレークポイントからパス数をクリアするには、「ブレークポイントの編集」ダイアログでその値をゼロに設定します。
どの位置で実行を停止するかを指定する標準のブレークポイントとは異なり、例外ブレークポイントは、指定したタイプの例外の発生源で実行を停止します。例外ブレークポイントは、このリリースのService BusおよびJDeveloperでサポートされています。例外ブレークポイントは、パイプラインと分割-結合に対して作成できます。
例外ブレークポイントがトリガーされると、デバッグ・フレームワークが通知され、実行を停止する位置が示されます。実行が停止されると、次の情報について確認できます。
発生した例外タイプ。これはワイルドカードを使用して例外ブレークポイントを作成した場合に役立ちます
例外に関するメッセージ
ランタイムでスローされたベースとなる例外のスタック・トレース(使用可能な場合)
実行が停止したときのスタック・フレームおよびデータ値。
有効な複数の例外ブレークポイントが発生した例外タイプと一致する場合、デバッグ・フレームワークでは、例外と完全に一致するブレークポイント(たとえば、ワイルドカードを使用していない例外ブレークポイントなど)、またはワイルドカードが設定されている最初のブレークポイントが選択されます。
例外ブレークポイントでは、条件式とパス数がサポートされています。条件式とパス数に関する詳細は、「条件ブレークポイントについて」を参照してください。
Service Busコンポーネントでの例外ブレークポイントの使用に関する詳細は、次のトピックを参照してください。
パイプライン・ランタイムはPipelineException
例外をスローします。PipelineExceptions
には、(エラーの生成アクションを使用して)設定できるエラー・コード、または各アクションごとに設定されるエラー・コードが含まれます。
パイプライン例外ブレークポイントには、次の例外タイプを選択できます。
すべてのパイプライン例外: このタイプを使用すると、任意のパイプライン例外が(特に明示的なエラー・コードがなく)スローされたときに、実行が停止されます。
パイプライン例外: このタイプを使用すると、明示的なエラー・コードのあるパイプライン例外がスローされたときに実行が停止されます。たとえば、382510を「エラー・コード」フィールドに入力すると、エラー・コード382510のパイプライン例外がスローされたときに実行が停止されます。
ヒント:
「エラー・コード」フィールドにアスタリスク(*)を入力すると、任意のパイプライン固有の例外を検索できます。
システム例外:
このタイプは、ランタイムによってスローされる、予期しない例外に使用します。パイプライン例外ブレークポイントの追加については、「Service Busコンポーネントに例外ブレークポイントを設定する方法」を参照してください。
分割-結合はBPEL言語に基づいています。BPELエラー処理フレームワークでは、フォルトおよびフォルト・ハンドラを使用します。フォルトはQNamesによって定義されます。分割-結合には一連のBPEL言語定義フォルトがあります。また、独自のフォルトを手動で定義するか、WSDLフォルトを使用して定義できます。
分割-結合例外ブレークポイントには、次の例外タイプを選択できます。
すべての分割-結合例外: このタイプを使用すると、任意の分割-結合例外がスローされたときに、実行が停止されます。
すべてのシステム例外: この例外タイプを使用すると、任意のランタイム例外がスローされたときに、実行が停止されます。
分割-結合例外: このタイプを使用すると、特定の分割-結合エラーがスローされたときに、実行が停止されます。たとえば、userFaultを「エラー・コード」フィールドに入力すると、userFault
という分割-結合エラーがスローされたときに実行が停止されます。
システム例外: このタイプを使用すると、特定のランタイム・エラーがスローされたときに、実行が停止されます。
分割-結合例外ブレークポイントの追加については、「Service Busコンポーネントに例外ブレークポイントを設定する方法」を参照してください。
デバッグ・プロセスを制御するため、プロジェクトおよびデバッガの設定を構成できます。プログラムのデバッグまたは実行方法を制御する設定は実行構成で定義されます。これらの設定には、ターゲット、起動オプションおよびデバッガ、ログ出力、プロファイラの動作などが含まれます。Service Busは、ローカルでのデバッグおよびテスト用のデフォルトの実行構成を提供していますが、新しい構成を作成することもできます。1つのプロジェクトに、それぞれプロジェクトの特定のファセットまたは開発プロセスのフェーズに対応して設定されている複数の実行構成が存在する場合があります。実行構成は、プロジェクトにバインドされ、プロジェクトで作業する全員が使用できる場合もあれば、自分専用のカスタム構成の場合もあります。
これらの手順はオプションで、統合サーバーでデフォルト構成を使用してローカル・デバッグを実行できます。詳細と手順は、『Oracle JDeveloperによるアプリケーションの開発』の次のトピックを参照してください。
デバッグ用にプロジェクトを構成する方法
デバッガ開始オプションの設定方法
実行用のプロジェクトの構成
Service Busが提供するデフォルト構成などの既存の構成をコピーして、新しい実行構成を作成します。コピー後に、新しい構成に応じて設定を変更します
リモート・デバッグ用に実行構成を作成するには:
ヒント:
実行構成ウィンドウで作業するウィンドウとフィールドの詳細を参照するには、「ヘルプ」をクリックしてください。
デフォルトの実行構成は、新しいプロジェクトごとに作成され、ローカル・デバッグに統合WebLogic Serverを使用します。このデフォルト構成または作成した他の構成を選択して、選択したプロジェクトを実行できます。JDeveloperツールバーからデバッガを実行する場合は、「デバッグ」アイコンの横にある使用可能な構成オプションのリストから実行構成を選択できます。
デバッグ用に実行構成を選択するには:
JDeveloperデバッガを起動する方法は複数あります。この章に記載された手順では、アプリケーション・ナビゲータを使用してデバッガを起動しますが、準備が整った時点で次のいずれかの方法を使用してデバッガを起動できます。
アプリケーション内のプロジェクトまたはコンポーネントを右クリックし、「デバッグ」を選択します。
JDeveloperツールバーで、「デバッグ」アイコンをクリックします。デバッグ・プロセスは選択された実行構成を使用します。「デバッグ用に実行構成を選択する方法」を参照してください。
Service Busコンポジット概要エディタでパイプラインまたは分割-結合を右クリックし、「デバッグ」を選択します。
開かれたパイプラインまたは分割-結合のエディタ内を右クリックし、「デバッグ」を選択します。
この項では、JDeveloperでデバッガの起動、ブレークポイントの作成、およびService Busアプリケーションのデバッグを実行する方法を説明します。テスト・コンソールとデバッガを使用する以外にもデバッグする方法があります。JMSメッセージのポスト、ファイル・プロキシ・サービスのディレクトリへの入力ファイルの配置など、他の方法でサービスを実行することもできます。
ブレークポイントは、デバッグ・プロセス用に設定されるService Busアプリケーション内の意図的な一時停止位置です。テスト・コンソールを使用してテスト・データを実行すると、プロセスはブレークポイントごとに一時停止し、ユーザーが指示するまで再開しません。ブレークポイントは、パイプラインと分割-結合に設定できます。
Service Busコンポーネントにブレークポイントを設定するには:
例外ブレークポイントは、設定されているポイントでは実行を停止しません。例外ブレークポイントは、特定の位置ではなく、JDeveloperの「ブレークポイント」ウィンドウで設定します。
ローカル・サーバーを使用してコンポーネントをデバッグする場合は、デバッグ・プロセスに入力情報を入力できるようにテスト・コンソールが起動されます。統合WebLogicサーバーを使用する場合は、ローカルでのみテストできます。プロジェクトのプロパティで、ローカルでテストするか、リモートでテストするかを指定します。また、デバッグ中のブレークポイントの処理方法も構成できます。
これらのオプションの設定方法の詳細は、『Oracle JDeveloperによるアプリケーションの開発』のデバッグ用にプロジェクトを構成する方法およびデバッガ起動オプションの設定方法に関する項を参照してください。
ブレークポイントを使用してコンポーネントでデバッグを開始するには:
デバッグ・フレームワークを使用すると、デバッグ・コードに対してステップ・アクションを実行してインクリメンタルにデバッグできます。メッセージ・フロー部分に対してステップ実行し、同じまたは異なるコンポーネントの異なるブレークポイントなどの異なる位置でデバッグを開始できます。デバッグが進行するにつれ、ブレークポイント用の追加のフレームが作成され、スタック・ビューが表示されます。
次のステップで示されるすべてのアイコンが、ツールバーの「デバッグ」アイコンの右側にあります。アイコンにポインタを重ねると、アイコンの名前が表示されます。
デバッグ・セッションでステップ実行するには:
デバッグ・セッションを開始すると、「ログ」ウィンドウにいくつかのタブが表示され、デバッグ・プロセスに役立つ追加情報と機能が示されます。これらのウィンドウは、「ウィンドウ」→「デバッガ」メニューから開くこともできます。
「ブレークポイント」ウィンドウでは、ブレークポイントをグループに追加し、グループ内のすべてのブレークポイントを有効化または無効化できます。また、ロギング、サウンドおよびブレークポイントに達したら処理を停止するかどうかも構成できます。デバッグ・セッションの内側または外側のいずれにいる場合でも、「ブレークポイント」ウィンドウは使用可能です。
ブレークポイントのオプションを表示および変更するには:
ブレークポイント・グループを作成することで、ブレークポイントに対して一括編集を実行できます。グループを作成すると、新しいノードが「ブレークポイント」ウィンドウに追加され、グループに追加されたブレークポイントがそのグループ・ノードの下に表示されます。
個々のブレークポイントまたはすべてのブレークポイントを無効化するか、または削除できます。
ブレークポイントを削除または無効化するには:
ブレークポイントを無効にした場合、それを再度有効にして、デバッグ・プロセスに含めることができます。
ブレークポイントを有効にするには:
「データ」ウィンドウには、現在のブレークポイントのコンテキスト変数とその値が表示されます。デバッグ・プロセス全体を通じたリクエストまたはレスポンス・データを表示し、さらにデバッグするためにそれらの値を変更できます。単純型の変数値のみを変更できます。
変数値を表示および変更するには:
ウォッチを使用して、プログラムの実行につれて変化する変数や式の値をモニターできます。ウォッチ式を入力後、「ウォッチ」ウィンドウに式の現在の値が表示されます。プログラムの実行に伴い、プログラムがウォッチ式の変数の値を更新すると、ウォッチの値も変化します。
ウォッチは、「スタック」ウィンドウでの選択によって制御される現在のコンテキストに従って式を評価します。新しいコンテキストに移動すると、式は新しいコンテキストに応じて再評価されます。ウォッチ式内の変数が定義されていない位置に実行ポイントが移動すると、ウォッチ式全体が未定義となります。ウォッチ式が評価可能な位置に実行ポイントが戻ると、「ウォッチ」ウィンドウに再度ウォッチ式の値が表示されます。
ウォッチを追加するには: