58 テスト・コンソールの使用

この章では、本番環境でのテスト・コンソールのアンデプロイ方法を含め、Service Busテスト・コンソールを使用したサービスのテストについてのガイドラインと情報を示します。

この章のトピックは、次のとおりです:

• テスト・コンソールの概要

• テスト・コンソールへのアクセス

• プロキシ・サービス、ビジネス・サービス、パイプラインおよび分割-結合のテスト

• MFLトランスフォーメーションのテスト

• XSLTトランスフォーメーションのテスト(リソース)

• XQueryトランスフォーメーションのテスト(リソース)

• インライン式のテスト

• OWSMセキュリティを含むサービスのテスト

• セキュリティとトランスポートについて

• テスト・コンソールのアンデプロイ

• サービスのテスト・コンソール・ページ参照

58.1 テスト・コンソールの概要

Service Busテスト・コンソールは、システムの設計の検証およびテストに使用するブラウザ・ベースのテスト環境です。

テスト・コンソールはService Busコンソールの拡張機能で、コンソール、Oracle JDeveloperおよびFusion Middleware Controlからアクセスできます。テスト・コンソールは、オペレーティング・システムおよびJDeveloperの構成に応じて、JDeveloperまたはWebブラウザにタブ付きウィンドウとして表示されます。

Service Busリソースをテストする場合は、テストのオブジェクトを構成し、テストを実行して、テスト・コンソール・ウィンドウで結果を表示します。場合によっては、コードをトレースし、特定のトレース・ポイントのメッセージの状態を調べることができます。設計時テストを行うことで、構成を本番環境にデプロイする前に設計上の問題を割り出すことができます。テスト・コンソールを使用してテストできるコンポーネントには、プロキシ・サービス、ビジネス・サービス、パイプライン、分割-結合、XQueryリソース、XSLTリソース、MFLリソースおよびXQuery/XPath式が含まれます。

テスト・コンソールでは、システムの特定部分を切り分けてテストしたり、システムを1つの単位としてテストしたりできます。テスト・コンソールはクラスタ環境で使用できます。しかし、本番環境にテスト・コンソールをデプロイすることはお薦めしません。テスト・コンソールを使用できるのはIntegrationAdminおよびIntegrationDeployerロールのユーザーのみです。ロールの詳細は、『Oracle Service Busの管理』のロールに関する項を参照してください。

大半のサービスはテスト・コンソールを使用してテストできますが、テストコンソールでは、Javaオブジェクトがメッセージ入力であることを前提とするサービスを呼び出すことはできません。たとえば、メッセージのリクエストまたはレスポンス・タイプがJavaのメッセージ・サービスはテストできません。また、Javaオブジェクトを前提としているJEJB操作もテストできません。

58.1.1 プロキシ・サービス・テスト

プロキシ・サービスをテストする場合、メッセージはトランスポート・レイヤーを介してプロキシ・サービスへ送信されます。トランスポート・レイヤーでは、テストの一環としてメッセージ・ヘッダーまたはメタデータの操作を実行します。テスト用に入力する構成データは、クライアントからプロキシ・サービスへ送信されるデータをシミュレートします。プロキシ・サービス・テストのレスポンスは、システム内の次のコンポーネントへ送信されるメッセージです。これは、前バージョンのService Busの間接コールに緩やかに関連付けられます。

このテスト・アプローチと、テスト・コンソールの「トランスポート」セクションにあるカスタム(アウトバウンド)トランスポート・ヘッダーの設定を使用して、サービス・コールを正確にシミュレートします。トランスポート設定の詳細は、「テスト・コンソールのトランスポート設定」を参照してください。

ノート:

リクエスト/レスポンスMQまたはJMSのプロキシ・サービスのテストは動作しません。messageIDに基づく相関を使用したMQまたはJMSリクエスト/レスポンス・プロキシ・サービスへのコールからのレスポンスは、テスト・コンソールには表示されません。MQまたはJMSリクエスト/レスポンス・プロキシ・サービスをテストした場合、レスポンスはレスポンス・キューに保持されますが、テスト・コンソールには表示されません。

58.1.2 パイプライン・テスト

パイプラインをテストする場合、入力メッセージは直接パイプラインへ送信されます。デフォルトでトレースが有効になり、テスト・コンソールでメッセージ・フローの診断とトラブルシューティングが可能になります。テスト・コンソールに入力する入力データは、呼出し元のプロキシ・サービスのパイプラインが想定するデータである必要があります。つまり、テスト・コンソールは、パイプラインを呼び出すプロキシ・サービスのロールを担います。これは、前バージョンのService Busの直接コールに緩やかに関連付けられます。

パイプラインのテストでは、内部メッセージ・フロー・ロジックがテストされます。このテスト・アプローチと、テスト・コンソールの「トランスポート」パネルにあるカスタム(インバウンド)トランスポート・ヘッダーの設定を使用して、サービス呼出しを正確にシミュレートします。

58.1.2.1 テスト・コンソールを使用したパイプラインでのトレースの実行

パイプラインを介したメッセージのトレースでは、メッセージ・フローの様々なポイントで、メッセージ・コンテキストの確認と、アウトバウンドを行う通信が発生します。メッセージを検査するポイントはService Busで事前に定義され、ステージ、エラー・ハンドラおよびルート・ノードに対して定義されます。トレースのステージごとに、メッセージ・コンテキストに発生した変更と、そのステージの実行中に呼び出されたすべてのサービスが含まれます。

トレースには次のステージ情報が含まれます。

• 初期メッセージ・コンテキスト: プロキシ・サービスが呼び出されたときに、プロキシ・サービスが初期化した変数を表示します。変数の値を確認するには、変数名に対応する+記号をクリックします。

• 新しい変数: すべての新しい変数の名前と値。変数を展開すると、その値が表示されます。

• 削除された変数: 削除されたすべての変数の名前。

• 変更された変数: ステージを経由してメッセージを処理した結果として変更された$header、$body、$inboundを含め、値が変更されたすべての変数の名前。変数を展開すると、新しい値が表示されます。

• フォルト: エラーが発生した場合に、ステージ・エラー・ハンドラが検証エラーを処理した結果として、faultコンテキスト変数($fault)のコンテンツが表示されます。

• パブリッシュ: すべてのパブリッシュ・コールがリストされます。トレースには、パブリッシュ呼出しごとに、呼び出されたサービスの名前と、outbound、header、bodyおよびattachmentの各変数の値が含まれます。

• サービス・コールアウト: すべてのサービス・コールアウトがリストされます。トレースには、サービス・コールアウトごとに、呼び出されたサービスの名前、outbound変数の値、リクエスト・メッセージとレスポンス・メッセージのheader、bodyおよびattachmentの各変数の値が含まれます。

ルート・ノードについても、ステージと同様の情報が含まれます。ルート・ノードの場合、トレースには次のカテゴリの情報が含まれます。

• リクエスト・パスでのサービス呼出しのトレース

• ルーティングされたサービスのトレース

• レスポンス・パスでのサービス呼出しのトレース

• (リクエスト・パスの)ルート・ノードの開始ポイントと(レスポンス・パスの)終了ポイントの間でメッセージ・コンテキストに加えられた変更

ノート:

ログ・ファイルまたは標準出力(サーバー・コンソール)にトレースを表示するには、WebLogic Serverのロギングを次の重大度に設定する必要があります。

• ログの最低の重大度: 情報

• ログ・ファイル: 情報

• 標準出力: 情報

ログの重大度の設定の詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタリング』のログの重大度の使用に関する項を参照してください。

58.1.3 ビジネス・サービス・テスト

ビジネス・サービスの入力テスト・データは、ビジネス・サービスの呼出し元のパイプライン、分割-結合またはプロキシ・サービスから受信したときにビジネス・サービスが想定する形式になっている必要があります。たとえば、ルート・ノードやパイプラインのサービス・コールアウト・アクションからのデータなどが考えられます。テスト・コンソールを使用してビジネス・サービスをテストする場合、テスト・コンソールは呼出し側のサービスの役割を果たします。ビジネス・サービスをテストする場合、メッセージは必ずトランスポート・レイヤーを経由してルーティングされます。

ビジネス・サービスをテストする場合は、テスト中のビジネス・サービスがリモート・ドメインにある場合でも、テスト・コンソールで指定されたユーザー名およびパスワードが、ローカルService Busドメインに存在することを確認します。テスト・サービスは、プロキシ・サービスまたはビジネス・サービスを呼び出す前に、ローカル認証を実行します。

58.1.4 サービスの推奨テスト・アプローチ

図58-1に示すシナリオでは、クライアントがプロキシ・サービスPS1を呼び出し、それによってパイプラインP1が呼び出されています。パイプラインは、パイプラインP2、ビジネス・サービスB1、ローカル・プロキシ・サービスPS2の順に呼び出してから、メッセージをクライアントに返します。インタフェースを番号で示しています。

図58-1 テスト・シナリオの例

「図58-1 テスト・シナリオの例」の説明

このシナリオには、有効なテスト方法がいくつもあります。次が推奨されます。

• 最初に初期プロキシ・サービス以外のインタフェースのテストを完了します。つまり、図58-1に示すサンプル・シナリオでは、まずインタフェース1から6のテストを完了してから、インタフェース7をテストします。

  通常は、メッセージがシステムを流れる逆の順序でテストします。この方法により、ダウンストリーム・インタフェースが正しく機能することを確認しながら、パイプラインのメッセージ・フロー・ロジックを反復的に変更およびテストできます。

• ビジネス・サービス(B1)インタフェース(1)へのパイプライン(P1)をテストします。

• パイプライン自身をテストする前に、パイプラインですべてのXQuery式を検証し、テストします。図58-1では、インタフェース2および5がXQuery式のテストを示しています。

• パイプライン(P2)インタフェース(3)へのパイプライン(P1)をテストします。

• ローカル・プロキシ・サービス(PS2)インタフェース(4)へのパイプライン(P1)をテストします。

• パイプライン(P1)インタフェース(6)への初期プロキシ・サービス(PS1)をテストします。

• 最後のシステム・テストで、プロキシ・サービスPS1を呼び出すクライアントをシミュレートします。図58-1では、このテストはインタフェース7によって表されています。

• システムの今後のトラブルシューティングを容易にするために、インタフェースのテストが成功した後のメッセージの状態を保存します。インタフェース6のテストは、実際にはシステム全体のテストです。システムの他のすべてのインタフェースが正しく機能していることを確認することで、システム・エラー発生時のトラブルシューティングの範囲を絞り込むことができます。

58.1.5 HTTPリクエスト

プロキシ・サービスをテストするときに、テスト・コンソールではネットワーク経由でHTTPリクエストを送信しないため、トランスポート・レベルのアクセス制御は適用されません。トランスポート・レベルのアクセス制御は、Webアプリケーション・レイヤーを介して実現されます。トランスポート・レイヤーのメッセージ処理の詳細は、「メッセージ処理」を参照してください。トランスポート設定の詳細は、「ランタイムがテスト・コンソールでトランスポート設定を使用する方法」を参照してください。

58.2 テスト・コンソールへのアクセス

特定のService Busサービスをテストするためにテスト・コンソールにアクセスする方法は複数あり、Oracle Service Busコンソール、JDeveloperまたはFusion Middleware Controlからアクセスできます。

プロキシ・サービス、ビジネス・サービス、パイプラインおよび分割-結合は、セッションの外部でのみテストできます。トランスフォーメーションはセッションの外部でも内部でもテストできます。

ノート:

テスト・コンソール・サービスが実行されていないことを示すエラーを受信した場合は、管理サーバーがlocalhostなどの特定の有効なアドレスをリスニングするように設定してみます。Oracle WebLogic Server管理コンソールの「環境」→「サーバー」→「admin_server_name」→「構成」→ >「全般」を選択し、「リスニング・アドレス」を設定します。また、クラスタではすべての管理対象ノードが実行されていることを確認します。

58.2.1 前提条件

テスト・コンソールを使用するには、事前に次の準備が整っている必要があります。

• Service Busが稼動している必要があり、サービスをテストする場合はテストするリソースを含むセッションがアクティブ化されている必要があります。サービスはセッションの外部でのみテストできますが、トランスフォーメーションはセッションの外部でも内部でもテストできます。

• XQueryテストを実行するには、ブラウザのポップアップ・ブロッカを無効にする必要があります。Internet Explorerブラウザでツールバーを使用している場合、「インターネット オプション」メニューでポップアップ・ブロッカを無効にするだけでなく、ポップアップをブロックするように構成されているすべてのツール・バーについてもこの機能を無効にする必要があります。XQueryテストは、設計時環境(アクティブ・セッション)でのみ実行されます。

• テスト・コンソールを使用してSAMLトークンを生成し、プロキシ・サービスに送信する場合は、SAMLトークンを要求し、リライイング・パーティにするように、プロキシ・サービスを構成する必要があります。SAMLリライイング・パーティの作成方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 1.1リライイング・パーティの作成に関する項を参照してください。

  ノート:

  SAMLリライイング・パーティ作成時には、次に留意してください。

  • プロキシ・サービスではWSS/Sender-VouchesプロファイルおよびWSS/Holder-of-Key SAMLプロファイルのみ使用できます。

  • リライイング・パーティを構成する場合、対象URLの値としてプロキシ・サービスのURIを指定します。プロキシ・サービスのURIを表示するには、Oracle Service Busコンソールで「プロキシ・サーバーを開く」をクリックして、「トランスポート」サブタブをクリックします。

58.2.2 Oracle Service Busコンソールからテスト・コンソールへのアクセス方法

Oracle Service Busコンソールで、コンポーネントの定義エディタまたはプロジェクト/フォルダ定義エディタからサービスまたはトランスフォーメーションのテスト・コンソールにアクセスできます。

58.2.2.1 コンポーネントの定義エディタからのテスト・コンソールへのアクセス

コンポーネントの定義エディタからテスト・コンソールにアクセスするには:

1. Oracle Service Busコンソール・プロジェクト・ナビゲータで、テストするサービスまたはトランスフォーメーションを含むプロジェクトとフォルダを開きます。
2. リソースをクリックして、定義エディタで開きます。
3. 定義エディタの右上のセクションにある「テスト・コンソールの起動」(緑色の矢印アイコン)をクリックします。

   新しいブラウザ・ウィンドウにテスト・コンソールが表示され、そこで選択したコンポーネントをテストできます。

58.2.2.2 プロジェクト/フォルダ定義エディタからのテスト・コンソールへのアクセス

プロジェクト/フォルダ定義エディタからテスト・コンソールにアクセスするには:

1. Oracle Service Busコンソール・プロジェクト・ナビゲータで、テストするコンポーネントを含むプロジェクトまたはフォルダの名前をクリックします。

   そのフォルダまたはプロジェクトの定義エディタが表示されます。

2. リソース表でテストするコンポーネントを検索します。
3. 「アクション」列で、「テスト・コンソールの起動」(緑色の矢印アイコン)をクリックします。

   新しいブラウザ・ウィンドウにテスト・コンソールが表示され、そこで選択したコンポーネントをテストできます。

58.2.3 Fusion Middleware Controlからテスト・コンソールへのアクセス方法

Fusion Middleware Controlで、サービスの「ダッシュボード」ページからサービスのテスト・コンソールにアクセスできます。Fusion Middleware Controlからはサービスのみテストでき、トランスフォーメーションはテストできません。

Fusion Middleware Controlからテスト・コンソールにアクセスするには:

1. Fusion Middleware Controlの対象のナビゲータで、SOA、service-busの順に開き、テストするコンポーネントを含むプロジェクトをクリックします。

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

2. プロジェクトに関連付けられたサービスが「サービス」表に表示されない場合は、テストするサービスの検索を実行します。

   ノート:

   このページには、モニタリングが有効なサービスのみが表示されます。

3. 「サービス」表で、テストするサービスの名前をクリックします。

   サービスの「ダッシュボード」が表示されます。

4. サービス名の右の「テスト・コンソールの起動」(緑色の矢印アイコン)をクリックします。

   新しいブラウザ・ウィンドウにテスト・コンソールが表示され、そこで選択したコンポーネントをテストできます。

58.2.4 JDeveloperからテスト・コンソールへのアクセス方法

JDeveloperで、サービスの定義エディタまたはコンテキスト・メニューからサービスまたはトランスフォーメーションのテスト・コンソールにアクセスできます。トランスフォーメーションは、テスト・コンソールおよびJDeveloper XSLTテスターを含む複数のテスト・オプションを備えています。

58.2.4.1 JDeveloperからテスト・コンソールへのアクセス

JDeveloperからサービスのテスト・コンソールにアクセスするには:

1. JDeveloperで、テストするサービスを含むService Busプロジェクトを開きます。
2. 次のいずれかを行います:

   • サービスをダブルクリックしてエディタを表示し、その後、JDeveloperツールバーで「実行」アイコンをクリックします。

   • サービスを右クリックし、「実行」を選択します。

   新しいタブ付きウィンドウにテスト・コンソールが表示され、そこで、選択したサービスをテストできます。

58.2.4.2 JDeveloperからのトランスフォーメーションのテスト・コンソールへのアクセス

JDeveloperからトランスフォーメーションのテスト・コンソールにアクセスするには:

1. JDeveloperで、テストするトランスフォーメーションを含むService Busプロジェクトを開きます。
2. 次のいずれかを行います:

   • トランスフォーメーションをクリックしてエディタを表示し、その後、JDeveloperツールバーで「実行」アイコンをクリックします。

   • トランスフォーメーションを右クリックし、「実行」を選択します。

     ノート:

     「デバッグ」をクリックしてもテスト・コンソールは起動しますが、通常はセクション内のメッセージ・フローをステップ実行できるように、ブレークポイントと組み合わせて使用します。

3. ダイアログが表示された場合は、ターゲットの起動方法の選択肢として「Service Busテスト・コンソール内」を選択します。

   新しいタブ付きウィンドウにテスト・コンソールが表示され、そこで、選択したサービスをテストできます。

58.3 プロキシ・サービス、ビジネス・サービス、パイプラインおよび分割-結合のテスト

Service Busサービスをテストする場合、アクティブ・セッションでは実行できません。テスト・コンソールでは、入力、トランスポート・ヘッダー、添付および特定のセキュリティ構成をテストできます。

サービスのテスト方法の詳細は、「テスト・コンソールの概要」を参照してください。

ノート:

• クラスタリングされたドメインでは、テスト・コンソールを利用して、ビジネス・サービスにルーティングされる構成済のビジネス・サービスまたはプロキシ・サービスをテストすることはできません。

• HTTPカスタム・トークン認証を使用するプロキシをテスト・コンソールで呼び出した場合、認証チェックは行われません。

58.3.1 Service Busサービスのテスト方法

サービスのテスト・コンソールを起動した場合は、テストする操作、メッセージ・ペイロード、トランスポート・ヘッダー、セキュリティ情報を含むテスト入力を構成できます。パイプラインの場合は、様々なコンポーネントを介してメッセージ処理をトレースできます。次の図は、テスト・コンソール・ページの例を示しています。

図58-2 テスト・コンソールの「パイプライン・テスト」ページ

「図58-2 テスト・コンソールの「パイプライン・テスト」ページ」の説明

Service Busサービスをテストするには:

1. Oracle Service Busコンソール内のセッションがアクティブ化されていることを確認します(該当する場合)。
2. 「テスト・コンソールへのアクセス」で説明されているとおり、テストするプロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合を検索し、テスト・コンソールを起動します。
3. SOAPおよびXMLサービスの場合は、テストするWSDL操作を選択します。
4. 「リクエスト・ドキュメント」セクションで、使用するテスト・データを入力します。これはサービスが受信することを想定しているデータである必要があります。

   このセクションの入力方法の詳細は、「リクエスト・ドキュメント・テスト・コンソール・プロパティ」を参照してください。

   ノート:

   保護されたSOAPメッセージは、空白が追加されて表示されます。ホワイト・スペースはドキュメントのセマンティクスに影響する可能性があるため、このようなSOAPメッセージはリテラル・データとして必ずしも使用できるわけではありません。たとえば、デジタル署名はホワイト・スペースの影響を受け、無効になることがあります。

5. テスト・コンソールのその他のセクションを構成します。設定可能なプロパティの詳細は、「サービスのテスト・コンソール・ページ参照」を参照してください。
6. 「実行」をクリックします。

   リクエスト・メッセージおよびサービスのレスポンス・メッセージとメタデータがテスト・コンソールに表示されます。テスト結果の解釈方法の詳細は、「サービスのテスト結果の表示方法」を参照してください。

7. もう一度テストを実行するには、「戻る」をクリックします。ステップ3から6を繰り返します。

58.3.2 サービス内の添付のテスト方法

プロキシ・サービス、ビジネス・サービスおよびパイプラインとともに、メッセージ添付をテストできます。

添付とともにサービスをテストするには:

1. Oracle Service Busコンソール内のセッションがアクティブ化されていることを確認します(該当する場合)。
2. 「テスト・コンソールへのアクセス」で説明されているとおり、テストするプロキシ・サービス、ビジネス・サービスまたはパイプラインを検索し、テスト・コンソールを起動します。
3. SOAPおよびXMLサービスの場合は、テストするWSDL操作を選択します。
4. パイプラインの場合は、トレースを有効にするかどうかを指定します。詳細は、「パイプライン処理のトレース方法」を参照してください。
5. 「リクエスト・ドキュメント」セクションで、テスト・メッセージのペイロードを入力します。

   例として、次の入力はsubmitAttachment操作を使用して、SOAPメッセージ内の添付としてZIPファイルを送信します。

   <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
      <env:Header/>
      <env:Body>
         <m:submitAttachment xmlns:m="http://www.alsb.com/SOAPwithAttachment/">
            <submitAttachment>
               <fileName>c:\yourfile.zip</fileName>
            </submitAttachment>
            <zipFile href="cid:zipFile"/>
         </m:submitAttachment>
      </env:Body>
   </env:Envelope>
   

   このセクションの入力方法の詳細は、「リクエスト・ドキュメント・テスト・コンソール・プロパティ」を参照してください。

6. 「添付テスト・コンソールのプロパティ」で説明されているとおり、テスト・コンソールの「添付」セクションで、添付ヘッダーの値を入力します。添付として使用するファイルを選択する必要があります。
7. テスト・コンソールのその他のセクションを構成します。設定可能なプロパティの詳細は、「サービスのテスト・コンソール・ページ参照」を参照してください。
8. 「実行」をクリックします。

   添付が正常に送信されたことを確認するため、ここの例では、submitAttachment操作によってログに記録された次のようなメッセージが、サーバー・コンソールに表示されていることをチェックします。

   WS called - received the following properties:
   submitAttachment is:
         com.alsb.soapwithattachment.SubmitAttachmentRequestType@e2abb0
   zipFile is: javax.activation.DataHandler@175cf0a
   

58.3.3 パイプライン処理のトレース方法

パイプラインのトレースを有効にすると、テスト結果にはトレースの詳細が含まれます。トレースは、システムにある問題を追跡し、修正するために問題を切り分けるために使用します。トレース情報は、コード内で要求パスと応答パスを通過した経路を示します。次の図は、パイプライン・トレースの結果を示しています。

トレースの表示中、Service BusコンソールまたはOracle JDeveloperにメッセージ・フローを表示することもできます。これにより、トレースをメッセージ・フローのステージやアクションに対応付けるのが容易になります。メッセージ・フローを変更してから再度トレースを実行し、出力を表示できます。

図58-3 パイプライン呼出しのトレース

「図58-3 パイプライン呼出しのトレース」の説明

パイプラインを通じてメッセージをトレースするには:

1. Oracle Service Busコンソール内のセッションがアクティブ化されていることを確認します(該当する場合)。
2. 「テスト・コンソールへのアクセス」で説明されているとおり、テストするパイプラインを検索し、テスト・コンソールを起動します。
3. SOAPおよびXMLサービスの場合は、「サービス操作」セクションの使用可能なオプションから、テストするWSDL操作を選択します。
4. 「テスト構成」セクションで、「トレースを含む」が選択されていることを確認します。
5. 「リクエスト・ドキュメント」セクションで、使用するテスト・データを入力します。これはパイプラインが受信することを想定しているデータである必要があります。

   このセクションの入力方法の詳細は、「リクエスト・ドキュメント・テスト・コンソール・プロパティ」を参照してください。

6. テスト・コンソールのその他のセクションを構成します。設定可能なプロパティの詳細は、「サービスのテスト・コンソール・ページ参照」を参照してください。
7. 「実行」をクリックします。

   リクエスト・メッセージおよびサービスのレスポンス・メッセージとメタデータがテスト・コンソールに表示されます。テスト結果の解釈方法の詳細は、「サービスのテスト結果の表示方法」を参照してください。

8. 下の「呼出しのトレース」セクションまでスクロールします。

   このセクションには、メッセージ・フローの表現が表示されます。サービスを通過したメッセージをトレースし、あらかじめ選択されたポイントでのメッセージの状態を表示できます。トレース・ポイントは自動的に設定されます。

9. 「+」記号をクリックしてメッセージ・フローを展開し、詳細を表示します。

58.3.4 サービスのテスト結果の表示方法

プロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合をテストする場合、テスト・コンソールのいくつかのセクションに結果が表示されます。表58-1は、テスト結果のセクションを示しています。

表58-1 プロキシ・サービスのテスト結果

セクション	説明
リクエスト・ドキュメント	テスト・コンソールによってサービスに送信されたリクエスト・メッセージです。 リクエスト・メッセージがテスト・コンソールによって変更されなかった場合は、このセクションは最初は折りたたまれています。「フォーム」タブでSOAPサービスを構成した場合、またはWS-Securityが適用されている場合は、このセクションは最初は開かれます。 WS-Securityが適用されている場合、このセクションには2つのSOAPメッセージが表示されます。1番目のメッセージはクリア・テキスト・メッセージで、2番目は保護されたSOAPメッセージです。
レスポンス・ドキュメント	サービスによって生成されたメッセージ・レスポンスです。このセクションには、エラーが発生したかどうかも示されます。 WS-Securityレスポンスが適用されたSOAPサービスの場合、このセクションには2つのSOAPメッセージが表示されます。1つ目のSOAPメッセージは、クライアントが受け取る保護されたメッセージ。2つ目のSOAPメッセージは、対応するクリア・テキストのメッセージ。
レスポンス・メタデータ	メッセージのレスポンスと共に返されたメタデータ。
呼出しのトレース	トレースはパイプラインの場合のみ使用可能で、このセクションにはシステムを経由した際のメッセージの状態が表示されます。これは、テストを実行する前に「トレースを含む」を選択した場合にのみ実行されます。

58.4 MFLトランスフォーメーションのテスト

MFL(メッセージ・フォーマット言語)ドキュメントは、バイナリ・データのレイアウトの記述に使用する特殊なXMLドキュメントです。

MFLリソースは、次のトランスフォーメーションをサポートしています。

• XMLからバイナリ: 必須入力(XML)が1つと出力(バイナリ)が1つあります。

• バイナリからXML: 必須入力(バイナリ)が1つと出力(XML)が1つあります。

各トランスフォーメーションでは、入力を1つだけ受け入れ、出力を1つ返します。MFLトランスフォーメーションは、JDeveloperまたはOracle Service Busコンソールのいずれかからアクセスしたテスト・コンソールを使用して、またはJDeveloperのフォーマット・ビルダー内のテスターを使用してテストできます。

58.4.1 テスト・コンソールでのMFLトランスフォーメーションのテスト方法

セッションをアクティブ化した後、またはセッション中に、トランスフォーメーションをテストして、リソースが想定したとおりに動作するかどうかを確認できます。セッションをアクティブ化しない場合、テストはローカルでの変更内容を使用して設計時に実行されます。

JDeveloperで、フォーマット・ビルダーの組込みテスト・ツールを使用することもできます。フォーマット・ビルダーからテストを実行する方法の詳細は、「フォーマット定義のテスト」を参照してください。

テスト・コンソールでMFLトランスフォーメーションをテストするには:

1. 実行時にテストするには、現在のセッションをアクティブ化します。設計時にテストするには、セッションをアクティブ化しません。
2. 「テスト・コンソールへのアクセス」で説明されているとおり、テストするMFLリソースを検索し、テスト・コンソールを起動します。
3. MFLリソースのテスト・データを構成します。詳細については、表58-2を参照してください。
4. 「実行」をクリックします。

   テスト・コンソールに結果が表示されます。

5. もう一度テストする場合は、「戻る」をクリックします。テスト・コンソールを閉じたら、リソースを変更し、再度テストできます。

表58-2 MFLテスト・コンソールのプロパティ

セクション	説明
サポートされるトランスフォーメーション	テストする特定のトランスフォーメーションを選択するには、トランスフォーメーション名を選択します。
入力ドキュメント	XML入力: XMLからバイナリへのトランスフォーメーションでは必須です。 MFLドキュメントのXMLスキーマは推測できます。サンプルXMLドキュメントはテキスト・フィールドに自動的に入力されます。XML入力はファイル・ベースまたはテキスト・ベースで入力できます。テキスト入力よりファイルの参照による入力が優先されます。テストに使用するファイルを参照して選択します。 バイナリ入力: バイナリからXMLへのトランスフォーメーションでは必須です。 バイナリ入力はファイル・ベースまたはテキスト・ベースで入力できます。テキスト入力よりファイルの参照による入力が優先されます。テストに使用するファイルを参照して選択します。

58.4.2 MFLテスト・コンソールの例

次の例は、MFLトランスフォーメーションのテストと、MFLファイルのコンテンツ、テスト入力およびテスト結果を示しています。テスト・コンソールによってMFLファイルからサンプルXMLドキュメントが生成されます。XML入力を使用してテストを実行します。テストが成功すると、入力XMLドキュメントのメッセージ・コンテンツがバイナリ形式に変換されます。

例 - MFLファイルのコンテンツ

以下は、MFLファイルの例です。

<?xml version='1.0' encoding='windows-1252'?>
<!DOCTYPE MessageFormat SYSTEM 'mfl.dtd'>
  <MessageFormat name='StockPrices' version='2.01'>
   <StructFormat name='PriceQuote' repeat='*'>
    <FieldFormat name='StockSymbol' type='String' delim=':' codepage='windows-1252'/>
    <FieldFormat name='StockPrice' type='String' delim='|'codepage='windows-1252'/>
   </StructFormat>
  </MessageFormat>

例 - テスト・コンソールでのXML入力

前述の例のMFLファイルをテストするためにテスト・コンソールで生成されるXMLドキュメントを次に示します。

<StockPrices>
    <PriceQuote>
        <StockSymbol>StockSymbol_31</StockSymbol>
        <StockPrice>StockPrice_17</StockPrice>
    </PriceQuote>
</StockPrices>

例 - MFLのテスト・コンソールでの結果

テスト・コンソールで「実行」をクリックしてこのテストを実行すると、コンソールには次のデータが表示されます(バイナリ形式での株価記号と株価)。

00000000:53 74 6F 63 6B 53 79 6D 62 6F 6C 5F 33 31 3A 53 StockSymbol_31:S
00000010:74 6F 63 6B 50 72 69 63 65 5F 31 37 7C .. .. .. StockPrice_17|...

58.5 XSLTトランスフォーメーションのテスト(リソース)

Service Busでは、Extensible Stylesheet Language Transformation (XSLT)を使用してXML間のマッピングを記述します。メッセージ・フローのXQuery式でXSLTトランスフォーメーションを使用できます。

XSLTリソースをテストするには、入力XMLドキュメントを指定する必要があります。テスト・コンソールは、出力XMLドキュメントを返します。XSLTトランスフォーメーションには、トランスフォーメーションに役立つ複数のパラメータを含めることができます。テスト・コンソールに、トランスフォーメーションに必要なパラメータがすべて表示されます。デフォルト値が表示されますが、値はオーバーライドできます。XSLTパラメータは、値としてプリミティブ型またはXMLドキュメントをとります。XSLトランスフォーメーションからパラメータの型を識別することはできません。

XSLTトランスフォーメーション用のテスト・コンソールには、Oracle Service BusコンソールまたはJDeveloperからアクセスできます。JDeveloperでは、XSLTマッパーの組込みテスターも使用できます。

58.5.1 テスト・コンソールを使用したXSLTトランスフォーメーションのテスト方法

セッションをアクティブ化した後、またはセッション中に、XSLTトランスフォーメーションをテストして、リソースが想定したとおりに動作するかどうかを確認できます。実行時テストを行うには、セッションをアクティブ化する必要があります。それ以外の場合は、ローカルでの変更内容を使用した設計時テストが行われます。

テスト・コンソールを使用してXSLTトランスフォーメーションをテストするには:

1. 実行時にテストするには、現在のセッションをアクティブ化します。設計時にテストするには、セッションをアクティブ化しません。
2. 「テスト・コンソールへのアクセス」で説明されているとおり、テストするXSLTリソースを検索し、テスト・コンソールを起動します。
3. 次の情報を入力してリソースのテスト・データを構成します。

   • XML入力: XML入力はファイル・ベースまたはテキスト・ベースで入力できます。入力するためのファイルを選択した場合、それがテキスト入力より優先されます。テストに使用するファイルを参照して選択します。XML入力は必須です。

   • param_name: 名前付きXSLTパラメータ。XML型とプリミティブ型(string型、integer型、float型など)の2つの入力型があります。デフォルトの入力型はstring型です。XMLタイプのパラメータを識別するには、パラメータ名に関連付けられた「XMLとして」チェック・ボックスを選択します。このオプションの詳細は、「XQueryトランスフォーメーションのテスト(リソース)」を参照してください。

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

   テスト・コンソールに結果が表示されます。

5. もう一度テストする場合は、「戻る」をクリックします。テスト・コンソールを閉じたら、リソースを変更し、再度テストできます。

58.5.2 JDeveloper XSLTマッパーでXSLTトランスフォーメーションをテストする方法

JDeveloperからXSLTトランスフォーメーションのテスト・コンソールにアクセスできますが、JDeveloperはXSLTマッパーから直接アクセスできるXSLTトランスフォーメーション専用のテスターを提供しています。カスタムXPath関数はマッパーでテストできません。

JDeveloperでXSLTトランスフォーメーション・テストを実行する方法の詳細と手順は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のマップのテストに関する項を参照してください。

58.6 XQueryトランスフォーメーションのテスト(リソース)

XQueryは、データがXMLに物理的に格納されるか、XMLとして表示されるかに関係なく、XMLの構造を使用して、様々な種類のデータに対する問合せを表現します。XQueryトランスフォーメーションは複数の入力をとる場合があります。返される出力は1つです。

XQueryトランスフォーメーションに想定される入力は、定義済の各XQuery外部変数にバインドする変数値です。XQuery入力変数の値には、プリミティブ型の値(string型、integer型、date型)、XMLドキュメント、またはこれらの型のシーケンスを指定できます。出力値は、プリミティブ型の値(string型、integer型、date型)、XMLドキュメント、またはこれらの型のシーケンスになります。

XQueryは型付きの言語で、外部変数ごとに型が決まっています。型は次のグループに分類できます。

• 単純型/プリミティブ型(string、int、floatなど)

• XMLノード

• 型なし

テスト・コンソールでは、これらの3つの変数がすべてテスト・コンソールの「変数」セクションにリストされ、入力はテストの実行時に構成されます。型なし変数には、デフォルトでXMLが選択されます。これが最も一般的なケースであるためです。

58.6.1 XQueryトランスフォーメーションのテストの前提条件とガイドライン

XQueryテストが機能するように、ブラウザのポップアップ・ブロッカを無効にする必要があります。Internet Explorerブラウザでツールバーを使用している場合、「インターネット オプション」メニューでポップアップ・ブロッカを無効にするだけでなく、ポップアップをブロックするように構成されているすべてのツール・バーについてもこの機能を無効にする必要があります。

テスト・コンソールでXQueryテストを実行する場合、新しいテストを実行するには「戻る」ボタンを使用します。ただし、XQueryを変更した後に新しいテストを実行する場合、変更を有効にするには、テスト・コンソールを閉じて再度開く必要があります。

58.6.2 テスト・コンソールでのXQueryトランスフォーメーションのテスト方法

XQueryマップでは、XMLからXML、XMLから非XML、および非XMLからXMLへの各マッピングを記述できます。テスト・コンソールは入力のシーケンスに対応していません。セッションをアクティブ化した後、またはセッション中に、トランスフォーメーションをテストして、リソースが想定したとおりに動作するかどうかを確認できます。実行時テストを行うには、セッションをアクティブ化する必要があります。それ以外の場合は、ローカルでの変更内容を使用した設計時テストが行われます。

テスト・コンソールを使用してXQueryトランスフォーメーションをテストするには:

1. 実行時にテストするには、現在のセッションをアクティブ化します。設計時にテストするには、セッションをアクティブ化しません。
2. 「テスト・コンソールへのアクセス」で説明されているとおり、テストするXQueryリソースを検索し、テスト・コンソールを起動します。
3. XQuery入力を入力してリソースのテスト・データを構成します。次で説明するとおり、入力は外部変数に基づきます。

   • XQuery外部変数ごとに1つずつ名前付きの入力フィールドがあります。

   • 単純型である場合は、1行の編集ボックスが表示されます。データがXMLである場合は、複数行の編集ボックスが表示されます。

   • 変数に型がない場合は、両方の組合せの入力フィールドが使用されます。変数の型を宣言する必要があります。XML型のパラメータを指定するには、「XMLとして」チェック・ボックスを選択します。

   • XML入力はファイル・ベースまたはテキスト・ベースで入力できます。テキスト入力よりファイルの参照による入力が優先されます。テストに使用するファイルを参照して選択します。

   • テスト・コンソールの入力は、入力する必要のあるデータの型がわかりやすいように、型に基づいて表示されます。型なしの場合のデフォルトはXML型。

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

   テスト・コンソールに結果が表示されます。

5. もう一度テストする場合は、「戻る」をクリックします。テスト・コンソールを閉じたら、リソースを変更し、再度テストできます。

58.7 インライン式のテスト

Oracle Service Busコンソールで式または条件を作成または変更する際、メッセージ・フロー・アクションの式をXQuery/XSLT式エディタ、XQuery条件エディタおよびXPath式エディタからテストできます。

JDeveloperの式ビルダーからテスト・コンソールにアクセスすることもできます。テストは、XQuery/XSLT式エディタおよびXQuery条件エディタの両方で同じ形式をとりますが、XPath式エディタではわずかに異なります。

58.7.1 XQuery式をテストする方法

XQuery/XSLT式エディタおよびXQuery条件エディタからXQuery式を直接テストできます。

XQuery式をテストするには:

1. パイプライン・アクションで式を作成または更新します。
2. 次のいずれかを行います:

   • JDeveloperで、「テスト式」アイコンをクリックします。

   • Oracle Service Busコンソールで、「検証」をクリックして式が有効であることを確認し、「テスト」をクリックします。

   テスト・コンソールが現れ、テストする式が表示されます。

3. 「データ入力」セクションで、XQuery入力を入力してリソースのテスト・データを構成します。次で説明するとおり、入力は外部変数に基づきます。

   • XQuery外部変数ごとに1つずつ名前付きの入力フィールドがあります。

   • 単純型である場合は、1行の編集ボックスが表示されます。データがXMLである場合は、複数行の編集ボックスが表示されます。

   • 変数に型がない場合は、両方の組合せの入力フィールドが使用されます。変数の型を宣言する必要があります。XML型のパラメータを指定するには、「XMLとして」チェック・ボックスを選択します。

   • XML入力はファイル・ベースまたはテキスト・ベースで入力できます。テキスト入力よりファイルの参照による入力が優先されます。テストに使用するファイルを参照して選択します。

   • テスト・コンソールの入力は、入力する必要のあるデータの型がわかりやすいように、型に基づいて表示されます。型なしの場合のデフォルトはXML型。

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

   テスト・コンソールに結果が表示されます。

5. もう一度テストする場合は、「戻る」をクリックします。テスト・コンソールを閉じたら、リソースを変更し、再度テストできます。

   XQueryを変更してからもう一度テストを実行する場合、変更を有効にするには、テスト・コンソールを閉じて開きなおす必要があります。

58.7.2 XPath式をテストする方法

XPath式は、XMLメッセージ・コンテキスト変数のサブセットを選択するために使用します。XPath式エディタ内でテスト・コンソールを使用して、XPath式の定義をテストすることができます。XPath式は、入力として1つのXMLドキュメントをとり、出力としてXMLドキュメントのシーケンスやプリミティブ型、またはその両方を生成します。

XPath式をテストするには:

1. メッセージ・フロー・アクションでXPath式を作成または更新します。
2. 式の定義が終わったら、「検証」をクリックして式が有効であることを確認します。
3. 「テスト」をクリックします。

   テスト・コンソールが現れ、テストする式が表示されます。

4. 「データ入力」セクションで、XML入力を入力してリソースのテスト・データを構成します。

   • このセクションには、このXPath式のテスト対象のXMLドキュメントに対応する1つの入力フィールドが表示されます。

   • XML入力はファイル・ベースまたはテキスト・ベースで入力できます。テキスト入力よりファイルの参照による入力が優先されます。テストに使用するファイルを参照して選択します。

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

   テスト・コンソールに結果が表示されます。

6. もう一度テストする場合は、「戻る」をクリックします。テスト・コンソールを閉じたら、リソースを変更し、再度テストできます。

   XPath式を変更してからもう一度テストを実行する場合、変更を有効にするには、テスト・コンソールを閉じて開きなおす必要があります。

58.8 OWSMセキュリティを含むサービスのテスト

テスト・コンソールは、OWSMセキュリティ・ポリシーで保護されたプロキシ・サービスとビジネス・サービスのテストをサポートします。

サービスにOWSMポリシーがアタッチされている場合、テスト・コンソールとサービスとの間のメッセージのやり取りはポリシーによって保護されます。テスト・サービスは、ポリシーに従って、デジタル署名を施すか、メッセージ(正確にはメッセージの一部)を暗号化し、該当するセキュリティ・トークンを含めます。「リクエスト・ドキュメント・テスト・コンソール・プロパティ」に説明されているとおり、指定されたクリアテキストSOAPエンベロープでのデジタル署名操作および暗号化操作に対する入力を指定します。

テスト・コンソールでサービス・キー・プロバイダを指定すると、WS-Securityで要求されるクライアント側のすべてのPKIキー・ペア資格証明がサービス・キー・プロバイダから取得されます。操作のリクエスト・ポリシーでIDアサーションが指定されており、サポートされるトークン・タイプの1つがユーザー名トークンである場合は、「ユーザー名」フィールドと「パスワード」フィールドを使用します。

表58-3と表58-4にセキュリティ・シナリオを示します。

表58-3 デジタル署名と暗号化のシナリオ

シナリオ	サービス・キー・プロバイダの必要性
リクエスト・ポリシーにConfidentialityアサーションがあります。	いいえ。テスト・サービスは、サービスの公開キーでリクエストを暗号化します。プロキシ・サービスをテストする場合、テスト・サービスは、プロキシ・サービスのサービス・キー・プロバイダに割り当てられた暗号化証明書から公開キーを自動的に取得します。 ビジネス・サービスをテストする場合、暗号化証明書はビジネス・サービスのWSDLファイルに埋め込まれます。テスト・サービスは、WSDLリポジトリからこのWSDLファイルを自動的に取得し、WSDLファイルから暗号化証明書を取り出します。
レスポンス・ポリシーにConfidentialityアサーションがあります。	「はい」。このシナリオでは、操作ポリシーは、クライアントが証明書をサービスへ送信することを要求します。サービスは、この証明書の公開キーを使用し、クライアントへのレスポンスを暗号化します。サービス・キー・プロバイダを指定する必要があり、このサービス・キー・プロバイダには、暗号化資格証明が関連付けられている必要があります。 リクエストとレスポンスの両方の暗号化がサポートされている場合、異なる資格証明を使用する必要があります。
リクエスト・ポリシーにIntegrityアサーションがあります。	「はい」。クライアントはリクエストに署名する必要があります。サービス・キー・プロバイダを指定する必要があり、このサービス・キー・プロバイダには、デジタル署名資格証明が関連付けられている必要があります。 さらに、このIntegrityアサーションがSAML holder-of-keyの場合は、サービス・キー・プロバイダに加え、ユーザー名とパスワードも必要です。
レスポンス・ポリシーにIntegrityアサーションがあります。	いいえ。この場合、ポリシーは、サービスがレスポンスに署名する必要があることを指定します。サービスは、秘密キーでレスポンスに署名します。テスト・コンソールはこの署名を確認するのみです。 プロキシ・サービスをテストする場合、プロキシ・サービスのサービス・キー・プロバイダのデジタル署名資格証明に関連付けられた秘密キーが使用されます。 ビジネス・サービスをテストする場合、サービスは、サービスをホストするシステムに製品固有の方法で構成されたキー・ペアを使用して署名します。 現在のセキュリティ・レルムが証明書検索および検証を実行するように構成されている場合、サービス・キー・プロバイダに割り当てられる証明書は、証明書検索および検証フレームワークに登録され、有効である必要があります。 証明書ルックアップと検証の詳細は、『Oracle WebLogic Serverセキュリティの管理』の証明書ルックアップおよび検証フレームワークの構成に関する項を参照してください。

表58-4 IDポリシーのシナリオ(ポリシーにIDアサーションが含まれている場合)

サポートされるトークン・タイプ(リクエスト・ポリシー内のIDアサーションから)	説明	コメント
UNT	サービスがWSSユーザー名トークンのみを使用	「セキュリティ」パネルでユーザー名とパスワードを指定する必要があります。
X.509	サービスがWSS X.509トークンのみを使用	「セキュリティ」パネルでサービス・キー・プロバイダを指定する必要があります。このサービス・キー・プロバイダには、WSS X.509資格証明が関連付けられている必要があります。
SAML	サービスがWSS SAMLトークンのみを使用	「セキュリティ」パネルまたは「トランスポート」パネルで、ユーザー名とパスワードを指定する必要があります。両方のパネルで指定した場合は、「セキュリティ」パネルのユーザー名とパスワードがSAMLトークンのIDとして使用されます。
UNT、X.509	サービスがUNTまたはX.509トークンを使用	「セキュリティ」パネルで、ユーザー名とパスワードを指定します。または、WSS X.509資格証明が関連付けられているサービス・キー・プロバイダを「セキュリティ」パネルで指定する必要があります。両方指定した場合は、UNTトークンのみが生成されます。
UNT、SAML	サービスがUNTまたはSAMLトークンを使用	「セキュリティ」パネルまたは「トランスポート」パネルで、ユーザー名とパスワードを指定する必要があります。両方指定した場合は、UNTトークンのみが送信されます。
X.509、SAML	サービスがX.509またはSAMLトークンを使用	次のいずれかを指定する必要があります。 「セキュリティ」パネルでユーザー名とパスワード 「トランスポート」パネルでユーザー名とパスワード WSS X.509資格証明が関連付けられているサービス・キー・プロバイダ
UNT、X.509、SAML	サービスがUNT、X.509、またはSAMLトークンを使用	次のいずれかを指定する必要があります。 「セキュリティ」パネルでユーザー名とパスワード 「トランスポート」パネルでユーザー名とパスワード WSS X.509資格証明が関連付けられているサービス・キー・プロバイダ

58.8.1 サービスとポリシーの制限

SAMLポリシーを持つプロキシ・サービスとSAML holder-of-keyポリシーを持つビジネス・サービスのテストには、次の制限があります。

• インバウンドSAMLポリシーを持つプロキシ・サービスのテストはサポートされていません。

• SAML holder-of-keyポリシーを持つビジネス・サービスのテストは特殊なケースです。SAML holder-of-keyのシナリオは、次の2とおりの方法で構成できます。

  • 整合性ポリシーとして(推奨アプローチ)

  • IDポリシーとして

  どちらの場合も、ユーザー名とパスワードを指定する必要があります。SAMLアサーションはこのユーザーの代理として機能します。SAML holder-of-keyが整合性ポリシーとして構成されている場合は、サービス・キー・プロバイダも指定する必要があります。このサービス・キー・プロバイダには、デジタル署名資格証明が割り当てられている必要があります。これは、IDポリシーがない場合でもユーザー名とパスワードを指定する必要がある唯一のケースであり、特殊なケースです。

  ノート:

  テスト・コンソールでテストを実行した後、WSSで生成されたエンベロープが必ずしも有効なエンベロープというわけではありません。テスト・コンソールの結果ページには、読みやすくするために空白が挿入されています。つまり、保護されたSOAPメッセージは、ホワイト・スペースが追加された状態で表示されます。ホワイト・スペースはドキュメントのセマンティクスに影響する可能性があるため、このようなSOAPメッセージはリテラル・データとして必ずしも使用できるわけではありません。たとえば、デジタル署名はホワイト・スペースの影響を受け、無効になることがあります。

58.9 セキュリティとトランスポートについて

テスト・コンソールを使用してBASIC認証でHTTPビジネス・サービスをテストする場合、テスト・コンソールは、ビジネス・サービスのサービス・アカウントのユーザー名とパスワードを認証します。

同様に、認証を必要とするJMS、電子メールまたはFTPビジネス・サービスをテストする場合、テスト・コンソールは、そのビジネス・サービスに関連付けられたサービス・アカウントを認証します。

テスト・コンソールでは、プロキシ・サービスをテストするときに、HTTPリクエストはネットワーク経由で送信されません。そのため、トランスポート・レベルのアクセス制御は適用されません。

58.10 テスト・コンソールのアンデプロイ

Oracleは、本番システムでテスト・フレームワークを使用しないことをお薦めします。たとえば、パイプラインのテストでは、アクセス制御を含む重要なセキュリティ・ステップの一部がバイパスされます。

Service Busドメインを作成する場合、構成ウィザードには、デフォルトで、管理サーバーおよびすべての管理対象サーバーのターゲットとしてALSBテスト・フレームワーク(テスト・コンソール)が含まれます。次の項では、テスト・コンソールをアンデプロイする様々なオプションについて説明します。

• ドメイン作成前のテスト・コンソールの割当て解除

• サーバーが実行されている場合のテスト・コンソールの割当て解除

• サーバーが実行されていない場合のテスト・コンソールの割当て解除

58.10.1 ドメイン作成前のテスト・コンソールの割当て解除

ドメインの作成前に、Oracle Fusion Middleware構成ウィザードでテスト・コンソールを割当て解除するには:

1. 構成ウィザードを使用してService Busドメインを作成する場合、「デプロイメントとサービス」のオプションの構成を選択します。
2. 後続の関連ウィザード・ページで、サーバーごとに、「ターゲット」パネルでService Busテスト・フレームワークを選択し、左矢印をクリックしてそれを「デプロイメント」パネルに移動します。

ウィザードによってドメインが作成される場合は、テスト・コンソール(OSB_ORACLE_HOME\lib\apps\TestFwk.ear)はデプロイされません。

58.10.2 サーバーが実行されている場合のテスト・コンソールの割当て解除

すでにテスト・コンソールがService Busサーバーにデプロイされ、サーバーが実行中の場合は、テスト・コンソールをアンデプロイできます。

実行中のService Busドメイン上のテスト・コンソールをアンデプロイするには:

1. Oracle WebLogic Server管理コンソールを起動し、ログインします。
2. 左側のナビゲーション・ペインの「ドメイン構造」の下にある「デプロイメント」をクリックします。

   「デプロイメントのサマリー」ページが表示されます。

3. 「デプロイメント」表で、Service Busテスト・フレームワークをクリックします。

   Service Busテスト・フレームワークの「概要」ページが表示されます。

4. 「ターゲット」タブをクリックします。
5. 「ターゲットの割当」表のService Busテスト・フレームワークの横のチェック・ボックスを選択して、すべてのフレームワーク・リソースを選択します。
6. 「ターゲットの変更」をクリックします。
7. 「デプロイメントのターゲット指定」ページで、管理サーバーおよびすべての管理対象サーバーの横のチェック・ボックスをクリアします。
8. 「はい」をクリックします。

   設定が正常に更新されたことを示すメッセージが表示されます。

58.10.3 サーバーが実行されていない場合のテスト・コンソールの割当て解除

Service Busドメインが実行されていない場合は、WebLogic Scripting Tool (WLST)を使用して、ドメインからテスト・コンソールのターゲット設定を解除できます。

WLSTを使用してテスト・コンソールをターゲット設定解除するには:

1. WLSTを使用する環境が設定されていない場合は、『WebLogic Scripting Toolの理解』の対話モードまたはスクリプト・モードでのWLSTの主な使用ステップに関する項を参照してください。
2. 次のコマンドを使用してWLSTをオフラインで呼び出します。

   C:>java weblogic.WLST
   

   ノート:

   このコマンド用に環境が適切に設定されている必要があります。お使いのオペレーティング・システムに応じて、WL_HOME/server/binからsetWLSEnv.cmdまたはsetWLSEnv.shを実行します。

3. 構成ウィザードを使用して作成したドメインを読み取るために、次のコマンドを実行します。

   wls:/offline>readDomain('C:/oracle/user_projects/domains/domain_name')
   

4. Service Busテスト・フレームワーク・アプリケーションをターゲット設定解除するには、次のコマンドを実行します。

   wls:/offline/domain_name>unassign("AppDeployment", "Service Bus Test Framework", "Target", "AdminServer", "ManagedServer_1", "ManagedServer_2")
   

   このコマンドにはすべての管理対象サーバーの名前を含めます。

5. ドメインを更新するには、次のコマンドを実行します。

   wls:/offline/base_domain>updateDomain()
   

6. ドメインを閉じるには、次のコマンドを実行します。

   wls:/offline/base_domain>closeDomain()
   

7. 終了するには、WLSTコマンド・プロンプトから次のコマンドを実行します。

   wls:/offline>exit()
   

58.11 サービスのテスト・コンソール・ページ参照

この項では、Service Busサービスをテストする際に、Oracle Service Busテスト・コンソールに表示される各セクションについて説明します。すべてのコンポーネントですべてのセクションが表示されるわけではなく、セクションの一部はテストするコンポーネントによって異なります。

テスト・コンソール・リクエスト・ページには、テストするサービスのタイプと、それが使用しているメッセージングのタイプに応じて、次のセクションの組合せが含まれます。

• テスト構成テスト・コンソール・プロパティ

• サービス操作テスト・コンソール・プロパティ

• リクエスト・ドキュメント・テスト・コンソール・プロパティ

• セキュリティ・テスト・コンソール・プロパティ

• 認証テスト・コンソール・プロパティ

• トランスポート・テスト・コンソール・プロパティ

• 添付テスト・コンソール・プロパティ

58.11.1 テスト構成テスト・コンソール・プロパティ

このセクションはパイプラインをテストする場合のみ表示され、1つのフィールド「トレースを含む」が含まれます。このチェック・ボックスを選択すると、各処理ステージでのメッセージの状態のトレースが含まれます。

58.11.2 サービス操作テスト・コンソール・プロパティ

このセクションは、操作するWSDLファイルに基づいてプロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合をテストする場合、およびRESTfulプロキシまたはビジネス・サービスをテストする場合に表示されます。このセクションに表示されるされるフィールドは、サービスがWSDLベースかRESTfulか、およびRESTfulビジネス・サービスのSOAPビューまたはRESTビューのどちらを選択するかによって異なります。

RESTfulビジネス・サービスでは、RESTビューに純粋なRESTサービスとして情報が表示されます。SOAPビューでは、データを参照する呼出し元(パイプライン)として(WSDL SOAPサービスとしてラップされた)情報が表示されます。SOAPビューのフィールドはWSDLベース・サービスのフィールドと同じです。

表58-5 テスト・コンソール・プロパティ - サービス操作

プロパティ	説明
操作	サービスに関連付けられている操作のリストから、テストするWSDL操作を選択します。このフィールドはWSDLベース・サービスおよびRESTfulビジネス・サービスのSOAPビューで使用できます。
リソース	リストから既存のURLリソース・パスを選択します。リソースとは指定可能な特定の情報の任意のソースです。このフィールドは、RESTfulサービスのテスト時にのみ使用できます。
方式	実行するREST操作を選択します。このフィールドは、RESTfulサービスのテスト時にのみ使用できます。
承認	オプションのリストから、テスト入力用に承認されるメディア・タイプを選択します。オプションはサービス構成によって異なります。このフィールドは、RESTfulサービスのテスト時にのみ使用できます。

58.11.3 リクエスト・ドキュメント・テスト・コンソール・プロパティ

入力フィールドによって、プロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合へ送信されるリクエスト・メッセージが生成されます。「リクエスト・ドキュメント」セクションに入力する値は、サービス・タイプに固有です。それぞれで必要とされる入力のサービス・タイプと説明を以下に示します。

呼出しモード・オプションは、任意のSOAPまたは任意のXMLプロキシ・サービスをテストする場合にのみ表示されます。一方向のサービス呼出しの場合は、「リクエスト/レスポンス」チェックボックスをクリアします。リクエスト/レスポンス呼出しのチェック・ボックスを選択します。

表58-6 テスト・コンソール・プロパティ - リクエスト・ドキュメント

サービス・タイプ	説明
WSDL	複数の操作が定義されたWSDLベースのサービスの場合、テスト・コンソールはサービスのテスト時に使用するサンプル・ドキュメントを生成および提供します。このサンプル・データを直接使用し、編集してテストを実行するか、または、独自のテスト・データを指定します。
任意のXML	ペイロードの形式でリクエスト入力を入力します。ペイロードは、送信されるメッセージのコンテンツです。コンテンツはXMLドキュメントであることが想定されます。ファイルを参照することも、テキスト・ボックスにメッセージ・コンテンツを直接入力することもできます。
任意のSOAP	ペイロードの形式でリクエスト入力を入力します。ペイロードは、送信されるメッセージのコンテンツです。コンテンツはSOAPエンベロープであることが想定されます。ファイルを参照することも、テキスト・ボックスにメッセージ・コンテンツを入力することもできます。
メッセージング	ファイルベースまたはテキストベースで単一の入力を入力します。メッセージ・サービスによって、バイナリ、Java、MFL、XML、テキストを含む各種入力タイプが定義されます。タイプがnoneの場合、入力は必要ありません。 Oracleでは、ファイルからのバイナリの入力をお薦めします。テキスト領域に入力したデータは、システム・エンコーディングでバイナリに変換されます。 テキスト型のサービスの場合、ファイルから入力したデータはテキストへの変換が必要です。エンコーディング入力フィールドでは、変換時に適用するエンコーディングを指定します。このフィールドを構成しない場合は、システム・エンコーディングが使用されます。デフォルトでは、エンコーディング・フィールドはプロキシ・サービスのエンドポイントに構成されたエンコーディング値で初期化されます。
SOAPドキュメント	SOAPドキュメントの場合、SOAPエンベロープは通常0個以上のヘッダーと1つの本体ペイロードで構成されます。「フォーム」タブと「XML」タブではそれぞれ異なる方法でコンテンツを指定します。 「フォーム」タブには「SOAPヘッダー」フィールドと「SOAP本体」フィールドがあります。「SOAPヘッダー」フィールドの内容は、SOAP Headerタグであることが想定されます(これにより1つ以上のヘッダーを定義できます)。「SOAP本体」フィールドには実際にメッセージの一部として送信されるデータが含まれます。コンテンツはXMLドキュメントであることが想定されます。ヘッダーと本体の両方を使用してSOAPエンベロープが生成されます。
SOAP RPC	SOAP RPCの場合、SOAPエンベロープは0個以上のヘッダーと0個以上の引数で構成される。「フォーム」タブと「XML」タブではそれぞれ異なる方法でコンテンツを指定します。 「フォーム」タブにはSOAPヘッダーの入力が1つと、引数ごとに1つの入力フィールドがあります(入力フィールドの名前は引数の名前に相当します)。「SOAPヘッダー」フィールドの内容は、SOAP Headerタグであることが想定されます(これにより1つ以上のヘッダーを定義できます)。 テスト・コンソールはWSDLファイルを使用して、各引数のタイプを検出します。プリミティブの型の場合は1行の入力フィールドを使用し、XMLの型の場合は複数行の入力フィールドを使用します。テストを効率化するサンプル・ドキュメントが自動的に生成されます。 テスト・コンソールにより、ヘッダーと引数を使用してSOAPエンベロープが生成されます。 「XML」タブには1つの入力フィールドがあります。このフィールドの内容は、送信されるSOAPエンベロープであることが想定されます。ペイロード(XML入力)はファイル・ベースまたはテキスト・ベースです。テキスト入力よりファイルの参照による入力が優先されます。テストに使用するファイルを参照して選択します。
REST	RESTfulサービスの入力は、テストするリソース、およびSOAPビューまたはRESTビューのどちらを使用しているかによって異なります。 SOAPビューで、ペイロードの形式でリクエスト入力を行います。ペイロードは、送信されるメッセージのコンテンツです。「参照」をクリックしてファイルへの移動またはファイルの選択を行うか、テキスト・ボックスにメッセージ・コンテンツを入力します RESTビューで、RESTパラメータの形式またはペイロードの形式でリクエスト入力を行うことができます。パラメータ・フィールドが表示される場合は、各パラメータの入力を行ってください。「ペイロード」フィールドが表示されている場合は、オプションのリストからメディア・タイプを選択してから、「参照」をクリックしてファイルへの移動またはファイルの選択を行うか、テキスト・ボックスにメッセージ・コンテンツを入力します

58.11.4 セキュリティ・テスト・コンソール・プロパティ

テストするサービスがOWSMポリシーを使用して保護されている場合は、テスト・コンソールに「セキュリティ」パネルが表示されます。オーバーライド値を変更したり、セキュリティ・ポリシーを追加または削除したりできます。別のポリシーをテストするには、「追加」ボタンをクリックし、テストするポリシーを選択します。詳細は、「Oracle Web Services Managerを使用したOracle Service Busのセキュリティ」を参照してください。

表58-7 テスト・コンソール・プロパティ - セキュリティ

プロパティ	説明
ポリシー名	テストするサービスにアタッチされたOWSMポリシーの名前が表示されます。
プロパティ	リストされたポリシーについて、使用可能な各オーバーライド・プロパティの名前が表示されます。使用可能なプロパティは、アタッチされたポリシーに応じて異なります。
デフォルト値	各オーバーライド・プロパティのデフォルト値が表示されます(存在する場合)。
オーバーライド値	サービスのテスト時にオーバーライド・プロパティに使用する値を入力します。
アクション	この列の「削除」アイコンをクリックすると、テスト目的でアタッチされたポリシーが削除されます。

58.11.5 認証テスト・コンソール・プロパティ

テストしているサービスがSAMLトークンを想定しているビジネス・サービスへメッセージをルーティングする場合は、これがトークンで表されるIDになります。詳細は、「Oracle Service BusでのSAMLの使用」を参照してください。

表58-8 テスト・コンソール・プロパティ - 認証

プロパティ	説明
ユーザー名	サービスを呼び出したときにテスト・サービスによって使用されるセキュリティ・コンテキストを設定するためのユーザー名を入力します。このフィールドをWebサービス・セキュリティ(WSS)のユーザー名フィールドと混同しないでください。これは、ローカル・セキュリティ・レルムで有効なユーザー名とパスワードである必要があります。ユーザー名またはパスワードが無効な場合、テスト・サービスでクライアント側のエラーが発生します。 ノート: HTTPカスタム・トークン認証を使用するプロキシをテスト・コンソールで呼び出した場合、認証チェックは行われません。
パスワード	ユーザー名に関連付けられるパスワードを入力します。
サービス・キー・プロバイダ	認証に使用するサービス・キー・プロバイダを入力します。このフィールドは、 クライアントの証明書認証を使用するHTTPSビジネス・サービスをテストする場合に使用します。サービス・プロバイダにはSSLクライアント資格が関連付けられている必要がある。テスト・サービスはSSLハンドシェイクでその資格証明を使用します。

58.11.6 トランスポート・テスト・コンソール・プロパティ

テスト・コンソールの「トランスポート」パネルでは、テスト・システムのメッセージのメタデータとトランスポート・ヘッダーを指定します。次の項では、トランスポート設定とそれらが処理に及ぼす影響について説明します。

• テスト・コンソールのトランスポート設定

• テスト・コンソールでのランタイムによるトランスポート設定の使用方法

58.11.6.1 テスト・コンソールのトランスポート設定

テスト・コンソールの「トランスポート」セクションは、テストするトランスポートのタイプにより異なります。図58-4に、WSDLベースのプロキシ・サービスの「トランスポート」セクションを示します。

図58-4 テスト・コンソールの「トランスポート」パネル

「図58-4 テスト・コンソールの「トランスポート」パネル」の説明

パイプラインのメタデータとトランスポート・ヘッダーを設定すると、アウトバウンド・トランスポートのアクションに影響します。メタデータ、メッセージ、およびヘッダーをテストして、パイプライン出力を表示できます。プロキシ・サービスのテスト時に「トランスポート」パネルに表示されるフィールドは、パイプラインで使用できるヘッダーとメタデータを表します。プロキシ・サービスによっては、テスト・コンソールに表示されるフィールドをフィルタできない場合もあります。HTTPベースのすべてのリクエストに対して、トランスポート・パラメータの同じセットが表示されます。

「ユーザー名」と「パスワード」フィールドは、プロキシ・サービスを実行しているユーザーの基本認証を実装するために使用されます。「ユーザー名」と「パスワード」フィールドは、特にトランスポートとの関連はありません。

メタデータ・フィールドは、「ユーザー名」フィールドおよび「パスワード」フィールドと、トランスポート・ヘッダー・フィールドの間に配置されています。表示されるフィールドは、サービスのトランスポート・タイプに基づいています。サービスを定義したときに選択した操作選択アルゴリズムに応じて、事前移入されているフィールドもあります。選択アルゴリズムの詳細は、「Oracle Service Busでのメッセージ・フローの作成」を参照してください。

テストするサービスのタイプに応じて、「トランスポート」パネルのフィールドに値を指定します。パイプラインまたは分割-結合をテストする場合、テスト・データは、呼出し元から離れ、テストするサービスに渡される時点で予期される状態のメッセージを表す必要があります。ビジネス・サービスをテストする場合、テスト・データは、ルート・ノードまたはサービス・コールアウトから送信されるデータを表します。

次のプロパティは、大半のトランスポート・タイプで共通です。特定のヘッダーおよびメタデータの詳細と、テスト・フレームワークでそれらが処理される仕組みについては、「テスト・コンソールでのランタイムによるトランスポート設定の使用方法」を参照してください。

表58-9 テスト・コンソール・プロパティ - トランスポート

プロパティ	説明
ユーザー名	テストを実行しているユーザーに対してBasic認証を実装するためのユーザー名を入力します。これはトランスポート固有ではありません。
パスワード	上記で入力したユーザー名のパスワードを入力します。
リクエスト/レスポンス	一方向のサービス呼出しの場合は、「リクエスト/レスポンス」チェックボックスをクリアします。リクエスト/レスポンス呼出しのチェック・ボックスを選択します。このオプションは、任意のSOAPまたは任意のXMLプロキシ・サービスをテストする場合にのみ表示されます。
サービス・キー・プロバイダ	認証に使用するサービス・キー・プロバイダを入力します。このフィールドは、 クライアントの証明書認証を使用するHTTPSビジネス・サービスをテストする場合に使用します。サービス・プロバイダにはSSLクライアント資格が関連付けられている必要がある。テスト・サービスはSSLハンドシェイクでその資格証明を使用します。

58.11.6.2 テスト・コンソールでのランタイムによるトランスポート設定の使用方法

「トランスポート・テスト・コンソール・プロパティ」では、テスト・コンソールでプロキシ・サービスまたはビジネス・サービスをテストするときに、アウトバウンド・リクエストのトランスポート・ヘッダー、トランスポート・メタデータおよびトランスポート関連のセキュリティ・データの値を構成する方法が説明されています。ただし、テスト・コンソールで作成できる仕様の一部は、実行時に無視されます。つまり、特定のヘッダーやメタデータの値は、テストの実行時にService Busランタイムで上書きされるか無視されます。制限のあるヘッダーとメタデータについては、表58-10を参照してください。

表58-10 テスト・コンソールで指定するトランスポート・ヘッダーとメタデータの値の制限

トランスポート	サービス・タイプ	制限の説明	影響を受けるトランスポート・ヘッダー
HTTP(S) ノート: プロキシ・サービスをテストするときに、テスト・コンソールではネットワーク経由でHTTPリクエストを送信しないため、トランスポートレベルのアクセス制御は適用されません。	プロキシ・サービス	実行時に、設定したすべてのトランスポート・ヘッダーとその他のフィールドが保持されます。	すべて
HTTP(S)	ビジネス・サービス	これらのパラメータに設定したすべての値がService Busランタイムでオーバーライドされます。	Content-Length Content-Type relative-URI client-host client-address
JMS	プロキシ・サービス	トランスポート・ヘッダー・アクションの構成と同じ制限が適用されます。	表12-8に示すJMSトランスポート・ヘッダーの制限を参照してください。
JMS	ビジネス・サービス	トランスポート・ヘッダー・アクションの構成と同じ制限が適用されます。	表12-8に示すJMSトランスポート・ヘッダーの制限を参照してください。
email	プロキシ・サービス	制限はありません。実行時に、設定したトランスポート・ヘッダーとその他のフィールドが保持されます。	なし
email	ビジネス・サービス	これらのパラメータに設定したすべての値がService Busランタイムでオーバーライドされます。	Content-Type
File	プロキシ・サービス	制限はありません。実行時に、設定したトランスポート・ヘッダーとその他のフィールドが保持されます。 たとえば、FileName (トランスポート・メタデータ)に指定した値は、出力ファイル名に付加されますたとえば、1698922710078805308-b3fc544.1073968e0ab.-7e8e-{$FileName}です。	なし
File	ビジネス・サービス	制限なし	なし
FTP	プロキシ・サービス	制限はありません。実行時に、設定したトランスポート・ヘッダーとその他のフィールドが保持されます。	なし
FTP	ビジネス・サービス	制限なし	なし

58.11.7 添付テスト・コンソール・プロパティ

テスト・コンソールの「添付」セクションを使用して、添付をテスト入力の一部として含めます。表58-11は、このセクションのプロパティを示しています。

表58-11 プロキシ・サービス・テスト・コンソール・プロパティ

プロパティ	説明
Content-Type	添付を識別するグローバルに一意の参照を入力します。
Content-ID	添付のメディア・タイプとサブタイプを入力します。
Content-Description	コンテンツの簡単な説明を入力します。
Content-Disposition	プロキシ・サービスが添付を処理する方法を指定します。
Content-Transfer-Encoding	添付のエンコード方法を指定します。
File	添付としてテストするファイルを参照して選択します。
Resp.Attach.Display Limit	テスト結果の表示に含める添付の文字数。