--- schema_version: "1" id: 3c3debac89cbac50905d9df4a9728b4957286dbeccaae995779ad02ba3e06105 title: JMS Connector への移行 collection: mulesoft version: current locale: ja-jp portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/mule-runtime/4.5/migration-connectors-jms.md canonical_url: https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-connectors-jms source_site: docs.mulesoft.com content_type: documentation content_hash: 30890fe43bcaba50729d18a65218b16c345b80919f434e30857439bee6ee6fe3 description: MuleSoft Documentation Site release: "4.5" latest: false --- # JMS Connector への移行 JMS トランスポートは、Mule 3 トランスポートモデルを進化させ、UX の簡素化と DataSense 完全対応のメッセージ情報を使用する、操作ベースのコネクタへと刷新されました。 つまり JMS を使用すると、接続と設定に関して他のコネクタと同じ環境が提供されるだけではなく、構造化されたメッセージ情報に基づき、メッセージの生成とコンシュームも簡略化されます。 また、JMS Connector の新しいバージョンでは待望の JMS 2.0 仕様がサポートされ、共有サブスクリプションなどの新機能がすべて含まれています。 ## [](#ConfiguringTheConnector)コネクタの設定 3.x のトランスポート設定から Mule 4 の JMS Connector 設定への移行は、基本的にはまったく同じパラメーターを使用することを暗黙に示していますが、パラメーターはよりまとまった形で宣言されます。 たとえば、メッセージのコンシュームに使用するパラメーターは「consumer-config」グループで宣言されますが、一般的な認証パラメーターは一般グループで設定されます。また、コネクタの動作に影響するパラメーター (config に存在) が、接続の確立方法にのみ影響するパラメーター (接続レベルで存在) と区別されています。 Mule 3 の例: コネクタの設定 ```xml ``` この同じ設定を Mule 4 で行うには、「topic-consumer」のみに影響する「noLocal」または「durable」のように、実際に適用するコンテキストに同じパラメーターを設定します。 Mule 4 の例: コネクタの設定 ```xml ``` ## [](#ConnectingToABroker)ブローカーへの接続 Mule 4 の JMS Connector では、汎用的な JMS 接続と簡易的な ActiveMQ 接続が引き続き区別されますが、接続のみに関連付けられる、かなり絞り込まれたパラメーターセットを使用します。まずこの簡易接続の設定方法を確認し、その後に汎用アプローチについて説明します。 ### [](#activemq-への接続)ActiveMQ への接続 トランスポートを使用して ActiveMQ 固有のパラメーターを設定する唯一の方法は、ConfigurationFactory を Spring bean として定義してから、各プロパティに渡すという方法です。 .Mule 3 の例: ActiveMQ への接続 ```xml ``` 新しい JMS Connector では、このプロパティを activemq connection で直接設定することができます。 Mule 4 の例: ActiveMQ への接続 ```xml ``` JMS Connector でまだ標準でサポートされていない Connection Factory を使用するトランスポート設定を移行する必要がある場合は、「activemq-connection」で「connectionFactory」属性を引き続き使用して、Connection Factory の bean に参照を渡すことができます。 ### [](#別のブローカーの使用)別のブローカーの使用 Connection Factory への必要な汎用接続は、Mule 3 の JMS トランスポートと Mule 4 の JMS Connector のどちらでも定義することができます。 これには 2 通りの方法があります。1 つ目の方法は、Spring bean を使用して Connection Factory を作成した後、それを Connection Factory として参照することです。 Mule 3 の例: Spring Bean を使用した汎用接続 ```xml ``` Mule 4 の場合も、ほとんど同じです。 Mule 4 の例: Spring Bean を使用した汎用接続 ```xml ``` 汎用接続を作成するもう 1 つの方法は、JNDI を使用して検出される Connection Factory を使用することです。この場合、機能は同じですが、構文がトランスポートからコネクタに変わります。 Mule 3 の例: JNDI を使用した汎用接続 ```xml in in ``` Mule 4 の場合は、JNDI をインラインで設定して行うことができます。 Mule 4 の例: Spring Bean を使用した汎用接続 ```xml ``` この例には、主に 3 つの違いがあります。 - プロパティはインラインで宣言されるので、Spring bean の util を使用する必要がなくなりました。 - JNDI を使用した宛先のルックアップの実行は、以前の「jndiDestinations」と「forceJndiDestinations」の 2 つのパラメーターが統合された、「lookupDestination」という 1 つのパラメーターで設定できるようになりました。 - 「jndiProviderUrl」が「name-resolver」の一部になったように、パラメーターは関連するコンテキスト内に含まれるようになりました。 ## [](#SendingMessages)メッセージの送信 JMS トランスポートでは、JMS メッセージの本文を含めるためにペイロードを必要とし、Mule のアウトバウンドプロパティを使用して JMS プロパティとヘッダーをカスタマイズしていました。新しい Mule 4 アプローチでは、JMS の「publish」操作で、入力パラメーターのみを使用してパブリッシュする JMS メッセージを完全にビルドします。 たとえば、本文にペイロードの一部のみを含めて優先度の高い JMS メッセージを送信し、そのメッセージをグループに関連付ける場合、次の手順を実行する必要があります。 <1>) ​`transform`​ を使用して、メッセージ本文となるものをペイロードに設定します。 <2>) 生成されたストリームを文字列に変換して、テキストメッセージとして送信します。 <3>) アウトバウンドメッセージプロパティにキーとして ​`priority`​ を設定し、JMSPriority を設定します。 <4>) アウトバウンドメッセージプロパティにキーとして ​`JMSXGroupID`​ を設定し、JMSXGroupID を設定します。 Mule 3 の例: 優先度が設定されたメッセージをグループの一部として送信 ```xml (1) (2) (3) (4) ``` Mule 4 では JMS Connector と次の設定を使用して、同じ結果を得ることができます。 Mule 4 の例: 優先度が設定されたメッセージをグループの一部として送信 ```xml (2) (3) (1) #[output application/json --- { order_id: payload.id, supplier: payload.warehouse }] (4) ``` 次の違いに注意します。 1) メッセージの ​`body`​ はインラインで作成され、ペイロードには変更がないため、​`transform`​ コンポーネントは必要ありません。 2) コネクタでは変換出力を自動的に処理できるので、​`object-to-string`​ トランスフォーマーも削除されました。 3) 優先度は ​`publish`​ 操作のパラメーターとして設定され、ユーザーが正確なキーを知っている必要はありません。 4) グループはメッセージ JMSX プロパティの一部として設定され、ユーザーが正確なヘッダー名を知っている必要はありません。 要約すると、JMS トランスポートを使用する 3.x でメッセージをパブリッシュする場合、JMS メッセージの作成を設定するには、MuleMessage ペイロードとアウトバウンドプロパティを使用します。それにはトランスポートの機能についてより深い知識が必要でした。4.x の JMS Connector では、設定可能なすべての要素は、属するスコープのパラメーターとして公開されるため、すべての JMS 機能がより明確に公開されます。 ## [](#ListeningForNewMessages)新規メッセージのリスン JMS トランスポートの ​`inbound-endpoint`​ では、特定のトピックまたはキューで新規メッセージを待機することができます。このリスナーの出力では、メッセージの本文はペイロードに、すべての JMS ヘッダーとプロパティは ​`inboundProperties`​ として含まれます。 Mule 3 の例: セレクターによる絞り込みを使用したメッセージのリスン ```xml (1) (2) (3) (4) ``` この場合、優先度の高いメッセージをリスンし、優先順序のバージョン 2 で要求される新しい形式に適合させます。 1) 受信メッセージを優先度で絞り込みます。 2) inboundProperties に含まれているメタデータを使用して MuleMessage を変換し、新たな API で求められる新しい JSON 形式にペイロードを適合させます。 3) 変換されたペイロードを JSON 文字列に変換します。 4) ペイロードをプロキシキューにパブリッシュします。 Mule 4 に同じコードを実装すると次のようになります。 Mule 4 の例: セレクターによる絞り込みを使用したメッセージのリスン ```xml (1) (2) #[output application/json --- { items: payload, costumer: attributes.properties.userProperties.costumer_id, (3) type: attributes.headers.type }] ``` この場合、フローのコンポーネント数が減り、メッセージペイロードを異なる形式でパブリッシュするために変更する必要がありません。
1検索条件を使用したリスンは、リスナーで「selector」を設定して行います。
2新しいメッセージの定義はインラインで行われるため、新しいメッセージ本文の JSON のみが作成されます。
3「inboundProperties」の代わりに、メッセージの「attributes」POJO を使用します。これで、JMS メッセージの「headers」と「properties」が区別されるようになります。
## [](#ConsumingMessages)メッセージのコンシューム 特定の宛先からのメッセージをフロー途中でコンシュームすることは、Mule 3 の JMS トランスポートではサポートされておらず、その対応策としてアプリケーションに Mule Requester Module を追加して、フロー途中のメッセージのコンシュームを処理していました。 たとえば、新しい REST API の背後にある JMS キューを公開する場合、アプリケーションは次のようになります。 Mule 3 の例: フローの途中のメッセージのコンシューム ```xml ``` 留意点: - JMS メッセージに関するすべてのメタデータは完全に失われるため、CorrelationId のログを作成するには、ヘッダーを取得する構文を知っている必要があります。 - 「selector」による動的な絞り込みは、リクエスターの「resource」URL で行われる必要があるため、複数の引数の構成でエラーが発生しやすくなります。 - JMS Ruquester と Mule Requester の両方の設定が必要です。 Mule 4 には、「consume」操作を使用する、フロー途中のメッセージのコンシューム機能が標準で備わっています。この操作は前述のリスナーとよく似ていますが、相違点はフローのどの時点でも使用できることです。 Mule 4 の例: フローの途中のメッセージのコンシューム ```xml ``` ここで必要なのは JMS Connector のみで、リスナーからのメタデータを使用して「consume」操作に「selector」パラメーターを設定し、またメッセージ属性のメタデータのサポートにより correlationId のログを作成することができました。 ## [](#HandlingTopicSubscriptions)トピックサブスクリプションの処理 3.x でインバウンドエンドポイントとして使用されるトピックでは、トピックサブスクリプションを ​`durable`​ サブスクリプションとして実行する必要があるかどうかをユーザーが設定することができました。これには異なる設定方法があり、​`queues`​ の ​`durable`​ 設定も公開されるという、意味をなさない問題がありました。 3.x でのトピックサブスクリプションは、次のようになります。 Mule 3 の例: トピックサブスクリプション ```xml ``` Mule 4 では、サブスクリプションのメカニズムの見直しを行い、サブスクリプションをトピックのみに絞り込むオプションを残し、JMS 2.0 のサポートのおかげで機能がさらに追加されました。 前述の例は 4.x では次のようになります。 Mule 4 の例: トピックサブスクリプション ```xml ``` ただし、このケースでは、​`topic-consumer`​ 設定で ​`shared`​ サブスクリプションも設定することができ (JMS 2.0 接続を使用している場合のみ)、複数のスレッド、接続、または JVM によるトピックサブスクリプションのメッセージの処理が可能です。 Mule 4 の例: トピックサブスクリプション ```xml ``` ## [](#RespondingToIncomingMessages)受信メッセージへの応答 新しい JMS メッセージのリスナーが「JMSReplyTo」ヘッダーが設定されたメッセージを受信すると、メッセージ処理の完了後に応答が返信宛先に対して生成されます。 Mule 3 の場合、これはトランスポートに ​`` exchange-pattern="request-response"` ``​ を設定することを意味し、フローの結果は自動的に応答のペイロードになります。応答メッセージのヘッダーが ​`outbound-properties`​ を使用して設定されたのに対し、メッセージの本文はフローの最後の ​`payload`​ から取得されました。 Mule 3 の例: 受信メッセージへの応答 ```xml ``` Mule 4 ではその代わりに、応答に関連付けられたすべてのパラメーターを、​`listener`​ コンポーネントの一部としてインラインで直接設定でき、フローの最後に到達したときに変換を行う必要がなくなりました。 Mule 4 の例: 受信メッセージへの応答 ```xml #['BRIDGED'] ``` ## [](#DoingRequestReply)要求-応答の実行 JMS では、​`JMSReplyTo`​ ヘッダーを使用して非同期通信を実行できます。これは、クライアントによってその場で作成される一時的な宛先か、既存の宛先のどちらかを使用して行うことができます。 ### [](#一時的な宛先を使用した返信の要求)一時的な宛先を使用した返信の要求 Mule 3 では、返信宛先がメッセージが到着したら破棄される一時キューである最初のケースの場合、アウトバウンドエンドポイントで "request-response" exchange-pattern を使用します。 Mule 3 の例: 一時的な応答先を使用した要求-応答の実行 ```xml ``` 他方 Mule 4 には、この特定のユースケースの解決を目的とする、​`publish-consume`​ というまったく新しい操作が用意されています。 Mule 4 の例: 一時的な応答先を使用した要求-応答の実行 ```xml #[output application/xml --- { data: payload, costumer: attributes.queryParams.costumer_id }] ``` この場合も、メッセージの構築が ​`message`​ 要素内で操作のインラインで行われることがあり、送信メッセージに影響する変換または設定はその要素の一部として行われます。 ### [](#明示的な宛先を使用した返信の要求)明示的な宛先を使用した返信の要求 明示的な ​`reply-to`​ 宛先を使用した request-reply の実行は、​`request-reply`​ スコープという新しいコンポーネントが必要だったため、3.x では少し複雑でした。 Mule 3 の例: 明示的な返信宛先を使用した Request-Reply の実行 ```xml (1) ``` このスコープ (1) では、request-reply パターンを実行する送受信トランスポートを設定できました。そうすると、送信メッセージに ​`JMSReplyTo`​ ヘッダーが自動的に挿入され、インバウンドエンドポイントでリスンが開始されました。 新しい ​`publish-consume`​ 操作を使用する Mule 4 の JMS Connector では、フローに変更を加える必要がほとんどありません。返信を特定の宛先に送信する必要がある場合は、パブリッシュまたは応答の他のケースと同様に、メッセージビルダーで直接 ​`reply-to`​ ヘッダーを設定します。 Mule 4 の例: 一時的な応答先を使用した要求-応答の実行 ```xml #[output application/xml --- { data: payload, costumer: attributes.queryParams.costumer_id }] (1) ``` この例では、既知の宛先が他のユーザーによってイベント追跡や処理後トリガーなどに使用される場合があることを示すために、返信宛先ヘッダー (​<1>​) をよく知られたトピックに設定します。 ## [](#UsingTransactions)トランザクションの使用 3.x から 4.x に移行する場合、トランザクションのサポートは設定がよく似ています。予想されるのは、​`inbound-endpoint`​ および ​`outbound-endpoint`​ で行われていた設定から、操作トランザクションについて標準化された Mule 4 アプローチへの変更です。 Mule 3 の例: トランザクションの使用 ```xml (1) (2) (3) (4) (5) (6) (7) ``` 注意点:
1ALWAYS_BEGIN​ を指定したインバウンドエンドポイントからトランザクションが開始されます。
2元のペイロードが失われていないことを確認します。
3ペイロードが変換され、アウトバウンドエンドポイントを介して送信可能になります。
4アウトバウンドエンドポイントが ​ALWAYS_JOIN​ に設定されます。
5あらゆる例外をキャッチする例外戦略をセットアップします。
6元のペイロードが復元されるため、元のメッセージが dead.letter にパブリッシュされます。
7最後に、元のメッセージを dead.letter に送信して、現在のトランザクションへの結合を試行します。
Mule 4 でも、次のアプローチで同じシナリオを実装できます。 Mule 4 の例: トランザクションの使用 ```xml (1) (2) #[output application/xml --- payload (3) (4) ```
1ALWAYS_BEGIN​ を指定した ​listener​ からトランザクションが開始されます。
2publish​ 操作によってペイロードが XML 形式でパブリッシュされますが、現在のペイロードを変更したり、​ALWAYS_JOIN​ を指定したトランザクションに結合することはありません。
3生じたエラーをキャッチするエラーハンドラーを使用して、メッセージが失われていないことを確認します。
4現在のペイロードは受信した元のメッセージのままのため、​JOIN_IF_POSSIBLE​ トランザクションアクションを使用してそのまま dead.letter にパブリッシュします。