この章では、本番環境でのテスト・コンソールのアンデプロイ方法を含め、Service Busテスト・コンソールを使用したサービスのテストについてのガイドラインと情報を示します。
この章の内容は次のとおりです。
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操作もテストできません。
プロキシ・サービスをテストする場合、メッセージはトランスポート・レイヤーを介してプロキシ・サービスへ送信されます。トランスポート・レイヤーでは、テストの一環としてメッセージ・ヘッダーまたはメタデータの操作を実行します。テスト用に入力する構成データは、クライアントからプロキシ・サービスへ送信されるデータをシミュレートします。プロキシ・サービス・テストのレスポンスは、システム内の次のコンポーネントへ送信されるメッセージです。これは、前バージョンのService Busの間接コールに緩やかに関連付けられます。
このテスト・アプローチと、テスト・コンソールの「トランスポート」セクションにあるカスタム(アウトバウンド)トランスポート・ヘッダーの設定を使用して、サービス・コールを正確にシミュレートします。トランスポート設定の詳細は、「テスト・コンソールのトランスポート設定」を参照してください。
注意:
リクエスト/レスポンスMQまたはJMSのプロキシ・サービスのテストは動作しません。messageIDに基づく相関を使用したMQまたはJMSリクエスト/レスポンス・プロキシ・サービスへのコールからのレスポンスは、テスト・コンソールには表示されません。MQまたはJMSリクエスト/レスポンス・プロキシ・サービスをテストした場合、レスポンスはレスポンス・キューに保持されますが、テスト・コンソールには表示されません。
パイプラインをテストする場合、入力メッセージは直接パイプラインへ送信されます。デフォルトでトレースが有効になり、テスト・コンソールでメッセージ・フローの診断とトラブルシューティングが可能になります。テスト・コンソールに入力する入力データは、呼出し元のプロキシ・サービスのパイプラインが想定するデータである必要があります。つまり、テスト・コンソールは、パイプラインを呼び出すプロキシ・サービスのロールを担います。これは、前バージョンのService Busの直接コールに緩やかに関連付けられます。
パイプラインのテストでは、内部メッセージ・フロー・ロジックがテストされます。このテスト・アプローチと、テスト・コンソールの「トランスポート」パネルにあるカスタム(インバウンド)トランスポート・ヘッダーの設定を使用して、サービス呼出しを正確にシミュレートします。
パイプラインを介したメッセージのトレースでは、メッセージ・フローの様々なポイントで、メッセージ・コンテキストの確認と、アウトバウンドを行う通信が発生します。メッセージを検査するポイントはService Busで事前に定義され、ステージ、エラー・ハンドラおよびルート・ノードに対して定義されます。トレースのステージごとに、メッセージ・コンテキストに発生した変更と、そのステージの実行中に呼び出されたすべてのサービスが含まれます。
トレースには次のステージ情報が含まれます。
初期メッセージ・コンテキスト: プロキシ・サービスが呼び出されたときに、プロキシ・サービスが初期化した変数を表示します。変数の値を確認するには、変数名に対応する+記号をクリックします。
新しい変数: すべての新しい変数の名前と値。変数を展開すると、その値が表示されます。
削除された変数: 削除されたすべての変数の名前。
変更された変数: ステージを経由してメッセージを処理した結果として変更された$header
、$body
、$inbound
を含め、値が変更されたすべての変数の名前。変数を展開すると、新しい値が表示されます。
フォルト: エラーが発生した場合に、ステージ・エラー・ハンドラが検証エラーを処理した結果として、fault
コンテキスト変数($fault
)のコンテンツが表示されます。
パブリッシュ: すべてのパブリッシュ・コールがリストされます。トレースには、パブリッシュ呼出しごとに、呼び出されたサービスの名前と、outbound
、header
、body
およびattachment
の各変数の値が含まれます。
サービス・コールアウト: すべてのサービス・コールアウトがリストされます。トレースには、サービス・コールアウトごとに、呼び出されたサービスの名前、outbound
変数の値、リクエスト・メッセージとレスポンス・メッセージのheader
、body
およびattachment
の各変数の値が含まれます。
ルート・ノードについても、ステージと同様の情報が含まれます。ルート・ノードの場合、トレースには次のカテゴリの情報が含まれます。
リクエスト・パスでのサービス呼出しのトレース
ルーティングされたサービスのトレース
レスポンス・パスでのサービス呼出しのトレース
(リクエスト・パスの)ルート・ノードの開始ポイントと(レスポンス・パスの)終了ポイントの間でメッセージ・コンテキストに加えられた変更
注意:
ログ・ファイルまたは標準出力(サーバー・コンソール)にトレースを表示するには、WebLogic Serverのロギングを次の重大度に設定する必要があります。
ログの最低の重大度: 情報
ログ・ファイル: 情報
標準出力: 情報
ログの重大度の設定の詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタリング』のログの重大度の使用に関する項を参照してください。
ビジネス・サービスの入力テスト・データは、ビジネス・サービスの呼出し元のパイプライン、分割-結合またはプロキシ・サービスから受信したときにビジネス・サービスが想定する形式になっている必要があります。たとえば、ルート・ノードやパイプラインのサービス・コールアウト・アクションからのデータなどが考えられます。テスト・コンソールを使用してビジネス・サービスをテストする場合、テスト・コンソールは呼出し側のサービスの役割を果たします。ビジネス・サービスをテストする場合、メッセージは必ずトランスポート・レイヤーを経由してルーティングされます。
ビジネス・サービスをテストする場合は、テスト中のビジネス・サービスがリモート・ドメインにある場合でも、テスト・コンソールで指定されたユーザー名およびパスワードが、ローカルService Busドメインに存在することを確認します。テスト・サービスは、プロキシ・サービスまたはビジネス・サービスを呼び出す前に、ローカル認証を実行します。
図58-1に示すシナリオでは、クライアントがプロキシ・サービスPS1を呼び出し、それによってパイプラインP1が呼び出されています。パイプラインは、パイプラインP2、ビジネス・サービスB1、ローカル・プロキシ・サービスPS2の順に呼び出してから、メッセージをクライアントに返します。インタフェースを番号で示しています。
このシナリオには、有効なテスト方法がいくつもあります。次が推奨されます。
最初に初期プロキシ・サービス以外のインタフェースのテストを完了します。つまり、図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のテストは、実際にはシステム全体のテストです。システムの他のすべてのインタフェースが正しく機能していることを確認することで、システム・エラー発生時のトラブルシューティングの範囲を絞り込むことができます。
プロキシ・サービスをテストするときに、テスト・コンソールではネットワーク経由でHTTPリクエストを送信しないため、トランスポート・レベルのアクセス制御は適用されません。トランスポート・レベルのアクセス制御は、Webアプリケーション・レイヤーを介して実現されます。トランスポート・レイヤーのメッセージ処理の詳細は、「メッセージ処理」を参照してください。トランスポート設定の詳細は、「ランタイムがテスト・コンソールでトランスポート設定を使用する方法」を参照してください。
特定のService Busサービスをテストするためにテスト・コンソールにアクセスする方法は複数あり、Oracle Service Busコンソール、JDeveloperまたはFusion Middleware Controlからアクセスできます。
プロキシ・サービス、ビジネス・サービス、パイプラインおよび分割-結合は、セッションの外部でのみテストできます。トランスフォーメーションはセッションの外部でも内部でもテストできます。
注意:
テスト・コンソール・サービスが実行されていないことを示すエラーを受信した場合は、管理サーバーがlocalhostなどの特定の有効なアドレスをリスニングするように設定してみます。Oracle WebLogic Server管理コンソールの「環境」→「サーバー」→「admin_server_name」→「構成」→ >「全般」を選択し、「リスニング・アドレス」を設定します。また、クラスタではすべての管理対象ノードが実行されていることを確認します。
テスト・コンソールを使用するには、事前に次の準備が整っている必要があります。
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コンソールで「プロキシ・サーバーを開く」をクリックして、「トランスポート」サブタブをクリックします。
Oracle Service Busコンソールで、コンポーネントの定義エディタまたはプロジェクト/フォルダ定義エディタからサービスまたはトランスフォーメーションのテスト・コンソールにアクセスできます。
Fusion Middleware Controlで、サービスの「ダッシュボード」ページからサービスのテスト・コンソールにアクセスできます。Fusion Middleware Controlからはサービスのみテストでき、トランスフォーメーションはテストできません。
Fusion Middleware Controlからテスト・コンソールにアクセスするには:
Service Busサービスをテストする場合、アクティブ・セッションでは実行できません。テスト・コンソールでは、入力、トランスポート・ヘッダー、添付ファイルおよび特定のセキュリティ構成をテストできます。
サービスのテスト方法の詳細は、「テスト・コンソールの概要」を参照してください。
注意:
クラスタリングされたドメインでは、テスト・コンソールを利用して、ビジネス・サービスにルーティングされる構成済のビジネス・サービスまたはプロキシ・サービスをテストすることはできません。
HTTPカスタム・トークン認証を使用するプロキシをテスト・コンソールで呼び出した場合、認証チェックは行われません。
サービスのテスト・コンソールを起動した場合は、テストする操作、メッセージ・ペイロード、トランスポート・ヘッダー、セキュリティ情報を含むテスト入力を構成できます。パイプラインの場合は、様々なコンポーネントを介してメッセージ処理をトレースできます。次の図は、テスト・コンソール・ページの例を示しています。
Service Busサービスをテストするには:
プロキシ・サービス、ビジネス・サービスおよびパイプラインとともに、メッセージ添付ファイルをテストできます。
添付ファイルとともにサービスをテストするには:
パイプラインのトレースを有効にすると、テスト結果にはトレースの詳細が含まれます。トレースは、システムにある問題を追跡し、修正するために問題を切り分けるために使用します。トレース情報は、コード内で要求パスと応答パスを通過した経路を示します。次の図は、パイプライン・トレースの結果を示しています。
トレースの表示中、Service BusコンソールまたはOracle JDeveloperにメッセージ・フローを表示することもできます。これにより、トレースをメッセージ・フローのステージやアクションに対応付けるのが容易になります。メッセージ・フローを変更してから再度トレースを実行し、出力を表示できます。
パイプラインを通じてメッセージをトレースするには:
プロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合をテストする場合、テスト・コンソールのいくつかのセクションに結果が表示されます。表58-1は、テスト結果のセクションを示しています。
表58-1 プロキシ・サービスのテスト結果
セクション | 説明 |
---|---|
リクエスト・ドキュメント |
テスト・コンソールによってサービスに送信されたリクエスト・メッセージです。 リクエスト・メッセージがテスト・コンソールによって変更されなかった場合は、このセクションは最初は折りたたまれています。「フォーム」タブでSOAPサービスを構成した場合、またはWS-Securityが適用されている場合は、このセクションは最初は開かれます。 WS-Securityが適用されている場合、このセクションには2つのSOAPメッセージが表示されます。1番目のメッセージはクリア・テキスト・メッセージで、2番目は保護されたSOAPメッセージです。 |
レスポンス・ドキュメント |
サービスによって生成されたメッセージ・レスポンスです。このセクションには、エラーが発生したかどうかも示されます。 WS-Securityレスポンスが適用されたSOAPサービスの場合、このセクションには2つのSOAPメッセージが表示されます。1つ目のSOAPメッセージは、クライアントが受け取る保護されたメッセージ。2つ目のSOAPメッセージは、対応するクリア・テキストのメッセージ。 |
レスポンス・メタデータ |
メッセージのレスポンスと共に返されたメタデータ。 |
呼出しのトレース |
トレースはパイプラインの場合のみ使用可能で、このセクションにはシステムを経由した際のメッセージの状態が表示されます。これは、テストを実行する前に「トレースを含む」を選択した場合にのみ実行されます。 |
MFL(メッセージ・フォーマット言語)ドキュメントは、バイナリ・データのレイアウトの記述に使用する特殊なXMLドキュメントです。
MFLリソースは、次のトランスフォーメーションをサポートしています。
XMLからバイナリ: 必須入力(XML)が1つと出力(バイナリ)が1つあります。
バイナリからXML: 必須入力(バイナリ)が1つと出力(XML)が1つあります。
各トランスフォーメーションでは、入力を1つだけ受け入れ、出力を1つ返します。MFLトランスフォーメーションは、JDeveloperまたはOracle Service Busコンソールのいずれかからアクセスしたテスト・コンソールを使用して、またはJDeveloperのフォーマット・ビルダー内のテスターを使用してテストできます。
セッションをアクティブ化した後、またはセッション中に、トランスフォーメーションをテストして、リソースが想定したとおりに動作するかどうかを確認できます。セッションをアクティブ化しない場合、テストはローカルでの変更内容を使用して設計時に実行されます。
JDeveloperで、フォーマット・ビルダーの組込みテスト・ツールを使用することもできます。フォーマット・ビルダーからテストを実行する方法の詳細は、「フォーマット定義のテスト」を参照してください。
テスト・コンソールでMFLトランスフォーメーションをテストするには:
表58-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|...
Service Busでは、Extensible Stylesheet Language Transformation (XSLT)を使用してXML間のマッピングを記述します。メッセージ・フローのXQuery式でXSLTトランスフォーメーションを使用できます。
XSLTリソースをテストするには、入力XMLドキュメントを指定する必要があります。テスト・コンソールは、出力XMLドキュメントを返します。XSLTトランスフォーメーションには、トランスフォーメーションに役立つ複数のパラメータを含めることができます。テスト・コンソールに、トランスフォーメーションに必要なパラメータがすべて表示されます。デフォルト値が表示されますが、値はオーバーライドできます。XSLTパラメータは、値としてプリミティブ型またはXMLドキュメントをとります。XSLトランスフォーメーションからパラメータの型を識別することはできません。
XSLTトランスフォーメーション用のテスト・コンソールには、Oracle Service BusコンソールまたはJDeveloperからアクセスできます。JDeveloperでは、XSLTマッパーの組込みテスターも使用できます。
セッションをアクティブ化した後、またはセッション中に、XSLTトランスフォーメーションをテストして、リソースが想定したとおりに動作するかどうかを確認できます。実行時テストを行うには、セッションをアクティブ化する必要があります。それ以外の場合は、ローカルでの変更内容を使用した設計時テストが行われます。
テスト・コンソールを使用してXSLTトランスフォーメーションをテストするには:
XQueryは、データがXMLに物理的に格納されるか、XMLとして表示されるかに関係なく、XMLの構造を使用して、様々な種類のデータに対する問合せを表現します。XQueryトランスフォーメーションは複数の入力をとる場合があります。返される出力は1つです。
XQueryトランスフォーメーションに想定される入力は、定義済の各XQuery外部変数にバインドする変数値です。XQuery入力変数の値には、プリミティブ型の値(string型、integer型、date型)、XMLドキュメント、またはこれらの型のシーケンスを指定できます。出力値は、プリミティブ型の値(string型、integer型、date型)、XMLドキュメント、またはこれらの型のシーケンスになります。
XQueryは型付きの言語で、外部変数ごとに型が決まっています。型は次のグループに分類できます。
単純型/プリミティブ型(string、int、floatなど)
XMLノード
型なし
テスト・コンソールでは、これらの3つの変数がすべてテスト・コンソールの「変数」セクションにリストされ、入力はテストの実行時に構成されます。型なし変数には、デフォルトでXMLが選択されます。これが最も一般的なケースであるためです。
XQueryテストが機能するように、ブラウザのポップアップ・ブロッカを無効にする必要があります。Internet Explorerブラウザでツールバーを使用している場合、「インターネット オプション」メニューでポップアップ・ブロッカを無効にするだけでなく、ポップアップをブロックするように構成されているすべてのツール・バーについてもこの機能を無効にする必要があります。
テスト・コンソールでXQueryテストを実行する場合、新しいテストを実行するには「戻る」ボタンを使用します。ただし、XQueryを変更した後に新しいテストを実行する場合、変更を有効にするには、テスト・コンソールを閉じて再度開く必要があります。
XQueryマップでは、XMLからXML、XMLから非XML、および非XMLからXMLへの各マッピングを記述できます。テスト・コンソールは入力のシーケンスに対応していません。セッションをアクティブ化した後、またはセッション中に、トランスフォーメーションをテストして、リソースが想定したとおりに動作するかどうかを確認できます。実行時テストを行うには、セッションをアクティブ化する必要があります。それ以外の場合は、ローカルでの変更内容を使用した設計時テストが行われます。
テスト・コンソールを使用してXQueryトランスフォーメーションをテストするには:
Oracle Service Busコンソールで式または条件を作成または変更する際、メッセージ・フロー・アクションの式をXQuery/XSLT式エディタ、XQuery条件エディタおよびXPath式エディタからテストできます。
JDeveloperの式ビルダーからテスト・コンソールにアクセスすることもできます。テストは、XQuery/XSLT式エディタおよびXQuery条件エディタの両方で同じ形式をとりますが、XPath式エディタではわずかに異なります。
テスト・コンソールは、OWSMセキュリティ・ポリシーで保護されたプロキシ・サービスとビジネス・サービスのテストをサポートします。
サービスにOWSMポリシーがアタッチされている場合、テスト・コンソールとサービスとの間のメッセージのやり取りはポリシーによって保護されます。テスト・サービスは、ポリシーに従って、デジタル署名を施すか、メッセージ(正確にはメッセージの一部)を暗号化し、該当するセキュリティ・トークンを含めます。「リクエスト・ドキュメント・テスト・コンソール・プロパティ」に説明されているとおり、指定されたクリアテキストSOAPエンベロープでのデジタル署名操作および暗号化操作に対する入力を指定します。
テスト・コンソールでサービス・キー・プロバイダを指定すると、WS-Securityで要求されるクライアント側のすべてのPKIキー・ペア資格証明がサービス・キー・プロバイダから取得されます。操作のリクエスト・ポリシーでIDアサーションが指定されており、サポートされるトークン・タイプの1つがユーザー名トークンである場合は、「ユーザー名」フィールドと「パスワード」フィールドを使用します。
表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トークンを使用 |
次のいずれかを指定する必要があります。
|
UNT、X.509、SAML |
サービスがUNT、X.509、またはSAMLトークンを使用 |
次のいずれかを指定する必要があります。
|
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メッセージはリテラル・データとして必ずしも使用できるわけではありません。たとえば、デジタル署名はホワイト・スペースの影響を受け、無効になることがあります。
テスト・コンソールを使用してBASIC認証でHTTPビジネス・サービスをテストする場合、テスト・コンソールは、ビジネス・サービスのサービス・アカウントのユーザー名とパスワードを認証します。
同様に、認証を必要とするJMS、電子メールまたはFTPビジネス・サービスをテストする場合、テスト・コンソールは、そのビジネス・サービスに関連付けられたサービス・アカウントを認証します。
テスト・コンソールでは、プロキシ・サービスをテストするときに、HTTPリクエストはネットワーク経由で送信されません。そのため、トランスポート・レベルのアクセス制御は適用されません。
Oracleは、本番システムでテスト・フレームワークを使用しないことをお薦めします。たとえば、パイプラインのテストでは、アクセス制御を含む重要なセキュリティ・ステップの一部がバイパスされます。
Service Busドメインを作成する場合、構成ウィザードには、デフォルトで、管理サーバーおよびすべての管理対象サーバーのターゲットとしてALSBテスト・フレームワーク(テスト・コンソール)が含まれます。次の項では、テスト・コンソールをアンデプロイする様々なオプションについて説明します。
ドメインの作成前に、Oracle Fusion Middleware構成ウィザードでテスト・コンソールを割当て解除するには、次の手順を実行します。
ウィザードによってドメインが作成される場合は、テスト・コンソール(OSB_ORACLE_HOME
\lib\apps\TestFwk.ear
)はデプロイされません。
すでにテスト・コンソールがService Busサーバーにデプロイされ、サーバーが実行中の場合は、テスト・コンソールをアンデプロイできます。
実行中のService Busドメイン上のテスト・コンソールをアンデプロイするには:
この項では、Service Busサービスをテストする際に、Oracle Service Busテスト・コンソールに表示される各セクションについて説明します。すべてのコンポーネントですべてのセクションが表示されるわけではなく、セクションの一部はテストするコンポーネントによって異なります。
テスト・コンソール・リクエスト・ページには、テストするサービスのタイプと、それが使用しているメッセージングのタイプに応じて、次のセクションの組合せが含まれます。
このセクションはパイプラインをテストする場合のみ表示され、1つのフィールド「トレースを含む」が含まれます。このチェック・ボックスを選択すると、各処理ステージでのメッセージの状態のトレースが含まれます。
このセクションは、操作する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サービスのテスト時にのみ使用できます。 |
入力フィールドによって、プロキシ・サービス、ビジネス・サービス、パイプラインまたは分割-結合へ送信されるリクエスト・メッセージが生成されます。「リクエスト・ドキュメント」セクションに入力する値は、サービス・タイプに固有です。それぞれで必要とされる入力のサービス・タイプと説明を以下に示します。
呼出しモード・オプションは、任意のSOAPまたは任意のXMLプロキシ・サービスをテストする場合にのみ表示されます。一方向のサービス呼出しの場合は、「リクエスト/レスポンス」チェックボックスを選択解除します。リクエスト/レスポンス呼出しのチェック・ボックスを選択します。
表58-6 テスト・コンソール・プロパティ - リクエスト・ドキュメント
サービス・タイプ | 説明 |
---|---|
WSDL |
複数の操作が定義されたWSDLベースのサービスの場合、テスト・コンソールはサービスのテスト時に使用するサンプル・ドキュメントを生成および提供します。このサンプル・データを直接使用し、編集してテストを実行するか、または、独自のテスト・データを指定します。 |
任意のXML |
ペイロードの形式でリクエスト入力を入力します。ペイロードは、送信されるメッセージのコンテンツです。コンテンツはXMLドキュメントであることが想定されます。ファイルを参照することも、テキスト・ボックスにメッセージ・コンテンツを直接入力することもできます。 |
任意のSOAP |
ペイロードの形式でリクエスト入力を入力します。ペイロードは、送信されるメッセージのコンテンツです。コンテンツはSOAPエンベロープであることが想定されます。ファイルを参照することも、テキスト・ボックスにメッセージ・コンテンツを入力することもできます。 |
メッセージング |
ファイルベースまたはテキストベースで単一の入力を入力します。メッセージ・サービスによって、バイナリ、Java、MFL、XML、テキストを含む各種入力タイプが定義されます。タイプが 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パラメータの形式またはペイロードの形式でリクエスト入力を行うことができます。パラメータ・フィールドが表示される場合は、各パラメータの入力を行ってください。「ペイロード」フィールドが表示されている場合は、オプションのリストからメディア・タイプを選択してから、「参照」をクリックしてファイルへの移動またはファイルの選択を行うか、テキスト・ボックスにメッセージ・コンテンツを入力します |
テストするサービスがOWSMポリシーを使用して保護されている場合は、テスト・コンソールに「セキュリティ」パネルが表示されます。オーバーライド値を変更したり、セキュリティ・ポリシーを追加または削除したりできます。別のポリシーをテストするには、「追加」ボタンをクリックし、テストするポリシーを選択します。詳細は、「Oracle Web Services Managerを使用したOracle Service Busのセキュリティ」を参照してください。
表58-7 テスト・コンソール・プロパティ - セキュリティ
プロパティ | 説明 |
---|---|
ポリシー名 |
テストするサービスにアタッチされたOWSMポリシーの名前が表示されます。 |
プロパティ |
リストされたポリシーについて、使用可能な各オーバーライド・プロパティの名前が表示されます。使用可能なプロパティは、アタッチされたポリシーに応じて異なります。 |
デフォルト値 |
各オーバーライド・プロパティのデフォルト値が表示されます(存在する場合)。 |
オーバーライド値 |
サービスのテスト時にオーバーライド・プロパティに使用する値を入力します。 |
アクション |
この列の「削除」アイコンをクリックすると、テスト目的でアタッチされたポリシーが削除されます。 |
テストしているサービスがSAMLトークンを想定しているビジネス・サービスへメッセージをルーティングする場合は、これがトークンで表されるIDになります。詳細は、「Oracle Service BusでのSAMLの使用」を参照してください。
表58-8 テスト・コンソール・プロパティ - 認証
プロパティ | 説明 |
---|---|
ユーザー名 |
サービスを呼び出したときにテスト・サービスによって使用されるセキュリティ・コンテキストを設定するためのユーザー名を入力します。このフィールドをWebサービス・セキュリティ(WSS)のユーザー名フィールドと混同しないでください。これは、ローカル・セキュリティ・レルムで有効なユーザー名とパスワードである必要があります。ユーザー名またはパスワードが無効な場合、テスト・サービスでクライアント側のエラーが発生します。 注意: HTTPカスタム・トークン認証を使用するプロキシをテスト・コンソールで呼び出した場合、認証チェックは行われません。 |
パスワード |
ユーザー名に関連付けられるパスワードを入力します。 |
サービス・キー・プロバイダ |
認証に使用するサービス・キー・プロバイダを入力します。このフィールドは、 クライアントの証明書認証を使用するHTTPSビジネス・サービスをテストする場合に使用します。サービス・プロバイダにはSSLクライアント資格が関連付けられている必要がある。テスト・サービスはSSLハンドシェイクでその資格証明を使用します。 |
テスト・コンソールの「トランスポート」パネルでは、テスト・システムのメッセージのメタデータとトランスポート・ヘッダーを指定します。次の項では、トランスポート設定とそれらが処理に及ぼす影響について説明します。
テスト・コンソールの「トランスポート」セクションは、テストするトランスポートのタイプにより異なります。図58-4に、WSDLベースのプロキシ・サービスの「トランスポート」セクションを示します。
パイプラインのメタデータとトランスポート・ヘッダーを設定すると、アウトバウンド・トランスポートのアクションに影響します。メタデータ、メッセージ、およびヘッダーをテストして、パイプライン出力を表示できます。プロキシ・サービスのテスト時に「トランスポート」パネルに表示されるフィールドは、パイプラインで使用できるヘッダーとメタデータを表します。プロキシ・サービスによっては、テスト・コンソールに表示されるフィールドをフィルタできない場合もあります。HTTPベースのすべてのリクエストに対して、トランスポート・パラメータの同じセットが表示されます。
「ユーザー名」と「パスワード」フィールドは、プロキシ・サービスを実行しているユーザーの基本認証を実装するために使用されます。「ユーザー名」と「パスワード」フィールドは、特にトランスポートとの関連はありません。
メタデータ・フィールドは、「ユーザー名」フィールドおよび「パスワード」フィールドと、トランスポート・ヘッダー・フィールドの間に配置されています。表示されるフィールドは、サービスのトランスポート・タイプに基づいています。サービスを定義したときに選択した操作選択アルゴリズムに応じて、事前移入されているフィールドもあります。選択アルゴリズムの詳細は、「Oracle Service Busでのメッセージ・フローの作成」を参照してください。
テストするサービスのタイプに応じて、「トランスポート」パネルのフィールドに値を指定します。パイプラインまたは分割-結合をテストする場合、テスト・データは、呼出し元から離れ、テストするサービスに渡される時点で予期される状態のメッセージを表す必要があります。ビジネス・サービスをテストする場合、テスト・データは、ルート・ノードまたはサービス・コールアウトから送信されるデータを表します。
次のプロパティは、大半のトランスポート・タイプで共通です。特定のヘッダーおよびメタデータの詳細と、テスト・フレームワークでそれらが処理される仕組みについては、「テスト・コンソールでのランタイムによるトランスポート設定の使用方法」を参照してください。
表58-9 テスト・コンソール・プロパティ - トランスポート
プロパティ | 説明 |
---|---|
ユーザー名 |
テストを実行しているユーザーに対してBasic認証を実装するためのユーザー名を入力します。これはトランスポート固有ではありません。 |
パスワード |
上記で入力したユーザー名のパスワードを入力します。 |
リクエスト/レスポンス |
一方向のサービス呼出しの場合は、「リクエスト/レスポンス」チェックボックスを選択解除します。リクエスト/レスポンス呼出しのチェック・ボックスを選択します。このオプションは、任意のSOAPまたは任意のXMLプロキシ・サービスをテストする場合にのみ表示されます。 |
サービス・キー・プロバイダ |
認証に使用するサービス・キー・プロバイダを入力します。このフィールドは、 クライアントの証明書認証を使用するHTTPSビジネス・サービスをテストする場合に使用します。サービス・プロバイダにはSSLクライアント資格が関連付けられている必要がある。テスト・サービスはSSLハンドシェイクでその資格証明を使用します。 |
「トランスポート・テスト・コンソール・プロパティ」では、テスト・コンソールでプロキシ・サービスまたはビジネス・サービスをテストするときに、アウトバウンド・リクエストのトランスポート・ヘッダー、トランスポート・メタデータおよびトランスポート関連のセキュリティ・データの値を構成する方法が説明されています。ただし、テスト・コンソールで作成できる仕様の一部は、実行時に無視されます。つまり、特定のヘッダーやメタデータの値は、テストの実行時に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トランスポート・ヘッダーの制限を参照してください。 |
電子メール |
プロキシ・サービス |
制限はありません。実行時に、設定したトランスポート・ヘッダーとその他のフィールドが保持されます。 |
なし |
電子メール |
ビジネス・サービス |
これらのパラメータに設定したすべての値がService Busランタイムでオーバーライドされます。 |
Content-Type |
ファイル |
プロキシ・サービス |
制限はありません。実行時に、設定したトランスポート・ヘッダーとその他のフィールドが保持されます。 たとえば、 |
なし |
ファイル |
ビジネス・サービス |
制限はありません |
なし |
FTP |
プロキシ・サービス |
制限はありません。実行時に、設定したトランスポート・ヘッダーとその他のフィールドが保持されます。 |
なし |
FTP |
ビジネス・サービス |
制限はありません |
なし |
テスト・コンソールの「添付ファイル」セクションを使用して、添付ファイルをテスト入力の一部として含めます。表58-11は、このセクションのプロパティを示しています。
表58-11 プロキシ・サービス・テスト・コンソール・プロパティ
プロパティ | 説明 |
---|---|
Content-Type |
添付ファイルを識別するグローバルに一意の参照を入力します。 |
Content-ID |
添付ファイルのメディア・タイプとサブタイプを入力します。 |
Content-Description |
コンテンツの簡単な説明を入力します。 |
Content-Disposition |
プロキシ・サービスが添付ファイルを処理する方法を指定します。 |
Content-Transfer-Encoding |
添付ファイルのエンコード方法を指定します。 |
ファイル |
添付ファイルとしてテストするファイルを参照して選択します。 |
Resp.Attach.Display Limit |
テスト結果の表示に含める添付ファイルの文字数。 |