| Oracle® Fusion Middleware Oracle Service Busでのサービスの開発 12c (12.1.3) E53004-06 |
|
 前 |
 次 |
この章では、MQトランスポートの概要と、サービスでの使用および構成方法について説明します。MQトランスポートにより、IBM WebSphere MQへのアクセスが提供され、インバウンド接続とアウトバウンド接続の両方がサポートされます。
この章の内容は次のとおりです。
MQトランスポートにより、Service BusコンポーネントとIBM WebSphere MQとの間にネイティブの接続が提供されます。MQプロキシ・サービスではWebSphere MQからのメッセージの受信が可能で、MQビジネス・サービスではWebSphere MQへのメッセージのルーティングが可能です。
WebSphere MQの基礎概念の詳細は、IBM WebSphere MQのドキュメントを参照してください。
MQトランスポートによってService Busに提供される機能は、次のとおりです。
インバウンドおよびアウトバウンド接続。MQプロキシ・サービスではWebSphere MQからのメッセージの受信が可能で、MQビジネス・サービスではWebSphere MQへのメッセージのルーティングが可能です。
WebSphere MQへのアクセス。詳細は、「環境へのMQクライアント・ライブラリの追加方法」を参照してください。
メッセージをXML、バイナリ、XML、テキスト、およびMFLの任意の種類で送受信可能です。
すべてのMQメッセージ記述子(MQMD)ヘッダーの処理。メッセージ記述子は、送信または受信されたメッセージのプロパティを表す属性です。構成可能なMQヘッダーのリストについては、「MQトランスポート・ヘッダー」を参照してください。
キュー・マネージャに接続するためのTCP/IPおよびバインディング・モード。TCP/IPモードでは、リモートのWebSphere MQサーバーに接続します。バインド・モードでは、ローカルのWebSphere MQに接続します。
インバウンドおよびアウトバウンド・トランスポートにおける一方向および双方向SSL (TCP/IP接続が使用される場合のみ)。
WebSphere MQ JMSインタフェースを使用する場合と比べて、MQトランスポートの使用には次のような利点があります。
MQトランスポートを使用すると、WebSphere MQ JMSインタフェースを使用した場合に比べ、WebSphere MQへの接続がより高速に行えます。
MQメッセージを読込みおよび生成する機能。JMSインタフェースの使用では、特定のヘッダーは設定できません。
MQ受信メッセージの送受信のサポート。
WebLogicのJNDIへのMQ接続ファクトリおよびMQキューの明示的なバインディングは不要です。
Service Busの範囲外にあるJMSプロバイダのようなリソースの構成は不要です。
メッセージが、JMSトランスポートを使用したチャネリングではなく、トランスポートを使用して直接送信されるため、パフォーマンスが向上します。
MQトランスポートでは、一方向メッセージおよびリクエスト/レスポンス・メッセージング・パターンがインバウンドおよびアウトバウンド接続の両方でサポートされます。デフォルトのパターンは一方向メッセージングです。プロキシ・サービスまたはビジネス・サービスでは、サービスの構成時に「レスポンスが必要」オプションを設定すると、リクエスト/レスポンス・メッセージングがサポートされます。
インバウンドおよびアウトバウンド・トランスポートでは、リクエストとレスポンス間の相関にmessageIDまたはcorrelationIDを使用する非同期のリクエスト/レスポンス・パターンをサポートします。サービスの構成時にレスポンス相関パターンを設定できます。詳細は、「MQトランスポート・ヘッダー」の「CorrelationID」と「MessageID」を参照してください。
アウトバウンド・トランスポートには、相関IDとメッセージIDを自動生成するか、パイプラインで指定したものを使用するオプションが用意されています。トランスポートによって相関IDとメッセージIDが自動生成される必要があることを指示するには、「相関値の自動生成」オプションを選択します。このオプションを選択しなかった場合、Service Busはパイプラインで指定された値を使用します。MQの実装で動的キューを使用する場合、アウトバウンド・トランスポートのレスポンス相関に動的キューを使用できます。
相関値(messageID/correlationID)を自動生成しない場合に、管理対象サーバーがダウンすると、サーバーの再起動時に残っているレスポンス・メッセージが削除されなくなることがあります。Oracleでは、リクエストの有効期限(Expiry)ヘッダーを有限な値に構成し、レポート(Report)ヘッダーにMQC.MQRO_PASS_DISCARD_AND_EXPIRYオプションを設定することをお薦めします。MQC.MQRO_PASS_DISCARD_AND_EXPIRYオプションは、返信のメッセージ記述子がリクエスト・メッセージの有効期限(Expiry)ヘッダー値から継承される必要があるという、受信クライアントに対する指示として機能します。これにより、構成された有効期限の経過後にMQサーバーによってレスポンス・メッセージが確実に削除されるようになります。相関値が自動生成される場合、残っているレスポンス・メッセージのクリーン・アップはService Busサーバーによって実施されます。
MQトランスポートではリモート・トランザクションではなくローカル・トランザクションがサポートされます。
サービスの「レスポンスが必要」、「レスポンス相関パターン」、「相関値の自動生成」の構成の詳細は、「MQトランスポートを使用するプロキシ・サービスの構成」および「MQトランスポートを使用するビジネス・サービスの構成」を参照してください。
MQ接続は、複数のMQプロキシ・サービスおよびビジネス・サービスで再使用できる、共有可能なリソースです。MQ接続リソースは、MQキュー・マネージャに接続するために必要な接続パラメータを提供します。MQベースのプロキシ・サービスまたはビジネス・サービスを作成するには、MQ接続リソースを作成および構成する必要があります。詳細は、「MQ接続の操作」を参照してください。
インバウンド・トランスポートがMQで、アウトバウンド・トランスポートのサービスの品質(QoS)がexactly-onceである場合、結果として得られるQoSはat-least-onceになります。アウトバウンド・トランスポートのQoSのデフォルトはexactly-onceです。
注意:
パイプライン・エラー・ハンドラに、(任意の再試行ロジックを含む)エラー処理ロジックを作成する必要があります。エラー処理の構成の詳細は、「JDeveloperでのエラー・ハンドラの追加」および「コンソールでのエラー・ハンドラの追加」を参照してください。
アウトバウンドがリクエスト/レスポンスの場合、アウトバウンド・トランスポートがexactly-once QoSをサポートするように構成されているときのみ、QoSはat-least-onceになります。Service BusメッセージングのQoSの詳細は、「サービスの品質」を参照してください。
WebSphere MQのクラスタ・サポートは、ストア・アンド・フォワード・メッセージングであり、ロード・バランシングおよびフェイルオーバーではありません。WebSphere MQのクラスタ・キューは、キュー・マネージャの1つにローカルで作成され、共有キューに対してリモート・フォワーダとして動作する他のクラスタ・メンバーと共有されます。MQトランスポートからのリクエストは、ロード・バランシング・アルゴリズムを使用してクラスタのメンバーにメッセージを送信することによってロード・バランシングされます。ただし、トランスポートは、ローカル・キューへの参照を保持するMQサーバー・ノードにアクセスすることによってのみ、メッセージを受信します。
MQトランスポートの制限は次のとおりです。
MQプロキシ・サービスに基づくリクエスト/レスポンス・プロキシ・サービスを、次の方法で呼び出すことはできません。
ルート・アクションまたは動的ルーティングおよびルーティング表アクションを使用して構成されているプロキシ・サービスから。
サービス・コールアウト・アクションを使用して。
ターゲットがMQトランスポートに基づくリクエスト/レスポンス・プロキシ・サービスである場合、サービス・コールアウトを使用してプロキシ・サービスを呼び出すことはできません。
Service Busテスト・コンソールで、リクエスト/レスポンスMQプロキシ・サービスへの間接呼出しは使用できません。
Service BusはIBM WebSphere MQのクライアントであり、Service Busではサポート対象のWebSphere MQバージョンについて実行時のサーバー互換性をサポートしていますが、これらのMQライブラリはService Busとともにインストールされません。使用するドメインで、MQクライアント・ライブラリcom.ibm.mq.jarのサポート対象のバージョンを利用できるようにする必要があります。
Service BusでのWebSphere MQバージョンのサポートについては、『Oracle Service Busの管理』の相互運用性のシナリオと考慮事項に関する項を参照してください。WebSphere MQのシステム要件の詳細は、http://www-306.ibm.com/software/integration/wmq/requirements/index.htmlを参照してください。
com.ibm.mq.jarファイルをService BusドメインのDOMAIN_HOME/libディレクトリにコピーします。 MQトランスポートを使用するようにプロキシ・サービスまたはビジネス・サービスを構成するには、MQサーバーへの接続を定義するMQ接続リソースを作成しておく必要があります。MQ接続は、複数のMQプロキシ・サービスおよびビジネス・サービスで再使用できる、共有可能なリソースです。MQプロキシ・サービスおよびビジネス・サービスは、MQキューにアクセスする前に、MQキュー・マネージャに接続する必要があります。MQ接続リソースは、MQキュー・マネージャに接続するために必要な接続パラメータを提供します。
各MQ接続リソースには、接続プールがあります。同じMQ接続リソースを使用してキュー・マネージャへの接続を取得しているすべてのビジネス・サービスまたはプロキシ・サービスは、そのリソースに対して作成された同じ接続プールを使用します。つまり、同じキュー・マネージャを使用している複数のビジネス・サービスまたはプロキシ・サービスは、接続プールを共有することになります。
Oracle Service BusコンソールでMQ接続を作成するオプションは、MQクライアント・ライブラリをドメインに追加しないと利用できません。JDeveloperでは、ライブラリを使用せずに接続を作成できますが、ランタイムのライブラリが必要になります。
始める前に:
「MQトランスポートの環境の設定」の手順に従い、MQクライアント・ライブラリを使用できるようにします。
MQ接続の作成に必要な次のリソースを作成したことを確認します。
サービス・アカウント
サービス・キー・プロバイダ
MQ接続を作成するには:
次のいずれかを行います:
JDeveloperの場合: アプリケーション・ナビゲータで、新しいMQ接続を含めるプロジェクトまたはフォルダを右クリックして、「新規」をポイントし、「MQ接続」を選択します。
Oracle Service Busコンソールの場合: プロジェクト・ナビゲータで、新しいMQ接続を含めるプロジェクトまたはフォルダを右クリックして、「作成」をポイントし、「MQ接続」を選択します。
このMQ接続の一意の名前と、必要に応じて説明を入力します。
エンドポイントURIに空白を含めることはできません。そのため、空白を含む名前のMQ接続リソース、プロジェクトまたはフォルダを作成しないでください。
「作成」または「終了」をクリックします。
MQ接続定義エディタが表示されます。
「接続タイプ」フィールドで、MQキュー・マネージャに接続する次のいずれかのモードを選択します。
mqTcpModeType: Service Busと同じマシンに存在しないキュー・マネージャに接続するには、TCP/IPを使用します。
mqBindingModeType: Service Busと同じマシンに存在するキュー・マネージャに接続するには、バインド・モードを使用します。
エディタのフィールドは、選択内容に応じて変わります。
MQサーバーに関する次の情報を構成します。
MQホスト名: MQキュー・マネージャのホスト名。TCPモード接続にのみ使用します。
MQポート番号: MQキュー・マネージャ・リスナーのポート番号。TCPモード接続にのみ使用します。
MQキュー・マネージャ名: 接続先のMQキュー・マネージャの名前を入力します。
MQキュー・マネージャのチャネル名: キュー・マネージャのサーバー接続チャネルの名前を入力します。TCPモード接続にのみ使用します。
キュー・マネージャCCSID: 接続を確立するときに使用されるコード化文字セット識別子(CCSID)です。これはTCPモード接続にのみ使用され、主に国際化をサポートする目的で使用されます。
TCPモード接続のSSLサポートを構成するには、次のようにします。
メッセージの送信にSSLを使用するよう「SSLが必要」チェック・ボックスを選択します。これで、サービス側のSSL認証が有効になります。
「暗号セット」フィールドで、SSLが使用する暗号スイート・アルゴリズムを選択します。
暗号スイート・アルゴリズムは、サーバーとクライアントとの間のメッセージ通信を暗号化および復号化する際に使用されます。
クライアント側およびサーバー側のSSL認証をどちらも有効にするには、「双方向SSLが必要」チェック・ボックスを選択します。
双方向SSLを選択した場合、サービス・キー・プロバイダへの参照フィールドで、「参照」アイコンをクリックして、使用するサービス・キー・プロバイダを見つけて選択します。
「静的なサービス・アカウントへの参照」フィールドで、「参照」アイコンをクリックして、使用するサービス・アカウントを見つけて選択します。
「MQバージョン」フィールドで、使用するMQサーバーのバージョンを選択します。
MQ接続を構成するには、次のようにします。
「MQ接続プール・サイズ」フィールドに、接続プールで保持される接続の数を入力します。
「MQ接続タイムアウト」フィールドに、未使用の接続が破棄されるまでの時間間隔を秒単位で入力します。デフォルトは1800秒です。
「MQ接続の最大待機時間」フィールドに、接続が利用可能になるまでに待機する最大時間(ミリ秒単位)を入力します。
その時間内に接続が確立されない場合、Service Busが例外をスローします。デフォルトは3000ミリ秒です。
この接続によって処理されるトランザクションが分散(XA)トランザクションである場合は、「XA有効」を選択します。
永続性を確保するには、キューを構成する必要があります。バージョン5.3または6.0 (いずれも非推奨)を使用している場合は、クラスパスにcom.ibm.mqetclient.jarファイルを追加します。
ツールバーで、「保存」をクリックします。
Oracle Service Busコンソールを使用している場合は、「アクティブ化」をクリックして、セッションを終了し、実行時用に構成をデプロイします。
MQ接続を作成すると、その情報を再構成できます。
MQ接続を編集するには:
MQ接続を削除する前に、その接続がMQトランスポートで現在使用されていないことを確認します。使用されている場合、削除する前に、プロキシ・サービスまたはビジネス・サービス構成からその接続を削除します。MQ接続が他のリソースで参照される場合でも、その接続を削除できますが、削除されたリソースに対する未解決の参照が原因で競合が生じることがあります。
コンソールとJDeveloperの両方で、参照と依存関係があるかどうかを確認できます。Oracle Service Busコンソールの場合、MQ接続定義エディタでMQ接続を開き、右上にある「参照」アイコンをクリックして、サービスで参照を使用しているかどうかを調べます。JDeveloperの場合、MQ接続を右クリックして、「依存性の参照」を選択します。
MQ接続を削除するには:
次のように、MQトランスポート・ビジネス・サービスを構成して、アプリケーション・エラーおよび通信エラーを処理できます。
アプリケーション・エラー: アプリケーション・エラーが発生した場合に、ビジネス・サービスのエンドポイントURIを再試行するかどうかを指定できます。詳細は、ビジネス・サービス定義エディタの「アプリケーション・エラーの再試行」フィールドに関して提供されているオンライン・ヘルプを参照してください。
通信エラー: 通信エラーが発生した場合に、ビジネス・サービスのURIがオフラインになるように構成できます。詳細は、『Oracle Service Busの管理』のビジネス・サービス用のエンドポイントURIの管理とモニターに関する項を参照してください。
次の項では、Service BusがWebSphere MQへ接続する方法について概説し、WebSphere MQとService Bus間の通信で使用されるメッセージ・タイプのいくつかについて概要を示します。
Service Busは、WebSphere MQ JMSインタフェースを介してWebSphere MQに接続します。つまり、Service BusはWebSphere MQ JMSクライアントです。Oracle WebLogic Serverの外部JMSサーバーでは、WebSphere MQサーバーに対する初期コンテキスト・ファクトリ、接続ファクトリおよびキューを指定します。詳細は、『Oracle WebLogic Server JMSリソースの管理』の外部サーバー・リソースからサード・パーティJMSプロバイダへのアクセスの構成に関する項を参照してください。
WebSphere MQ JMSでは、2種類のトランスポート方式がサポートされます。
BINDINGS
CLIENT
WebSphere MQ JMSクライアントがキュー・マネージャと物理的に同じマシン上で実行されている場合は、トランスポートのタイプをBINDINGSに設定します。それ以外の場合は、CLIENTタイプのみ使用できます。
WebSphere MQは、次の2通りの方法でService Busと対話できます。
Service Busでは、次のメッセージングのタイプがサポートされます。
リクエストが欠落しているなど、信頼性のない配信を受け入れる場合、必要に応じて非永続メッセージを使用できます。WebSphere MQのロギングとWebLogic JMSメッセージの永続化は永続メッセージに対してのみ実行されるため、非永続メッセージを使用すると関連するI/Oアクティビティが不要になります。
注意:
非永続メッセージのスループットは、通常はマシンのプロセッサ速度によって制限されます。ただし、物理メモリーが不足している場合は、サーバー・システムがページングI/OでCPUサイクルを消費することがあります。
キューへのトランザクション(XA)アクセスのサポートを有効にするには、次のいずれかのトランスポート・タイプを使用します。
Service BusがIBM WebSphere MQと同じマシン上にある場合は、BINDINGSを使用してキュー・マネージャにアクセスします。
Service BusとIBM WebSphere MQが異なるマシン上に存在する場合はCLIENTを使用します。ただし、CLIENTを使用する場合、XAトランザクションをサポートするIBM WebSphere MQクライアントの特殊なバージョンが必要です。このバージョンは、WebSphere MQ Extended Transaction Clientと呼ばれます。
ヒント:
デプロイメント記述子をXA対応リソース(JMS、TUXEDO、EJB)に適切に設定するには、プロキシ・サービスを作成する前に、参照接続ファクトリのXA属性を設定する必要があります。
Service Busとともに使用する場合、WebSphere MQのチューニングには次のガイドラインが役に立ちます。WebSphere MQ固有の情報については、関連するWebSphere MQのドキュメントを参照してください。
Service Busおよびキュー・マネージャが同じマシンにデプロイされている場合は、トランスポートのタイプとしてBINDINGSを使用します。
アプリケーション・リクエストのごく一部にのみXAが必要な場合は、別の接続オブジェクトを作成してXAを無効にします。
アクティブ・ログを多くのボリュームに分散させます。システムで高い永続メッセージ・スループットを処理する必要がある場合は、他のデータ・セットの使用との競合を最小限に抑えるために、高速の直接アクセス・ストレージ・デバイス(DASD)にログ・ファイルを置く必要があります。各アクティブ・ログを使用率の低い個別のボリュームに割り当てることをお薦めします。
バッファ・オーバーフローを削減するために、バッファ・プールとページ・セットをチューニングします。バッファ・オーバーフローにより、ハード・ディスクのフラッシュが発生します。
Service Bus JMSからMQキューへの接続が切断されないように、アクティブなチャネル数を増やして100を超えるようにします。デフォルトでは、アクティブなチャネル数は10です。
プロキシ・サービスでMQトランスポートを使用すると、WebSphere MQからメッセージを取得できます。ビジネス・サービスでMQトランスポートを使用すると、WebSphere MQにメッセージを送信できます。この項では、Service Bus環境にWebSphere MQを追加する方法、Service Bus MQトランスポートの特性、およびMQプロキシ・サービスやビジネス・サービスを構成する方法について説明します。
MQプロキシ・サービスまたはビジネス・サービスを作成する際は、次の形式でエンドポイントURIを指定します。
mq://local-queue-name?conn=mq-connection-resource-ref
説明:
ここで、local-queue-nameはMQサーバーに構成されているローカル・キューの名前です。
mq-connection-resource-refはMQ接続リソースの場所です。
たとえば、mqConnectionという名前のMQ接続リソースをdefaultMQフォルダに作成し、キュー名がtestQueueである場合、URIはmq://testQueue?conn=defaultMQ/mqConnectionになります。
注意:
エンドポイントURIには空白を含めることができないため、名前にスペースを入れてMQ接続リソース、プロジェクトまたはフォルダを作成しないでください。
MQトランスポートのプロキシ・サービスを構成するには、「MQ接続の作成方法」で示すようにMQ接続を作成する必要があります。サービスの構成時に、サービス・タイプとしてメッセージまたは任意のXMLを選択します。詳細は、「プロキシ・サービスの作成と構成」を参照してください。
次の表に、プロキシ・サービス用のMQトランスポートの構成に使用するプロパティを示します。
表33-1 プロキシ・サービス用のMQトランスポート・プロパティ
| プロパティ | 説明 |
|---|---|
レスポンスが必要 |
アウトバウンド・メッセージの送信後にレスポンスを受け取ることを指定する場合は、このオプションを選択します。 |
レスポンス相関パターン |
MessageIDまたはCorrelationIDを選択して、レスポンス相関パターンがどちらのIDに基づく必要があるかを指定します。 このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。 |
MQレスポンスURI |
レスポンスがパブリッシュされる宛先を入力します。次のようにエンドポイントURIと同じ形式でレスポンスURIを入力します。 mq://local-queue-name?conn=mq-connection-resource-ref 説明:
このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。 |
レスポンス・メッセージ・タイプ |
レスポンスのメッセージ・タイプとして、次のいずれかを選択します。
このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。 |
トランザクション・タイムアウト |
プロキシ・サービスによって開始されたXAトランザクションがタイムアウトするまでに待機する時間を秒単位で入力します。このプロパティは、XAトランザクション用に構成されたMQ接続リソースを使用するサービスにのみ適用されます(つまり、MQ接続リソースに「XA有効」オプションが選択されます)。 デフォルト値は |
ポーリング間隔 |
メッセージの次のポーリングまでに待機する間隔をミリ秒単位で入力します。デフォルトは |
ポーラー・ディスパッチ・ポリシー |
ポーラー・スレッドのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。 ワーク・マネージャの詳細は、次の説明を参照してください。
|
バックアウトしきい値 |
「配信失敗メッセージURI」フィールドに指定したキューにパイプラインがメッセージをリダイレクトする前に、メッセージを再試行する回数を示す値を入力します。 このフィールドに値が指定されていない場合は、再試行を実行しないで、メッセージを配信失敗キューにリダイレクトします。 |
MQ配信失敗メッセージURI |
「バックアウトしきい値」フィールドに指定した再試行回数を行った後、リクエスト・メッセージがリダイレクトされる配信失敗メッセージ・キューのURIを入力します。 このフィールドに値を指定しない場合、「バックアウトしきい値」フィールドに指定した再試行回数を行った後、メッセージがキューに戻され、各ポーリングでMQトランスポートによって無視されます。配信失敗メッセージURIの形式はエンドポイントURIの形式と同じです。 |
エンドポイントURI 'GET'オプション |
次のオプションでMQ GETメッセージ・オプションを入力します。
複数のオプションを区切るには、「|」または「+」を使用します。たとえば、次のように指定できます。 MQC.MQGMO_ACCEPT_TRUNCATED_MSG | MQC.MQGMO_LOCK インバウンド・キューからのメッセージを読み込む場合、MQ GETメッセージ・オプションが適用されます。 MQトランスポートによるRFH2ヘッダーの処理方法の詳細は、「RFH2ヘッダーについて」を参照してください。 |
RFH2ヘッダーのプロセス |
メッセージ・ペイロードからWebSphere MQ RFH2ヘッダーを解析して、RFH2データを含むRFH2Headersトランスポート・ヘッダーを自動的に生成する場合はこのオプションを選択します。このオプションを選択しない場合は、ペイロードはそのまま渡されます。 MQトランスポートによるRFH2ヘッダーの処理方法の詳細は、「RFH2ヘッダーについて」を参照してください。 |
返信先ヘッダーを無視 |
キュー・マネージャを指定する返信先ヘッダーを無視する場合はこのオプションを選択します。 |
動的返信先ヘッダー |
リクエスト・メッセージの返信先ヘッダーをレスポンス・メッセージでも使用する場合はこのオプションを選択します。 このプロパティがtrueに設定されて、「返信先ヘッダーを無視」プロパティがfalseに設定される場合、静的返信先キュー・マネージャ(プロキシ・サービスのレスポンスURIで定義)が、リクエスト・メッセージで指定されるキュー・マネージャと同じでなければ、メッセージは、リクエスト・メッセージで指定されるキュー・マネージャに送信されます。 |
ワーカー・スレッド・ディスパッチ・ポリシー |
このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。 ワーク・マネージャの詳細は、次の説明を参照してください。
|
MQトランスポートのビジネス・サービスを構成するには、「MQ接続の作成方法」で示すようにMQ接続を作成する必要があります。サービスの構成時に、サービス・タイプとしてメッセージまたは任意のXMLを選択します。詳細は、「ビジネス・サービスの作成と構成」を参照してください。
次の表に、プロキシ・サービス用のMQトランスポートの構成に使用するプロパティを示します。
表33-2 ビジネス・サービス用のMQトランスポート・プロパティ
| オプション | 説明 |
|---|---|
メッセージ・タイプ |
サービスで処理されるメッセージのメッセージ・タイプとして、次のいずれかを選択します。
|
レスポンスが必要 |
アウトバウンド・メッセージの送信後にレスポンスを受け取ることを指定する場合は、このオプションを選択します。 |
レスポンス相関パターン |
レスポンス相関パターンのベースとして、次のいずれかのオプションを指定します。
このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。 |
相関値の自動生成 |
このチェック・ボックスを選択して、CorrelationIDまたはMessageIDを自動的に生成します。 このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。 |
モデル・キュー |
動的キューの生成に使用するモデル・キューの名前を入力します(「動的キュー」レスポンス相関パターンの場合のみ)。 |
MQレスポンスURI |
レスポンスがパブリッシュされる宛先を入力します。次のようにエンドポイントURIと同じ形式でレスポンスURIを入力します。 mq://local-queue-name?conn=mq-connection-resource 動的キューを使用する場合、次の形式でURIを入力します。 mq://dynamic_queue_prefix?conn=mq-connection-resource
動的キューのレスポンスURIではワイルドカードとしてアスタリスク(*)も使用できます。次に例を示します。 mq://dynamic_queue_prefix*
mq://*
URIに このオプションは、「レスポンスが必要」オプションが選択されている場合のみ使用できます。 |
レスポンス・タイムアウト |
接続を切断するまでのレスポンスの待機時間を秒単位で入力します。デフォルトは このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。 |
ポーリング間隔 |
メッセージの次のポーリングまでに待機する間隔をミリ秒単位で入力します。デフォルトは このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。 |
ポーラー・ディスパッチ・ポリシー |
ポーラー・スレッドのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。 ワーク・マネージャの詳細は、次の説明を参照してください。
|
動的キュー・プーリング |
サーバーが動的キューへのプール接続を使用する場合は、このオプションを選択します(動的キュー・レスポンス相関パターンの場合のみ)。動的キューに別の接続プールを使用する場合は、動的キュー専用のMQ接続リソースを構成することを検討してください。 各リクエストに新しい動的キュー・インスタンスを作成する場合(レスポンスの後でキューを破棄する場合)は、このオプションを選択しないでください。 |
エンドポイントURI 'PUT'オプション |
次の中からMQ PUTメッセージ・オプションを入力します。
複数のオプションを区切るには、「|」または「+」を使用します。たとえば、次のように指定できます。 MQC.MQPMO_LOGICAL_ORDER | MQC.MQPMO_NEW_MSG_ID MQ PUTメッセージ・オプションは、メッセージがアウトバウンド・キューに配置された場合に適用されます。 |
MQ認識できないレスポンスURI |
認識できないレスポンス・メッセージの送信先のキューを示すURIを入力します。「相関値の自動生成」チェック・ボックスが選択された場合のみ、設定が有効になります。 このフィールドの値を指定しない場合、認証できないレスポンス・メッセージが削除されます。 |
RFH2ヘッダーのプロセス |
メッセージ・ペイロードからWebSphere MQ RFH2ヘッダーを解析して、RFH2データを含むRFH2Headersトランスポート・ヘッダーを自動的に生成する場合はこのオプションを選択します。このオプションを選択しない場合は、ペイロードはそのまま渡されます。 MQトランスポートによるRFH2ヘッダーの処理方法の詳細は、「RFH2ヘッダーについて」を参照してください。 |
ワーカー・スレッド・ディスパッチ・ポリシー |
ワーカー・スレッドのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。 ワーク・マネージャの詳細は、次の説明を参照してください。
|
環境値とは、多くの場合ドメイン間での構成の移動(テスト環境から運用環境への移行など)に伴って変化する値で、構成データに含まれる特定の事前定義されたフィールドです。環境値の更新の詳細は、『Oracle Service Busの管理』のOracle Service Bus環境のカスタマイズに関する項を参照してください。
次の表に、MQトランスポートとMQ接続リソースでサポートされる環境値を示します。これらの変数に指定した値により、特定のMQプロキシ・サービスおよびビジネス・サービス用に構成されたプロパティがオーバーライドされます。MQトランスポートに基づいたサービスでは、「ワーク・マネージャ」環境値もサポートされています。
表33-3 MQトランスポートとMQ接続リソースの環境値
| 値 | 説明 |
|---|---|
MQ接続プール・サイズ |
MQ接続プールで保持される接続の数。 |
MQ接続タイムアウト |
未使用の接続が破棄されるまでの秒単位の時間間隔。 |
MQ配信失敗メッセージURI |
指定した回数再試行を行った後、リクエスト・メッセージがリダイレクトされる配信失敗メッセージ・キューのURI。 |
MQホスト名 |
MQキュー・マネージャのホスト名(TCPモードの接続のみ)。 |
MQポート番号 |
MQキュー・マネージャのポート番号(TCPモードの接続のみ)。 |
MQキュー・マネージャのチャネル名 |
キュー・マネージャ・サーバー接続チャネルの名前(TCPモードの接続のみ)。 |
MQキュー・マネージャ名 |
接続先のMQキュー・マネージャの名前。 |
MQレスポンスURI |
レスポンスが必要なときに、そのレスポンスがパブリッシュされる宛先のURI。 |
MQ認識できないレスポンスURI |
相関値が自動生成されたときに、認識できないレスポンス・メッセージが送信されるキューを表すURI。 |
MQバージョン |
使用されるWebSphere MQのバージョン。 |
MQ XA有効 |
この接続によって処理されるトランザクションが分散(XA)トランザクションであるかどうかを示す値。 |
次の表に、MQトランスポートで使用されるヘッダーを示します。ヘッダーの多くはアウトバウンド・リクエストとインバウンド・レスポンスの両方で共通になっています。返信先キュー名、返信先キュー・マネージャ名、ユーザーID、およびバージョンの各ヘッダーはインバウンド・レスポンス用としてのみ編集できます。
パイプラインを構成するときに、トランスポート・ヘッダー・アクションを使用してメッセージのヘッダー値を設定できます。
表33-4 MQトランスポート・ヘッダー
| ヘッダー | 説明 | インバウンド・レスポンス/アウトバウンド・リクエスト |
|---|---|---|
アカウンティング・トークン |
アカウンティング・トークンは、メッセージのIDコンテキストの一部です。 インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。 アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。 |
両方 |
アプリケーションIDデータ |
アプリケーションIDデータは、メッセージのIDコンテキストの一部です。この値を使用して、メッセージまたはメッセージの送信元についての追加情報を提供できます。 インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。 アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。 |
両方 |
アプリケーション送信元データ |
送信元アプリケーションについてのデータです。この値は、メッセージの送信元についての追加情報を提供するためにアプリケーションが使用できます。 インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。 アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。 |
両方 |
バックアウト数 |
1単位の処理の一部として、メッセージがMQキューから返され、その後取り消された回数です。 インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。 アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。 |
両方 |
キャラクタ・セット |
アプリケーション・メッセージ・データ内の文字データのコード化文字セット識別子です。 インバウンド・トランスポート・アクション: このフィールドは、データを特定の表現に変換するためにインバウンド・トランスポートによって使用されます。リクエスト/レスポンス・メッセージングの場合、リクエスト・メッセージのcharacterSetヘッダーはレスポンス・メッセージにコピーされます。このヘッダーがインバウンド・リクエストで構成されていない場合、デフォルト値である アウトバウンド・トランスポート・アクション: このヘッダーは、アウトバウンド・トランスポート用にパイプラインで設定できます。このヘッダー値が設定されていない場合は、デフォルト値の |
両方 |
相関ID |
取得する必要があるメッセージの相関IDです。 インバウンド・トランスポート・アクション: correlationIDに基づくレスポンス相関パターンでは、リクエストのcorrelationIDがレスポンスにエコーされます。ユーザーはレスポンス・パイプライン内でcorrelationIDをオーバーライドできます。 アウトバウンド・トランスポート・アクション: サービスの構成中にcorrelationIDの自動生成オプションが選択されている場合、アウトバウンド・トランスポートは自動的にcorrelationIDを生成し、トランスポート・ヘッダーからのcorrelationIDが上書きされます。この値が指定されていない場合、パイプラインで指定されているcorrelationIDが使用されます。 一方向メッセージングの場合、パイプラインで指定されているcorrelationIDが(アウトバウンド)リクエストで使用されます。 |
両方 |
エンコーディング |
アプリケーション・メッセージ・データ内の数値に使用される表現です。 インバウンド・トランスポート・アクション: インバウンド・トランスポートでは、このヘッダーを使用して着信メッセージ・データを解釈します。レスポンス・パイプラインでこのヘッダーが構成されていない場合、デフォルト値である アウトバウンド・トランスポート・アクション: このヘッダーがアウトバウンド・トランスポートのパイプラインで設定されていない場合、デフォルト値である |
両方 |
有効期限 |
有効期限は、メッセージを送信するアプリケーションによって設定されます(10分の1秒単位)。有効期限が過ぎたメッセージは、キュー・マネージャによって破棄されます。 インバウンド・トランスポート・アクション: リクエスト/レスポンス・メッセージングでは、リクエストの有効期限ヘッダーはインバウンド・トランスポートによってレスポンスにコピーされます。 アウトバウンド・トランスポート・アクション: 対応するトランスポート・ヘッダーがパイプラインで設定されている場合、このヘッダーはアウトバウンド・リクエスト・メッセージにコピーされます。 注意: レポート・ヘッダーには(他のオプションに加えて) |
両方 |
フィードバック |
フィード・バック・レポートの性質です。この値は、 インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。 アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。 |
両方 |
フォーマット |
メッセージ・データのフォーマット名です。フォーマット名は、メッセージの送信者によって使用され、受信者にメッセージのデータの性質を示すものです。 インバウンド・トランスポート・アクション: このフィールドが アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。 |
両方 |
グループID |
物理メッセージが属しているメッセージ・グループを識別する値です。 インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。 アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。 |
両方 |
オフセット |
セグメント化されたメッセージにおいて、論理メッセージの先頭からの、物理メッセージのデータのオフセットです。 インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。 アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。 |
両方 |
元の長さ |
セグメント化されたメッセージの元の長さです。 インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。 アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。 |
両方 |
メッセージ・フラグ |
メッセージのセグメント化とステータスを制御するフラグです。 インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。 アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。 |
両方 |
メッセージID |
取得するメッセージのIDです。 インバウンド・トランスポート・アクション: messageIDがレスポンス・パイプライン内で指定されていない場合、messageIDヘッダーは messageIDに基づく相関の場合、インバウンド・トランスポートによってリクエストのmessageIDがレスポンスのcorrelationIDヘッダーにコピーされます。レポート・ヘッダーに アウトバウンド・トランスポート・アクション: サービスの構成時にmessageIDの自動生成オプションが指定されていると、アウトバウンド・トランスポートによりmessageIDが自動生成され、トランスポート・ヘッダーのmessageIDが上書きされます。この値が指定されていない場合は、messageIDトランスポート・ヘッダーが使用されます。 一方向メッセージングの場合、パイプラインで指定されているmessageIDがアウトバウンド・リクエストで使用されます。この値が指定されていない場合、messageIDはトランスポートにより自動生成されます。 |
両方 |
メッセージ・シーケンス番号 |
グループ内の論理メッセージのシーケンス番号です。 インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。 アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。 |
両方 |
メッセージ・タイプ |
メッセージのタイプです。 インバウンド・トランスポート・アクション: インバウンド・トランスポートでは、 アウトバウンド・トランスポート・アクション: アウトバウンド・トランスポートでは |
両方 |
永続性 |
メッセージの永続性を示します。 インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。 アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。 |
両方 |
優先度 |
メッセージの優先度です。 インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。 アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。 |
両方 |
配信アプリケーション名 |
メッセージを配信するアプリケーションの名前です。 インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。 アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。 |
両方 |
配信アプリケーションの種類 |
メッセージを配信するアプリケーションの種類です。 インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。 アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。 |
両方 |
配信日時 |
メッセージが配信された日付と時刻です。これは、簡単な日付書式( インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。 アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。 |
両方 |
返信先キュー名 |
返信の送信先となるキューの名前です。 メッセージの取得リクエストを発行したアプリケーションは、 インバウンド・トランスポート・アクション: このフィールドが設定されていると、インバウンド・トランスポートでは アウトバウンド・トランスポート・アクション: リクエスト/レスポンス・メッセージ・パターンでは、メッセージ・フローで設定された |
インバウンド・レスポンス |
返信先キュー・マネージャ名 |
返信またはレポート・メッセージを送信できるキュー・マネージャの名前です。 インバウンド・トランスポート・アクション: リクエスト/レスポンス・メッセージ・パターンでは、インバウンド・メッセージの アウトバウンド・トランスポート・アクション: リクエスト/レスポンス・メッセージ・パターンでは、メッセージ・フローで設定された |
インバウンド・レスポンス |
レポート |
レポートとは、他のメッセージに関するメッセージです。このフィールドでは、元のメッセージを送信しているアプリケーションでどのレポート・メッセージが必要か、これらのレポート・メッセージにアプリケーション・メッセージ・データを含める必要があるかどうか、またレポートまたは応答にメッセージIDおよび相関IDを設定する方法を指定します。これはMQCクラスの1つ以上の定数を「+」または「|」演算子で組み合せることによって構成されます。 インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。リクエスト/レスポンス・メッセージングの場合、このヘッダーはレスポンス・パイプライン内に構成できます。 アウトバウンド・トランスポート・アクション: トランスポートによってレポート・フィールドに次のオプションの組合せが必ず設定されます。 messageIDに基づく相関パターンが使用される場合には 注意: これらのオプションは、パイプラインの対応するトランスポート・ヘッダーで指定されているオプションに追加して設定されます。 |
両方 |
ユーザーID |
メッセージIDの一部であり、メッセージ送信元のユーザーを識別します。 インバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。このヘッダーはパイプライン内でトランスポート・ヘッダーにコピーされます。 アウトバウンド・トランスポート・アクション: トランスポートによる明示的な処理は行われません。対応するトランスポート・ヘッダーがパイプライン内で設定されている場合は、リクエスト・メッセージにコピーされます。 |
インバウンド・レスポンス |
バージョン |
メッセージ記述子のバージョン番号です。 インバウンド・トランスポート・アクション: インバウンド・トランスポートは、メッセージ記述子バージョン1とバージョン2の両方をサポートしています。 アウトバウンド・トランスポート・アクション: デフォルトでは、アウトバウンド・トランスポートはバージョン2のヘッダーを生成します。ただし、このフィールドはパイプライン内でオーバーライドされることがあります。 |
インバウンド・レスポンス |
RFH2Headers |
トランスポート構成に「RFH2ヘッダーの処理」オプションが設定されている場合のペイロードにあるRFH2ヘッダー。RFH2HeadersヘッダーはStringです。 インバウンド・トランスポート・アクション: RFH2ヘッダーは、対応するトランスポート・メタデータ・ヘッダーを作成するためにMQペイロードから抽出されます。 アウトバウンド・トランスポート・アクション: アウトバウンドMQペイロードに挿入されたRFH2ヘッダー(各ヘッダー用の内容の長さを含む)を抽出するために、RFH2Headersデータを解析します。 |
両方 |
パイプラインでは、インバウンド・リクエストおよびアウトバウンド・リクエストの両方について、トランスポート・ヘッダー・アクションを使用してメッセージ内のヘッダー値を設定することによって、トランスポート・ヘッダーを構成できます。詳細は、「コンソールでのトランスポート・ヘッダー・アクションの追加」を参照してください。
パイプラインにおいて、トランスポート・ヘッダーが明示的に設定されている場合、次のシナリオを除いて、この値がヘッダー値をオーバーライドします。
アウトバウンド・リクエスト/レスポンス・パターンの場合、「相関値の自動生成」オプションがリクエスト/レスポンス・メッセージ・パターンのアウトバウンド・リクエストで選択されていると、この値がメッセージ・フローで設定されている場合であっても、相関IDが常に生成されます。
メッセージ・フローでレポート・ヘッダーが設定されている場合、レポート・ヘッダーに関連付けられた複数のディレクティブの組合せがデフォルトのディレクティブにマージされます。
リクエスト/レスポンス・メッセージ・パターンのアウトバウンド・リクエストについて、メッセージ・フローでreplyToQueueManagerNameまたはreplyToQueueNameヘッダーが設定されている場合、これらの値は無視されます。そのかわりに、これらのトランスポート・ヘッダーの値はビジネス・サービス用に構成されたレスポンスURIから導出されます。
インバウンド・レスポンスの場合、replyToQueueManagerNameヘッダーにある値が、レスポンスURIで指定されたキュー・マネージャ名と一致しないと、エラー・メッセージが生成され、レスポンス・メッセージは送信されません。
インバウンド・リクエスト・ヘッダーに設定されたreplyToQueueNameは、プロキシ・サービスの返信先URIで構成された値をオーバーライドします。
一方向ビジネス・サービスの場合、メッセージ・タイプのヘッダーがメッセージ・フローでリクエスト・タイプに構成されていると、replyToQueueNameヘッダーを指定する必要があります。この値が指定されていない場合は、MQサーバーでエラーが発生すると、メッセージはロール・バックされます。
RFH2Headerヘッダーには複数の<RFH2Header>ブロックがあり、各ブロックには複数のフォルダが含まれています。MQトランスポートによって、各ブロックが、フォルダの線形リストを含む1つのRFH2ヘッダーに統合されます。
たとえば、次のブロックが一つのRFH2Headerヘッダーに統合されます。
<RFH2Header>
<mcd><Msd>jms_bytes</Msd></mcd>
</RFH2Header>
<RFH2Header>
<usr><clientId>DASHBOARD</clientId></usr>
</RFH2Header>
